Hah. I spoke too soon. I just thought about it and using shade would be very dangerous because of possible class collisions. Let me modify my statement to never do this for anything that will ever be consumed by another build.
Thanks, Roy Lyons Senior Configuration Engineer On 10/12/12 2:06 PM, "Lyons, Roy" <roy.ly...@cmegroup.com> wrote: >John, > >That is a pretty good observation. > >My assumption (even though assuming anything can be fatal) is that the >resulting project was a top tier application -- one which would not be >subjected to being consumed by another application as a library. > >I am in full agreement that this is not a valid method when generating >anything other than an artifact which is not consumed by a subsequent >maven build. > >The best way to achieve the same results in an item which is consumed >would be to have a separate project which would consume the original >artifact, and use the shade plugin to unpack it and the additional >dependencies into a completely different artifact (artifactId being >different). This is of course also assuming that you aren't changing the >compilation of your classes based on the presence of these other >libraries. > > >Thanks, > >Roy Lyons >Senior Configuration Engineer > > > > > > >On 10/12/12 12:25 PM, "John Kramer" <jkra...@mojiva.com> wrote: > >>Not that I'm an expert, but I thought the rule of thumb was this: >> >>Never use profiles in such a way that different profiles build different >>versions of artifacts with the same id. >> >>I always restricted my use of profiles to activities such as deployment >>or >>testing that didn't affect the artifacts being built. >> >>This use seems like it could lead to some dependency issues. >> >>If you disagree, please explain your reasoning. >> >> >>John Kramer >>email: jkra...@mojiva.com >>mobile: 314.435.2370 >>skype: kramer.mojiva >>twitter: @KramerKnowsTech <https://twitter.com/KramerKnowsTech> >>0xCAFEBABE00000032 >> >> >> >> >> >> >> >>On 10/12/12 10:37 AM, "Lyons, Roy" <roy.ly...@cmegroup.com> wrote: >> >>>I would approach this as an acceptable use of a profile. Make a profile >>>with these dependencies defined. If you activate the profile, they will >>>all be added. If you don¹t activate the profile, none will be added. >>> >>>This should fix your issues. >>> >>>Thanks, >>> >>>Roy Lyons >>>Senior Configuration Engineer >>> >>>From: Stefan Rademacher <rademac...@hhla.de<mailto:rademac...@hhla.de>> >>>Reply-To: "'users@maven. org'" >>><users@maven.apache.org<mailto:users@maven.apache.org>> >>>Date: Friday, October 12, 2012 6:52 AM >>>To: "'users@maven. org'" >>><users@maven.apache.org<mailto:users@maven.apache.org>> >>>Subject: Antw: Re: Re: Corrupted Assembly, when using a type:pom >>>dependency >>> >>>Hi Curtis, >>> >>>yes, that's right. I want do declare a set of dependencies, which always >>>must be used "all" or "none". That why I encapsulate those dependencies >>>in a separate pom and reference it with a type=pom dependency. >>> >>>I didn't know about this scope "import" before and found your link very >>>infomative! Thanks! >>>Unfortunately, the assembly still gets corrupted, as soon as I have a >>>type=pom dependency in my configuration... with or without scope=import. >>> >>>Any other suggestions? >>> >>>Regards, >>>Stefan >>> >>> >>>>>> Curtis Rueden <ctrue...@wisc.edu<mailto:ctrue...@wisc.edu>> >>>>>>11.10.2012 18:05 >>> >>>Hi Stefan, >>> >>>> <dependency> >>>> <groupId>de.hhla.test</groupId> >>>> <artifactId>test.assembly.core</artifactId> >>>> <version>0.0.1-SNAPSHOT</version> >>>> <type>pom</type> >>>> </dependency> >>> >>>Personally, I have never used a dependency of type pom. But according to >>>the Maven docs, the main use case for it is as a shortcut to import a >>>group >>>of dependencies transitively from that POM project. But in that case, >>>you >>>would declare that dependency with scope "import"; see: >>> >>>http://maven.apache.org/guides/introduction/introduction-to-dependency-m >>>e >>>c >>>hanism.html#Importing_Dependencies >>> >>>Is that what you are trying to do? If you use scope import, does the >>>problem go away? If scope import is not what you want, I am curious why >>>you >>>are using a dependency of type pom. >>> >>>Regards, >>>Curtis >>> >>> >>>On Thu, Oct 11, 2012 at 3:53 AM, Stefan Rademacher >>><rademac...@hhla.de<mailto:rademac...@hhla.de>>wrote: >>> >>>> Sorry, I didn't notice, that my original posting wasn't attached to >>>>my >>>> last email. >>>> Here is again, what I asked few weeks ago. Can anyone help me with >>>>this? >>>> --- >>>> >>>> Hi all, >>>> >>>> I want to create an assembly, using a moduleSet. With the following >>>> (simplified) example, I select a certain artifact, define the output >>>>directory >>>> and provide a naming pattern. >>>> <assembly> >>>> <id>distribution</id> >>>> <formats> >>>> <format>zip</format> >>>> </formats> >>>> <moduleSets> >>>> <moduleSet> >>>> <useAllReactorProjects>true</useAllReactorProjects> >>>> <includes> >>>> <include>${artifact.groupId}:test.assembly.server</include> >>>> </includes> >>>> <binaries> >>>> <outputDirectory>.</outputDirectory> >>>> <unpack>false</unpack> >>>> <outputFileNameMapping>${module.artifactId}.${module.extension} >>>> </outputFileNameMapping> >>>> </binaries> >>>> </moduleSet> >>>> </moduleSets> >>>> </assembly> >>>> >>>> The module I select in this assembly.xml contains one dependency: >>>> <dependency> >>>> <groupId>de.hhla.test</groupId> >>>> <artifactId>test.assembly.core</artifactId> >>>> <version>0.0.1-SNAPSHOT</version> >>>> <type>pom</type> >>>> </dependency> >>>> >>>> The resulting assembly is unusable, as soon as the following two >>>>conditions are >>>> true: >>>> - The module has a dependency with <type>pom</type> >>>> AND >>>> - The outputDirectory of the moduleSet is "." >>>> >>>> In this case, the resulting assembly (e. g. zip file) looks like this: >>>> ZIP >>>> | >>>> |-- "" >>>> | |-- test.assembly.server.jar >>>> | >>>> |-- test.assembly.server.jar >>>> >>>> The file "test.assembly.server.jar", which is contained in that >>>>directory with >>>> an empty name, is not actually a jar, but the POM of the dependency, >>>>which I >>>> specified with <type>pom</type> !!! That's totally weird, isn't it? >>>> Extracting this zip structure leads to a corrupted >>>>"test.assembly.server.jar", >>>> because the first jar in the dir with no name (which actually is an >>>>XML >>>>file) >>>> overwrites the correct jar at the actual root level of the zip file. >>>> >>>> Another hint is this debug output of the assembly plugin: >>>> [DEBUG] Adding file: C:\Dokumente und >>>> >>>>Einstellungen\<user>\.m2\repository\de\hhla\test\test.assembly.core\0.0 >>>>. >>>>1 >>>>-SNAPSHOT\test.assembly.core-0.0.1-SNAPSHOT.pom >>>> to archive location: TEST_0.0.1-SNAPSHOT//test.assembly.server.jar >>>> (Please notice the two slashes in the destination path.) >>>> >>>> Is this already a known issue or should I file a bug? >>>> >>>> Thanks and best regards, >>>> Stefan >>>> >>>> --- >>>> >>>> Thanks and best regards >>>> Stefan >>>> >>>> >>>> >>> tobias maslowski >>>><tobiasmaslow...@gmail.com<mailto:tobiasmaslow...@gmail.com>> >>>>08.10.2012 >>>>11:45 >>> >>>> >>>> You probably should provide some information about your problem, like >>>>what >>>> you tried to do, the setup ... >>>> >>>> Anyway there are a few issues in the tracker, maybe you stumbled >>>>accross >>>> http://jira.codehaus.org/browse/MASSEMBLY-609? >>>> >>>> 2012/10/8 Stefan Rademacher >>>><rademac...@hhla.de<mailto:rademac...@hhla.de>> >>>> >>>> > Hi, >>>> > >>>> > is there nobody, who can confirm, if this is a known issue? >>>> > >>>> > Thanks, >>>> > Stefan >>>> > >>>> > >>>> > >>>>--------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: >>>>users-unsubscr...@maven.apache.org<mailto:users-unsubscribe@maven.apach >>>>e >>>>. >>>>org> >>>> > For additional commands, e-mail: >>>>users-h...@maven.apache.org<mailto:users-h...@maven.apache.org> >>>> > >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: >>>>users-unsubscr...@maven.apache.org<mailto:users-unsubscribe@maven.apach >>>>e >>>>. >>>>org> >>>> For additional commands, e-mail: >>>>users-h...@maven.apache.org<mailto:users-h...@maven.apache.org> >>>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>For additional commands, e-mail: users-h...@maven.apache.org >>> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>For additional commands, e-mail: users-h...@maven.apache.org >> >
