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>
>>> 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.
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Wed Jul 09 2008 - 20:33:31 EDT