>>
>>
>> I'm a big picture guy, so worrying about what folders should be
>> named is
>> way too much a detail to bother me.
>
> Sorry if I wasn't clear enough about that. I'm talking about more than
> the standard directory layout. Maven enforce some "best practices". If
> you don't like one of its "best practices" you will probably start
> criticizing Maven because it is difficult or impossible to do in a
> different way. It is not lack of flexibility. It is a proposed way to
> develop software.
Hmm... That's interesting.
>
>
> For example, if one of your tests don't pass, the build fails.
Ah, but presumably if I'm using TestNG (and why wouldn't you, it
rocks), I could deal with
that by changing TestNG's config file. :-)
> If you
> want to add a dependency to your project, you must use a repository
> (you can't add the jar to your project and write some configuration
> into your pom.xml).
I already mandated the use of a Jars Framework for just this reason.
> You can't release a project if it has a SNAPSHOT
> (under development) version of a dependency. These kind of
> "restriction" seems like a huge problem for some people.
That one seems weird.
>
>
> The examples have not do with the standard directory layout.
Er, Typo? The examples were not done with the standard directory
layout?
>
>
>>
>> So with maven, if I buy into the philosophy that inside each
>> project, all
>> of my files should be laid out with a certain structure, and it
>> should be
>> the same for all projects, and it should be the same for all WO
>> developers
>> everywhere, my life will be easier.
>
> Yes. This is a good start. :)
>
>>
>> Now in addition to all that, Java has this whole issue with
>> classpaths that
>> sucks. Eclipse hides a lot of the pain and suffering from you, but
>> once you
>> do a deployment, surprise, you're missing foo.jar! So maven has
>> some kind of
>> magic for dealing with this as well, something I don't understand
>> yet.
>
> Dependency Management + Repository Managers = Magic.
Or, in English, with Maven you can say "I'm using Apache Commons
Logging". Then instead of spending 20 minutes Googling for what the
latest version is, finding out that the .tar.gz version in corrupt so
you have to download the .zip version... rather mvn it will find it
and shove it into your ~/.m2 folder when it does the build.
More importantly, when someone says "hey, we should use the never
version of commons-logging", the nightly build system will suck in the
updated files.
> You can also
> achieve this kind of magic using Ant+Ivy [1] as mentioned by Chuck.
The Ivy reports look cool, but at the end of the day its all:
XML ---> [ MAGIC BOX ] ---> Build
Ivy is just another flavor of magic box. And I hate Ant, so Ivy is
guilty by association.
>
>
>> But it might solve that annoying problem, hallelujah. But its not
>> clear to me if
>> I can setup the dependencies in a GUI with Eclipse or if I have to
>> edit the
>> pom.xml.
>
> Not often. There is no 1.0 plug-in for Maven integration with Eclipse.
> So, you can suspect that some features are missing. Both plug-ins
> (m2eclipse [2] and q4e [3]) have wizards to add dependencies to your
> project. But it doesn't work every time. There is no visual editor for
> the pom.xml. But the Eclipse XML Tools can help with the autocomplete
> feature.
Can you use both or do you have to choose one or the other?
>
>
> You can also use mvnrepository [4] to search for dependencies deployed
> on Central Maven Repository.
Making stuff like using Apache Commons Logging even easier, I
suspect.
>
>
>>
>> So...lets say I want to buy into maven. Lets say I want to do the
>> absolute
>> minimum amount of pom.xml hacking (though GUI editing in eclipse is
>> ok). Are
>> those steps documented anywhere?
>
> The current Maven documentation to develop WebObjects applications was
> referenced in my first e-mail.
Yeah, as I said I read that, but that seems to assume you're making
a new project rather then migrating an existing project to maven. Or
are you implying the best way to migrate an old project is to generate
a new project, then move the old project files into the new locations?
I could see that, though of course it would give the source control
system fits, so what I really need to do is make a new Maven
WebObjects application, then copy files from it to the old project,
and issue "svn mv" commands as appropriate until the old project
structure mirrors the new layout.
> I think everybody will be happy if you
> start using Maven and help us to write more documentation.
Does asking dumb questions count as helping? :-)
Ok, I'll see about writing a "Maven for Lazy Noobs" document if I
can get something working.
>
>
>> So its seems like I'm half right. WOLips & Wonder are migrating to
>> FBL. The
>> maven plugins have their own layout, and in Wonder use pom.xml
>> instructions
>> so that maven groks FBL. Presumably, I could look at the Wonder
>> sources
>> (when maven builds are working again) and come up with an fbl.xml
>> that I
>> could use in all my project pom.xml files. If I did that, I could
>> migrate to
>> maven with a minimum of fuss.
>
> Not so easy. Lachlan have described his problems while starting to use
> Maven on "WebObjects Nightly Builds and WOLips addition" thread
> (referenced by Andrus). Besides, as WOLips and Wonder was not
> developed with Jar dependencies in mind, you may find some
> bugs/restrictions. Lachlan have already fixed some of them.
Er, I made it a point to read that entire thread. I think Lachlan
goes into less detail then you might think. :-)
Pierce
This archive was generated by hypermail 2.0.0 : Wed Jul 02 2008 - 20:00:52 EDT