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)
> -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: mardi 26 avril 2005 03:17 > 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) [snip] > >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? :-) > > > > > I assume you are now talking about how you'd configure a Cactus plugin > such that the project specifies all of the containers, but the user only > builds one or two. Yes, we need profile support. Ok. http://jira.codehaus.org/browse/MNG-354 > > >>You can start doing so if you like... snapshots work very nicely now :) > >> > >> > > > >Hmm... Is there a maven2 repository @ codehaus now? > > > > > > > Equivalent to dist.codehaus.org? No, but let's discuss that on > [EMAIL PROTECTED] It would be good to have a plan for all the projects there. Just sent an email. Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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)
Vincent Massol wrote: >I understand you're trying to figure good alternatives to this aggregated >jar use case but jdepend isn't a good one... :-) > > I'm not trying to think of alternatives... I already agreed we probably want to implement the use case. I'm just trying to get to the bottom of why you think doing things two ways is a good idea. You've given reasons yourself that it is a bad idea. It's not just about functionality, but the best practices we recommend. >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? :-) > > I assume you are now talking about how you'd configure a Cactus plugin such that the project specifies all of the containers, but the user only builds one or two. Yes, we need profile support. >>You can start doing so if you like... snapshots work very nicely now :) >> >> > >Hmm... Is there a maven2 repository @ codehaus now? > > > Equivalent to dist.codehaus.org? No, but let's discuss that on [EMAIL PROTECTED] It would be good to have a plan for all the projects there. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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)
> -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]
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). >Fine. I'm not in dire need of this. I'm just using Cargo to test m2, see >what can be done with it right now and to what extent and possibly help >fine-tune m2. > > Sounds good. >To recap on Cargo's build, I'm currently blocked by 3 things: >- no aggregated jar > > Yep, I think we can target a resolution for this for alpha-3. Let's keep thinking about potential use cases. >- no checkstyle plugin so I can't make the build fail upon checkstyle errors > > I'd hardly call this a blocker... :) >- no EAR plugin so I can't build the sample testdata projects which prevents >me to move the sample projects' builds to m2 > > This shouldn't be too hard to write with maven-archiver. >Then there are second level features that I'm missing compared to the >existing build: >- no clover plugin >- no site but that's secondary because I use confluence for Cargo's web site > > alpha-2 will have site functionality. >Also, I haven't tried deploying to codehaus yet. > > You can start doing so if you like... snapshots work very nicely now :) Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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)
> -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: lundi 25 avril 2005 02:33 > 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) [snip] > >2/ I would like to possibly distribute the modules jar separately in the > >future but this is still unsure and we're not ready yet to do this. > > > > > > > But define "distribute". For Maven2 users, surely they only need to > depend on one of these and the others get pulled in by transitive > dependencies? Is anyone else using the aggregated JAR, or are they > downloading a tarball with all these JARs included? By distribute I mean to make available a single JAR file (instead of 3 jar files). > >I agree that it makes sense only at distribution time. However, I'm a bit > >hesitant to distribute a JAR that hasn't been tested... The individual > JARs > >would have been tested. I would be more confident if the samples/* > projects > >were exercising the aggregated JAR to be sure it's working fine. I think > >there might always be some classloaders issue that would make the > individual > >jars work but that would make the aggregated one fail. > > > > > Good point, but is also one of the reasons that I said adding different > ways to distribute your code may not always be a good idea. So you'll > want to be sure that there is a definite reason for this JAR to exist in > the first place. 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... ;-) > >I'm quite open on all this and it's probably a minor thing. I still think > we > >should allow an aggregated JAR to be produced when running "m2 install" > on a > >special pom packaging (like aggregated-jar). > > > > > I'd still like to ponder over this some more. If we do it for EARs, it > is probably reasonable for JARs too. This is on the list for alpha-2... > I think the lifecycle may consume too much time though, so let's slot it > in for first thing in alpha-3. > > They are really the main two design issues I think are still outstanding. Fine. I'm not in dire need of this. I'm just using Cargo to test m2, see what can be done with it right now and to what extent and possibly help fine-tune m2. To recap on Cargo's build, I'm currently blocked by 3 things: - no aggregated jar - no checkstyle plugin so I can't make the build fail upon checkstyle errors - no EAR plugin so I can't build the sample testdata projects which prevents me to move the sample projects' builds to m2 Then there are second level features that I'm missing compared to the existing build: - no clover plugin - no site but that's secondary because I use confluence for Cargo's web site Also, I haven't tried deploying to codehaus yet. Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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)
Vincent Massol wrote: >>In the case of building "core", it's type could be that of a specific >>aggregated JAR, so install would trigger the install for that. This >>should be how EARs work too, though I'm yet to put it into practice. >> >> > >Just to be sure I understand: Are you saying you are planning to support >creating an aggregated jar when calling "m2 install"? Or is it just an idea >that it could be supported but you're still unsure about the UC so you're >holding off for now? :-) > > The latter. I think it's more valid for an EAR, and to build a distribution of a multiproject - though I'm still unsure what is the best way to go with them. In the case of an EAR I think it makes sense rather than to create a subproject with dependencies. For a distribution, while I think it makes sense it worries me that it would bahve differently to when someone makes a distribution for a single product. > > > >>I'm still skeptical your use case below is a good idea. Every time you >>add a new different way of distributing your code, you add some >>confusion for your users. >> >>I presume there is a good reason you separated util, module and >>container - so why pull them back in together again? >> >> > >I've separated them for 2 reasons: >1/ to physically ensure that I have no dependencies in the direction util -> >module, util -> container and module -> container. > > sounds reasonable >2/ I would like to possibly distribute the modules jar separately in the >future but this is still unsure and we're not ready yet to do this. > > > But define "distribute". For Maven2 users, surely they only need to depend on one of these and the others get pulled in by transitive dependencies? Is anyone else using the aggregated JAR, or are they downloading a tarball with all these JARs included? >I agree that it makes sense only at distribution time. However, I'm a bit >hesitant to distribute a JAR that hasn't been tested... The individual JARs >would have been tested. I would be more confident if the samples/* projects >were exercising the aggregated JAR to be sure it's working fine. I think >there might always be some classloaders issue that would make the individual >jars work but that would make the aggregated one fail. > > Good point, but is also one of the reasons that I said adding different ways to distribute your code may not always be a good idea. So you'll want to be sure that there is a definite reason for this JAR to exist in the first place. > > >I'm quite open on all this and it's probably a minor thing. I still think we >should allow an aggregated JAR to be produced when running "m2 install" on a >special pom packaging (like aggregated-jar). > > I'd still like to ponder over this some more. If we do it for EARs, it is probably reasonable for JARs too. This is on the list for alpha-2... I think the lifecycle may consume too much time though, so let's slot it in for first thing in alpha-3. They are really the main two design issues I think are still outstanding. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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)
> -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: samedi 23 avril 2005 14:18 > 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) > > Vincent, > > In the case of building "core", it's type could be that of a specific > aggregated JAR, so install would trigger the install for that. This > should be how EARs work too, though I'm yet to put it into practice. Just to be sure I understand: Are you saying you are planning to support creating an aggregated jar when calling "m2 install"? Or is it just an idea that it could be supported but you're still unsure about the UC so you're holding off for now? :-) > I'm still skeptical your use case below is a good idea. Every time you > add a new different way of distributing your code, you add some > confusion for your users. > > I presume there is a good reason you separated util, module and > container - so why pull them back in together again? I've separated them for 2 reasons: 1/ to physically ensure that I have no dependencies in the direction util -> module, util -> container and module -> container. 2/ I would like to possibly distribute the modules jar separately in the future but this is still unsure and we're not ready yet to do this. > The only time I see > it making sense is as a distribution mechanism, in which case it is > usually auxiliary to the main build process (assembly/javaapp/etc). I agree that it makes sense only at distribution time. However, I'm a bit hesitant to distribute a JAR that hasn't been tested... The individual JARs would have been tested. I would be more confident if the samples/* projects were exercising the aggregated JAR to be sure it's working fine. I think there might always be some classloaders issue that would make the individual jars work but that would make the aggregated one fail. > One thing we have looked at is being able to depend on "core", and have > that pull in it's modules as dependencies. This would simplify your > dependency specification to the same level, without creating the > artificial need to produce a different JAR when you are using m2 to build. Yes, that would be cool in itself even though it doesnt address the issue of testing the JAR that will get distributed. > What do you think? I'm quite open on all this and it's probably a minor thing. I still think we should allow an aggregated JAR to be produced when running "m2 install" on a special pom packaging (like aggregated-jar). Thanks -Vincent > - Brett > > Vincent Massol wrote: > > >Hi Brett, > > > > > > > >>-Original Message- > >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >>Sent: lundi 18 avril 2005 09:08 > >>To: [EMAIL PROTECTED] > >>Subject: cvs commit: maven-components/maven-plugins/maven-assembly- > >>plugin/src/main/resources/assemblies jar-with-dependencies.xml > >> > >> > > > >[snip] > > > > > > > >> add ability to build a JAR with its dependencies unpacked inside. > >> > >> > > > >Cool. Just a question: In the cargo's build I have the following > structure: > > > >cargo/ > > |_ core/ > >|_ util/ > >|_ module/ > >|_ container/ > > |_ ant/ > > |_ samples/ > >|_ ant/ > >|_ java/ > > > >Ideally I would like that the core's pom.xml produces an aggregated jar > from > >util/, module/ and container/ and that the ant/, samples/ant/ and > >samples/java project have a single dependency on this aggregated jar. > > > >How would that work? If I type "m2 install" it will not produce the > >aggregated jar as I believe it'll be done during the assembly stage only, > >right? > > > >Of course, I could still have the other projects depend on the individual > >jars but then it's not as good as they won't exercise the generated jar. > > > >Any idea how this UC could be supported? > > > >[snip] > > > >Thanks > >-Vincent > > > >_ > > > >Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > > > >Yahoo! Mail : http://fr.mail.yahoo.com > > > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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)
Vincent, In the case of building "core", it's type could be that of a specific aggregated JAR, so install would trigger the install for that. This should be how EARs work too, though I'm yet to put it into practice. I'm still skeptical your use case below is a good idea. Every time you add a new different way of distributing your code, you add some confusion for your users. I presume there is a good reason you separated util, module and container - so why pull them back in together again? The only time I see it making sense is as a distribution mechanism, in which case it is usually auxiliary to the main build process (assembly/javaapp/etc). One thing we have looked at is being able to depend on "core", and have that pull in it's modules as dependencies. This would simplify your dependency specification to the same level, without creating the artificial need to produce a different JAR when you are using m2 to build. What do you think? - Brett Vincent Massol wrote: >Hi Brett, > > > >>-Original Message- >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>Sent: lundi 18 avril 2005 09:08 >>To: [EMAIL PROTECTED] >>Subject: cvs commit: maven-components/maven-plugins/maven-assembly- >>plugin/src/main/resources/assemblies jar-with-dependencies.xml >> >> > >[snip] > > > >> add ability to build a JAR with its dependencies unpacked inside. >> >> > >Cool. Just a question: In the cargo's build I have the following structure: > >cargo/ > |_ core/ >|_ util/ >|_ module/ >|_ container/ > |_ ant/ > |_ samples/ >|_ ant/ >|_ java/ > >Ideally I would like that the core's pom.xml produces an aggregated jar from >util/, module/ and container/ and that the ant/, samples/ant/ and >samples/java project have a single dependency on this aggregated jar. > >How would that work? If I type "m2 install" it will not produce the >aggregated jar as I believe it'll be done during the assembly stage only, >right? > >Of course, I could still have the other projects depend on the individual >jars but then it's not as good as they won't exercise the generated jar. > >Any idea how this UC could be supported? > >[snip] > >Thanks >-Vincent > >_ > >Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > >Yahoo! Mail : http://fr.mail.yahoo.com > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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)
Vincent Massol wrote on Monday, April 18, 2005 10:14 AM: > Hi Brett, > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Sent: lundi 18 avril 2005 09:08 >> To: [EMAIL PROTECTED] >> Subject: cvs commit: maven-components/maven-plugins/maven-assembly- >> plugin/src/main/resources/assemblies jar-with-dependencies.xml > > [snip] > >> add ability to build a JAR with its dependencies unpacked inside. > > Cool. Just a question: In the cargo's build I have the following > structure: > > cargo/ > |_ core/ > |_ util/ > |_ module/ > |_ container/ > |_ ant/ > |_ samples/ > |_ ant/ > |_ java/ > > Ideally I would like that the core's pom.xml produces an > aggregated jar from util/, module/ and container/ and that > the ant/, samples/ant/ and samples/java project have a single > dependency on this aggregated jar. > > How would that work? If I type "m2 install" it will not > produce the aggregated jar as I believe it'll be done during > the assembly stage only, right? > > Of course, I could still have the other projects depend on > the individual jars but then it's not as good as they won't exercise > the generated jar. > > Any idea how this UC could be supported? javaapp ? Seriously, this is the job of the javaapp in M1. With this possibility a port of javaapp to M2 is a little hollow if it just reuses the functionality of the jar plugin, but with the aggregated jar as main artifact. OTOH I currently don't know enough about the different artifact type support of M2, but I believe you can specify a dependency. All that is left to support this is, that the aggregated jar has a different artifact type. One question to Brett though: How does the aggregation work, if two dependent artifacts come with the same classes? The aggregation must ensure, that the same classes are available as it would have been using a normal classpath i.e. the aggragation may not overwrite classes already provided by another artifact in the dependency list. A use case is my current app, that is a standalone java app running in a server environment managed with JMX. Additionally it has to access EJBs provided by an app server. In my case I have to use jboss-client-3.2.3.jar as dependency for accessing the EJBs and mx4j--2.1.1.jar for the JMX functionality. Unfortunately jboss-client-3.2.3.jar contains also a subset (!) of the classes defined by JSR3 and the app breaks if this dependency is in the classpath before the mx4j jars. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Jar aggregation use case (was RE: cvs commit: maven-components/maven-plugins/maven-assembly-plugin/src/main/resources/assemblies jar-with-dependencies.xml)
Hi Brett, > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: lundi 18 avril 2005 09:08 > To: [EMAIL PROTECTED] > Subject: cvs commit: maven-components/maven-plugins/maven-assembly- > plugin/src/main/resources/assemblies jar-with-dependencies.xml [snip] > add ability to build a JAR with its dependencies unpacked inside. Cool. Just a question: In the cargo's build I have the following structure: cargo/ |_ core/ |_ util/ |_ module/ |_ container/ |_ ant/ |_ samples/ |_ ant/ |_ java/ Ideally I would like that the core's pom.xml produces an aggregated jar from util/, module/ and container/ and that the ant/, samples/ant/ and samples/java project have a single dependency on this aggregated jar. How would that work? If I type "m2 install" it will not produce the aggregated jar as I believe it'll be done during the assembly stage only, right? Of course, I could still have the other projects depend on the individual jars but then it's not as good as they won't exercise the generated jar. Any idea how this UC could be supported? [snip] Thanks -Vincent _ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
