> -----Original Message-----
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: lundi 25 avril 2005 10:08
> To: Maven Developers List
> Subject: Re: [m2] Jar aggregation use case (was RE: cvs commit: maven-
> components/maven-plugins/maven-assembly-
> plugin/src/main/resources/assemblies jar-with-dependencies.xml)
>
>
> >I agree that having different ways to distribute one's code is bad. I
> only
> >want 1 way for Cargo: one JAR which is the aggregation of the 3
> individual
> >JARs. User don't see the individual jars (they are private artifacts).
> >
> >Actually and coincidentally Milos sent an email yesterday on the Cargo
> >mailing list reporting that he had found the error why his cargo
> integration
> >in mevenide wasn't working. That's because he was using the individual
> Cargo
> >jars (which he got from building cargo from the sources and not from the
> >distribution) instead of the unique cargo jar and there was a classloader
> >issue... ;-)
> >
> >
> >
> This says to me that you either need to make the 3-jar use case
> workable, or put them back together if they don't really work on their
> own :)
>
> I understand you want to keep them separate from a design perspective,
> but there are other tools to help with that (eg jdepend).
Come on! I'd like to see someone who's using jdepend in real... :-) Also,
jdepend does not enforce anything.
I understand you're trying to figure good alternatives to this aggregated
jar use case but jdepend isn't a good one... :-)
Putting the jars together is not good because:
1/ by separating them is has allowed us to flush out dependency issues that
we wouldn't have discovered otherwise (yes, we were generating the jdepend
reports but as it's not enforcing anything it's really not useful).
2/ As I mentioned we want to keep the possibility in the future to release
those jars separately (for example either when users request it or when the
aggregated jar becomes too big).
BTW, ATM we have only a single core/container project but we're planning to
have:
core/
|_ util/
|_ module/
|_ container/
|_ common/
|_ tomcat/
|_ orion/
|_ resin/
|_ [...]
Initially we'll still want to distribute a single jar for all this but as
container support expand we'll want to possibly distribute container support
separately (even possibly aggregate util+module+specific container -
Although we haven't thought about this yet).
Why do we want to separate them?
Once more to ensure a proper compartmentalization but also to make it easy
to test each container: Instead of having a single sample/java project that
iterates over all containers we would have a watchdog maven plugin and we
will apply it to each container/* project when running (m2 test).
BTW, this will require the ability to dynamically include/exclude m2 modules
according to a configuration. As a builder, I need to say in my profile that
I want to build for, say, resin and tomcat but not for any other containers
(because I don't have them installed for example). How will I be able to
specify this? :-)
[snip]
> >- no checkstyle plugin so I can't make the build fail upon checkstyle
> errors
> >
> >
> I'd hardly call this a blocker... :)
It depends what you call "blocking". For me nothing is blocking because
Cargo already has a working m1 build. However, what I call "blocking" is
anything that prevents my m2 build to be doing the same build actions as I'm
currently doing with m1. Currently the m1 build breaks the build if a
checkstyle error is encountered. It's a "blocker" because I couldn't switch
the build over to m2 because of this for example (amongst other things).
[snip]
> You can start doing so if you like... snapshots work very nicely now :)
Hmm... Is there a maven2 repository @ codehaus now?
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
