On Jul 9, 2008, at 8:43 PM, Henrique Prange wrote:
> Hi Chuck,
>
> Chuck Hill wrote:
>> On Jul 9, 2008, at 11:20 AM, Pierce T. Wetter III wrote:
>>> Well, really there are 3 issues for me:
>>>
>>> 1. Developer builds in Eclipse.
>>> 2. Nightly build done in Ant.
>>> 3. Production deployment ends up not matching because of Java/
>>> Extensions issues.
>>>
>>> Better Ant/Eclipse integration would fix #1/#2.
>> The Best Practice for #3 is to
>> (a) Never have anything in /Library/Java/Extensions (JDBC drivers
>> being a possible but unnecessary exception).
>> (b) rm /Library/WebObjects/Extensions after installing or updating WO
>> (c) put the jars you need in a framework (and maven that all you
>> want) and include that framework in the project that need the jars.
>
> IMHO, it seems like a workaround for those who don't have a
> dependency management mechanism. Not a best practice.
I don't see what a dependency management mechanism gets me over this.
What work does it save me? How much does it cost in terms of my time
fiddling with it?
>> Using either Extensions directory is a sure fire recipe for
>> versioning nightmares. I prefer to bundle _everything_ into the
>> app for most situations
>
> Including WebObjects libraries?
Yes.
>> (though Anjo pointed out where some very controlled sharing can be
>> a good thing). Dependancies be damned!
>>>
>>> However, sure, maven is much less "flexible" then Ant. You can
>>> call your "clean" target "trash" in Ant. Maven makes you call it
>>> "clean", with the theory that then anyone knows how to clean your
>>> projects without having to read any .xml files. Perhaps "clean" is
>>> a bad example, but with other Ant builds I've had to dive in and
>>> browse the targets to see whether the master target is "build",
>>> "all", "package", "deploy", etc.
>> Yes, that lack of standardization is a minor annoyance. But with
>> complex Maven builds, there can be a bewildering plethora of
>> options (goals and phases or whatever they call them).
>
> Can you give a more concrete example of complex Maven build?
The one for dbUnit, the last time I looked. Wandering though that,
trying to figure out which magic names I needed to use was no easier
than with Ant.
> Pierce started learning Maven with Wonder and have built it
> successfully. I have written the Maven configuration to build the
> GVCFrameworks and GVCSiteMaker some time ago. The Maven
> configuration to build both projects is straightforward.
>
>>> With all software design, the challenge is always flexibility vs.
>>> forcing the user to end up with a bunch of boilerplate. I always
>>> end up including my TestNG code in my master builds because I have
>>> no idea how to tell Ant not to include those files...
>> Not really that hard. I keep mine in a Tests/ directory with a
>> package structure parallel to src / Sources / whatever you are
>> calling it. Having the tests in the same package allows for the
>> tests to have access to internals that I would not want exposed.
>> Having them in a separate directory makes it easy to filter them
>> out of the final product. It is a good bread recipe. Try it, I
>> think you will like it. :-)
>
> This is the default behavior of Maven. Separate trees for main
> resources and test resources. By resources I mean sources,
> resources, eomodels, webserver-resources and any other kind of file.
> No test stuff on the final package. And no configuration to do this.
> Pretty good, huh? :)
Chuck
--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
This archive was generated by hypermail 2.0.0 : Thu Jul 10 2008 - 13:57:33 EDT