On Jul 9, 2008, at 11:20 AM, Pierce T. Wetter III wrote:
>
>>
>> Lets place the blame where the blame belongs and make a more honest
>> comparison. This is most NOT an Ant issue. It is a WOProject /
>> build philosophy issue. The duplication between .classpath and
>> some of the files in woproject/ are a deficiency in the woproject
>> Ant tasks in that they currently can't use what is in .classpath.
>> Mike is working on fixing this.
>
> Hmmm... That's interesting. It's very true that my main frustration
> has been that edits in Eclipse don't get reflected in the nightly
> build which is driven by Ant.
Yes, that really SUCKS right now. My hate for the woproject/ files
knows no limit.
> 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.
Using either Extensions directory is a sure fire recipe for versioning
nightmares. I prefer to bundle _everything_ into the app for most
situations (though Anjo pointed out where some very controlled sharing
can be a good thing). Dependancies be damned!
>> Now, what does maven do for this? Unless it is reading
>> the .classpath file, it also has to somehow, somewhere duplicate
>> the information that Eclipse uses. Duplication is duplication.
>> And will Eclipse update the Maven information in the pom.xml when
>> a new framework is added? When a new jar is added to the project?
>> Or is that all manual pom fiddling?
>
> maven works in reverse. I don't know anything about the Eclipse
> maven plugins yet, but I think that when you add dependencies to the
> pom, it generates an updated classpath for use with running/
> compiling in Eclipse. The upcoming m2eclipse plugin means you can
> edit the dependency in a GUI fairly efficiently. And unlike
> Eclipse's build path editor, using maven means it pulls in the
> dedpendencies of the dependencies as well. So actually slightly less
> duplication because you can say "hey, I need this framework",
> without having to know what that framework needs in turn.
I can see the advantage of that, but I would rather initiate this from
Eclipse so that I don't have to tool-hop. Less thinking better, less
chance for getting it wrong.
> In other words, if I'm interpreting things correctly, you set
> dependencies in a different place in Eclipse for maven-based
> projects, with the end result being no duplication because it uses
> maven to generate the build path for you.
It is still in two places then and edits in Eclipse can potentially
bring them out of sync.
>> The rest of the patternsets are also not an Ant issue, but a design
>> philosophy in woproject (to not force a project layout). If you do
>> use a project layout, as Wonder does, these can easily be rendered
>> unnecessary.
>
> Yeah, same recipe same bread thing again. If you standardize on a
> layout, life gets easier.
Agreed.
>> Finally, build.properties:
>>
>> principalClass=
>> project.name=
>> customInfoPListContent=
>> eoAdaptorClassName=
>> webXML=
>> webXML_CustomContent=
>> classes.dir=
>>
>> If Maven does not use these and does not have a parallel system,
>> then it has less flexibility.
>
> 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).
> 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. :-)
>> How would Maven handle it if the package name for the Application
>> were changed in Eclispe?
>
> Well, that would be a maven/Eclipse/wolifecycle-plugin integration
> issue, so I'm not sure. I'm not sure where it gets that information
> at the moment as its not specified in the pom. Oh, I remember,
> there's an Info.plist file. Which seems natural to me as a Cocoa
> programmer, but I guess WOProject must generate that for you from
> build.properties.
Yes. It also used build.properties when generating the script that
wotaskd uses to launch the app.
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 : Wed Jul 09 2008 - 14:39:04 EDT