On Jul 9, 2008, at 5:32 PM, Lachlan Deck wrote:
> On 10/07/2008, at 4:38 AM, Chuck Hill wrote:
>
>> On Jul 9, 2008, at 11:20 AM, Pierce T. Wetter III wrote:
>>
>>>> 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.
>
> edits in Eclipse == GUI tool for editing pom. i.e., adding lib or
> framework dependency has the effect of editing the pom.
> The .classpath file does not list these dependencies, just the
> container.
>
> cat /Users/ldeck/.eclipse33workspace/WOTestAppleMaven/.classpath
> <?xml version="1.0" encoding="UTF-8"?>
> <classpath>
> <classpathentry kind="src" path="src/main/java"/>
> <classpathentry kind="src" path="src/test/java"/>
> <classpathentry kind="src" path="src/main/resources"/>
> <classpathentry kind="src" path="src/main/webserver-resources"/>
> <classpathentry kind="src" path="src/test/resources"/>
> <classpathentry kind="src" path="src/main/components"/>
> <classpathentry kind="con"
> path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
> <classpathentry kind="con"
> path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/>
> <classpathentry kind="output" path="target"/>
> </classpath>
I like!
>>>> 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 be sure.
>
>>> 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. :-)
>
> Yep.
>
>>>> 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.
>
> I simply set the properties in maven that woproject needs. No ~/
> Library/wobuild.properties needed.
What about the things contained in the build.properties file in each
project? Does the Maven plugin use those files? That is one of the
files that Pierce was "counting".
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 - 20:39:45 EDT