On 09/07/2008, at 2:16 PM, Anjo Krank wrote:
> Thirdly from what I've seen, someone needs to change all these files
> whenever we bump a version. All of Ulrichs commits so far where
> these xml fixes. All *I* need to do is set one property.
Yep, I'm not sure why maven's pom insists on having the version of a
parent defined. I would have thought it could be inherited. Swings and
roundabouts.
> Fourth, adding a project typically requires five lines in Build/
> build/build.xml to add it to the correct group and some props. I
> might consider moving these props from the build file to a
> build.properties and making Build/build/build.xml only specify the
> inter-related deps.
>
> I'll grant you one point for the commons-logging versions, but I use
> neither ERJGroups or EROpenID. If I were and I'd be bothered, I'd
> figure out a way to keep them using only one.
>
> So far we've seen that maven is neither more terse nor more powerful
> (at least in a way that would mean something to me).
>
> The other issues I have with it is that I actually *need* the
> flexibility in deployment structure. In some projects I *don't* want
> all-embedded builds as that stuff goes out of hand with 7 apps*all
> the frameworks. The resulting release tops 250M. So I want some of
> them embed only some jars. Show me how this works with maven
> *without* writing any "goals" or "mojos".
Probably declaring the dependency with scope 'provided' rather than
'compile' will do it.
> So in summary, maven may or may not be nice. But I've been building
> Wonder with the build files for 7 years now and they haven't really
> changed a lot in this time. They do the roughly the same as some
> 20MB tool chain where you *still* have to write java plugins for.
>
> I'll leave the conclusions to you.
Both work.
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Wed Jul 09 2008 - 01:53:13 EDT