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.
> 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?
>(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?
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? :)
Cheers,
Henrique
This archive was generated by hypermail 2.0.0 : Wed Jul 09 2008 - 23:44:12 EDT