Re: WebObjects Nightly Builds and WOLips addition
Re: WebObjects Nightly Builds and WOLips addition
- Subject: Re: WebObjects Nightly Builds and WOLips addition
- From: "Henrique Prange" <email@hidden>
- Date: Wed, 11 Jun 2008 21:28:31 -0300
Hi Chuck,
I think WebObjects libraries are a good example of how dependency
management (and I'm talking in a general way) can make developer's
life easier. Do you think it is a good idea to put every WebObjects
library into SVN? How about storing all versions of WebObjects
libraries into SVN (5.2, 5.3, 5.3.1, 5.4.2-SNAPSHOT and etc)? I
believe you and your co-workers have Macs and it is not such a
problem. But what if you have a mixed environment (Mac, Linux and
Windows)?
The dependency management mechanism made my life and my co-workers
life easier. Sure, not without a cost to learn how to configure and
use it. But nowadays this mechanism is invaluable for us. Just to show
an example, how many companies/users with Windows machines are using
the latest official version of WebObjects (5.4.1)? I think it is a
very small number (please correct if I'm wrong). We tried that version
without effort in all machines in the day when it was released. I
don't know, but I think it is pretty good environment and a pretty
good reason to use some kind of dependency management.
I also agree with the theory that you should not use SCM to store
binary data if you can generate it from source. One advantage is
related to space. If you don't store binary data your projects became
smaller. This argument seems ridiculous, but when you live in a
country where bandwidth and GBytes are not so cheap, it is very
important.
By the way, I think it is a matter of taste and needs.
Cheers,
Henrique
PS.: Of course, you can use Ant+Ivy to solve this problem. I prefer
Maven because it solves other problems too.
On Wed, Jun 11, 2008 at 8:15 PM, Chuck Hill <email@hidden> wrote:
>
> On Jun 11, 2008, at 12:59 AM, Lachlan Deck wrote:
>
>> Yeah, it's worth saying that you don't want to 'switch' blindly.
>>
>> I spent a few months reading and kicking the tyres. It's one of those
>> things you really need to read up on to see if it works for you.
>>
>> And yes, you want to:
>> a) lock down your versions
>> b) put 3rd party dependencies into your shared repo so you know they're
>> always available.
>
> How is that different from putting the jars in svn or in a framework in svn
> (or your source control of choice)? If you are going to make local copies
> (and I do), then as simple a format as possible makes sense to me. If you
> are referring to external Maven repositories for your dependancies, then are
> at their mercy. And I have seen them go away or get moved.
>
>
> Chuck
>
>
>> On 11/06/2008, at 5:30 PM, Andrus Adamchik wrote:
>>
>>> In the sake of a balanced view you may also read this:
>>>
>>>
>>> http://tapestryjava.blogspot.com/2007/11/maven-wont-get-fooled-again.html
>>>
>>> Sort of matches my experience - the stated benefits of Maven are too big
>>> to resist the switch, but get ready for some major pain.
>>>
>>> Andrus
>>>
>>>
>>>
>>> On Jun 11, 2008, at 10:19 AM, Lachlan Deck wrote:
>>>>
>>>> Just some random thoughts...
>>>>
>>>> On 11/06/2008, at 4:16 PM, Ricardo Parada wrote:
>>>>
>>>>> I know very little about maven. Why would one want to build apps this
>>>>> way
>>>>
>>>> Lots of reasons. Some WO(Lips) particulars
>>>> - classpath works ;-) It's all defined once.
>>>> - not dependent on installed environment (e.g., spurious
>>>> wobuild.properties, custom ant stuff)
>>>> - don't need to switch installed environments
>>>>
>>>> More seriously, someone else may be able to summarise its benefits more
>>>> succinctly. The best thing to do as an into (I think) is to read up on maven
>>>> to see if you'd like to use it:
>>>> - http://maven.apache.org/
>>>> - http://maven.apache.org/guides/getting-started/index.html
>>>>
>>>> The second one listed above will run you through the overall concepts
>>>> and is quite helpful in introducing you to the various aspects of maven. Pay
>>>> particular attention to the links from that page (e.g., to the maven model -
>>>> which describes the various xml elements and what they do).
>>>>
>>>> Installing maven is simple. e.g., (for mac)
>>>> # install macports if not present already (macports.org)
>>>> $ sudo port -d selfupdate
>>>> $ sudo port install maven2
>>>>
>>>>> and use this project structure?
>>>>
>>>> The default project structure (as shown) is the recommended one. It's
>>>> the standard maven layout. The reasons for this is so that, from project to
>>>> project, any developer knows where to find things, where to put things -
>>>> whether familiar with WO or otherwise and also Maven's build system does
>>>> stuff by default (without need for further configuration) with these
>>>> files/resources when compiling/packaging/installing/testing etc.
>>>>
>>>> The mantra is standard conventions over configuration. [1]
>>>>
>>>> You can configure things (which I've done for transitioning) to work
>>>> with your current bunny layout. e.g., if you're just wanting to kick the
>>>> tyres so to speak. I'll write up how to do this on the wiki over the next
>>>> day or so. It's pretty simple.
>>>>
>>>> It's helpful to read [2] first to get the idea of things, but [3] shows
>>>> you how to configure things for your build.
>>>>
>>>>> Is it so that it builds your projects and apps with the right version
>>>>> of WO and other jars?
>>>>
>>>> It will build it with what you define, sure.
>>>>
>>>>> The deployed app will then use / include the version specified during
>>>>> the build? Is that what this is for?
>>>>
>>>> It will do that too. But this is not specifically what it's for as you
>>>> can do that already with ant or any other build system.
>>>>
>>>> [1] http://maven.apache.org/benefits-of-using-maven.html
>>>> [2]
>>>> http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
>>>> [3] http://maven.apache.org/ref/2.0.8/maven-model/maven.html
>>>>
>>>> with regards,
>>>> --
>>>>
>>>> Lachlan Deck
>>
>> with regards,
>> --
>>
>> Lachlan Deck
>>
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>>
>> This email sent to email@hidden
>>
>
> --
>
> Practical WebObjects - for developers who want to increase their overall
> knowledge of WebObjects or who are trying to solve specific problems.
> http://www.global-village.net/products/practical_webobjects
>
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden