You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Dimitar Gospodinov <ma...@hotmail.com> on 2012/08/17 22:25:24 UTC
Classifier not added to artifact when building module
Hi,
I have a project that consists of 3 modules:
- P1
- sample
- distribution
'P1' is built first, then 'sample' and finally 'distribution'.
'P1' has Jar packing and additional artifact of type ZIP.
'sample' also has Jar packing and an additional ZIP artifact.
The purpose of the 'distribution' module is simply to create a ZIP containing the ZIP artifacts from 'P1' and 'sample'.
'distribution' has 'P1' and 'sample' as dependencies.
The project uses 2 profiles - 'release' and 'debug', with 'release' being the default profile.
Everything works Ok in the 'release' profile.
When issuing 'mvn package -P debug' the build fails in the assembly plug-in with this error:
[ERROR] Failed to execute goal on project distribution: Could not resolve dependencies for project com.test:distribution:jar:1.0.0-SNAPSHOT: Could not find arti
fact com.test:sample:zip:debug:1.0.0-SNAPSHOT -> [Help 1]
If line 31, "<classifier>${buildClassifier}</classifier>" in the file distribution/pom.xml is commented out, the build is successful.
However if you examine the content of distribution-1.0.0-SNAPSHOT.zip, you will see that it contains sample-1.0.0-SNAPSHOT.zip and there is not such file anywhere in the file system.
It looks like the attached artifact classifier was not added for some reason, when creating the dependency on the 'sample' project.
If you examine the output for the 'sample' module (directory sample/target-debug/) you will see file sample-1.0.0-SNAPSHOT-debug.zip, which is correct.
If you compare sample-1.0.0-SNAPSHOT-debug.zip and sample-1.0.0-SNAPSHOT.zip (from distribution-1.0.0-SNAPSHOT.zip), they have exact same content.
Also note, that everything works Ok for the 'P1' module - 'distribution' has exact same type of dependency on 'P1' as on 'sample'.
Does anybody know what the problem is here?
Attached is the project in question - mvn-test.zip.
log.txt is the output from invoking 'mvn package -P debug -X' where the above mentioned error is shown.
Thank you,
Dimitar
Re: Classifier not added to artifact when building module
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 21/08/2012 7:28 AM, Dimitar Gospodinov wrote:
> Thank you for the suggestion, but this does not help and explain why it works once and does not work second time.
That is one of the nice things about profiles.
If you enjoy challenges and mysteries, profiles can provide that for
you, in an otherwise fairly dull and predictable development system.
Wayne's suggestion really does help if you follow it.
I have never used profiles but from the traffic in this forum, it
appears that they border on the "intrinsically evil" and should be
avoided unless you have lots of time to waste and no deadlines to meet.
It appears that there are a few valid use cases for profiles.
However, people are usually trying to do something else with them that
causes endless grief until they stop.
If Wayne suggests that you are in the situation of misusing profiles,
you probably should stop.
It is unlikely that you will get better advice here.
Ron
>
>
>> Date: Mon, 20 Aug 2012 11:20:59 -0500
>> Subject: Re: Classifier not added to artifact when building module
>> From: waynefay@gmail.com
>> To: users@maven.apache.org
>>
>>> The project uses 2 profiles - 'release' and 'debug', with 'release' being
>>> the default profile.
>> ...
>>> Does anybody know what the problem is here?
>> Find a way to do what you need without involving a profile (more
>> modules is the general approach rather than profiles) and things will
>> most likely work better for you.
>>
>> Wayne
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Classifier not added to artifact when building module
Posted by Dimitar Gospodinov <ma...@hotmail.com>.
Thank you for the suggestion, but this does not help and explain why it works once and does not work second time.
> Date: Mon, 20 Aug 2012 11:20:59 -0500
> Subject: Re: Classifier not added to artifact when building module
> From: waynefay@gmail.com
> To: users@maven.apache.org
>
> > The project uses 2 profiles - 'release' and 'debug', with 'release' being
> > the default profile.
> ...
> > Does anybody know what the problem is here?
>
> Find a way to do what you need without involving a profile (more
> modules is the general approach rather than profiles) and things will
> most likely work better for you.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: Classifier not added to artifact when building module
Posted by Wayne Fay <wa...@gmail.com>.
> The project uses 2 profiles - 'release' and 'debug', with 'release' being
> the default profile.
...
> Does anybody know what the problem is here?
Find a way to do what you need without involving a profile (more
modules is the general approach rather than profiles) and things will
most likely work better for you.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Classifier not added to artifact when building module
Posted by Stephen Connolly <st...@gmail.com>.
On 22 August 2012 13:06, Stephen Connolly
<st...@gmail.com>wrote:
> You could add a second execution of the compiler, resources, etc plugins
> with an alternative output directory... but that way madness lies.
>
> A far far better approach is to just build your jars with the debug info
> present always.
>
> The use a separate tool to strip the debug info from the jars that you
> release to end users. For example pack200 has the --strip-debug option, or
> you could write your own debug info stripper using ASM (
> http://www.java2s.com/Open-Source/Java/Byte-Code/asm/org/objectweb/asm/optimizer/ClassOptimizer.java.htm
> )
>
> http://download.forge.objectweb.org/asm/asm4-guide.pdf page 22
Quite trivial!
> Thus what you are doing is having one artifact that is definitive
> throughout your development and test process and then by a verifiable final
> step transforming it into the final released artifact. That will greatly
> reduce the opportunity for human error and bugs escaping
>
> -Stephen
>
>
> On 22 August 2012 12:25, Dimitar Gospodinov <ma...@hotmail.com> wrote:
>
>>
>>
>> Hi,
>>
>> Thank you for the advises.
>>
>> I am new to Maven and profiles was my first shot at the problem of
>> generating release and debug versions of the code.
>> By using classifiers, my expectation was, I will be able to tell what
>> came from where and how was it built.
>>
>> I tried to generate release and debug versions in the same build, but it
>> looked like that is not possible.
>> I did not see a way to compile exact same sources (Java), with different
>> compiler options.
>>
>> What I am trying to achieve is produce two versions of the exact same
>> code, compiled with different parameters. If this can be done in the same
>> build, it will actually be better.
>> Other than using separate POM-s, I do not see any other way how this can
>> be done (removing profiles completely).
>> Is there a way?
>>
>> Thank you,
>>
>> Dimitar
>>
>>
>>
>> > Date: Tue, 21 Aug 2012 14:43:36 +0100
>> > Subject: Re: Classifier not added to artifact when building module
>> > From: stephen.alan.connolly@gmail.com
>> > To: users@maven.apache.org
>> >
>> > Rule #1. One consumable artifact per module
>> > Rule #2. Active profiles should not affect the generated artifacts.
>> >
>> > You are breaking both rules.
>> >
>> > w.r.t. Rule #1
>> >
>> > You generate an assembly and a .jar from the same module... Much pain
>> will
>> > ensue.
>> >
>> > There are some circumstances where this rule seems to be broken, for
>> > example generating a javadocs artifact, a sources artifact, a src
>> > distribution of the module (i.e. a complete buildable zip of the
>> source)...
>> > in these cases the attached artifacts are incidental to the build....
>> this
>> > is why I added the word "consumable" to the way most people state rule
>> 1.
>> > The javadocs, etc are not consumed by any other modules... therefore
>> they
>> > do not get in the way.
>> >
>> > w.r.t. Rule #2
>> >
>> > You generate different artifacts depending on which profile is active...
>> > and I am going to take a wild stab in the dark and bet that the
>> contents of
>> > these different artifacts differs.
>> >
>> > Never mind what you think is supposed to happen when multiple profiles
>> are
>> > active!
>> >
>> > mvn -Prelease,debug
>> >
>> > That will do exactly what?
>> >
>> > If you insist on generating debug versions of the jars, etc... then your
>> > build should *always* generate those artifacts in addition to the
>> release
>> > versions.
>> >
>> > The other side of Rule #2 is that the artifact contents should be
>> identical
>> > irrespective of the profiles activated (this is where lots of people
>> abuse
>> > profiles by changing the database that their webapp points to when the
>> use
>> > different profiles)
>> >
>> > Active profile information is not part of the record that gets deployed
>> to
>> > the maven repo (local or remote) so you loose all tracability of what
>> > profiles were active when your artifact was built and deployed to the
>> maven
>> > repo... much fun ensues.
>> >
>> > Keep your life simple. Follow the rules.
>> >
>> > -Stephen
>> >
>> > On 17 August 2012 21:25, Dimitar Gospodinov <ma...@hotmail.com>
>> wrote:
>> >
>> > > Hi,
>> > >
>> > > I have a project that consists of 3 modules:
>> > > - P1
>> > > - sample
>> > > - distribution
>> > >
>> > > 'P1' is built first, then 'sample' and finally 'distribution'.
>> > >
>> > > 'P1' has Jar packing and additional artifact of type ZIP.
>> > > 'sample' also has Jar packing and an additional ZIP artifact.
>> > >
>> > > The purpose of the 'distribution' module is simply to create a ZIP
>> > > containing the ZIP artifacts from 'P1' and 'sample'.
>> > > 'distribution' has 'P1' and 'sample' as dependencies.
>> > >
>> > > The project uses 2 profiles - 'release' and 'debug', with 'release'
>> being
>> > > the default profile.
>> > > Everything works Ok in the 'release' profile.
>> > >
>> > > When issuing 'mvn package -P debug' the build fails in the assembly
>> > > plug-in with this error:
>> > >
>> > > [ERROR] Failed to execute goal on project distribution: Could not
>> resolve
>> > > dependencies for project com.test:distribution:jar:1.0.0-SNAPSHOT:
>> Could
>> > > not find arti
>> > > fact com.test:sample:zip:debug:1.0.0-SNAPSHOT -> [Help 1]
>> > >
>> > > If line 31, "<classifier>${buildClassifier}</classifier>" in the file
>> > > distribution/pom.xml is commented out, the build is successful.
>> > > However if you examine the content of
>> distribution-1.0.0-SNAPSHOT.zip, you
>> > > will see that it contains sample-1.0.0-SNAPSHOT.zip and there is not
>> such
>> > > file anywhere in the file system.
>> > > It looks like the attached artifact classifier was not added for some
>> > > reason, when creating the dependency on the 'sample' project.
>> > > If you examine the output for the 'sample' module (directory
>> > > sample/target-debug/) you will see file
>> sample-1.0.0-SNAPSHOT-debug.zip,
>> > > which is correct.
>> > > If you compare sample-1.0.0-SNAPSHOT-debug.zip and
>> > > sample-1.0.0-SNAPSHOT.zip (from distribution-1.0.0-SNAPSHOT.zip),
>> they have
>> > > exact same content.
>> > >
>> > > Also note, that everything works Ok for the 'P1' module -
>> 'distribution'
>> > > has exact same type of dependency on 'P1' as on 'sample'.
>> > >
>> > > Does anybody know what the problem is here?
>> > >
>> > > Attached is the project in question - mvn-test.zip.
>> > > log.txt is the output from invoking 'mvn package -P debug -X' where
>> the
>> > > above mentioned error is shown.
>> > >
>> > > Thank you,
>> > >
>> > > Dimitar
>> > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: users-help@maven.apache.org
>> > >
>>
>>
>
>
Re: Classifier not added to artifact when building module
Posted by Stephen Connolly <st...@gmail.com>.
You could add a second execution of the compiler, resources, etc plugins
with an alternative output directory... but that way madness lies.
A far far better approach is to just build your jars with the debug info
present always.
The use a separate tool to strip the debug info from the jars that you
release to end users. For example pack200 has the --strip-debug option, or
you could write your own debug info stripper using ASM (
http://www.java2s.com/Open-Source/Java/Byte-Code/asm/org/objectweb/asm/optimizer/ClassOptimizer.java.htm
)
Thus what you are doing is having one artifact that is definitive
throughout your development and test process and then by a verifiable final
step transforming it into the final released artifact. That will greatly
reduce the opportunity for human error and bugs escaping
-Stephen
On 22 August 2012 12:25, Dimitar Gospodinov <ma...@hotmail.com> wrote:
>
>
> Hi,
>
> Thank you for the advises.
>
> I am new to Maven and profiles was my first shot at the problem of
> generating release and debug versions of the code.
> By using classifiers, my expectation was, I will be able to tell what came
> from where and how was it built.
>
> I tried to generate release and debug versions in the same build, but it
> looked like that is not possible.
> I did not see a way to compile exact same sources (Java), with different
> compiler options.
>
> What I am trying to achieve is produce two versions of the exact same
> code, compiled with different parameters. If this can be done in the same
> build, it will actually be better.
> Other than using separate POM-s, I do not see any other way how this can
> be done (removing profiles completely).
> Is there a way?
>
> Thank you,
>
> Dimitar
>
>
>
> > Date: Tue, 21 Aug 2012 14:43:36 +0100
> > Subject: Re: Classifier not added to artifact when building module
> > From: stephen.alan.connolly@gmail.com
> > To: users@maven.apache.org
> >
> > Rule #1. One consumable artifact per module
> > Rule #2. Active profiles should not affect the generated artifacts.
> >
> > You are breaking both rules.
> >
> > w.r.t. Rule #1
> >
> > You generate an assembly and a .jar from the same module... Much pain
> will
> > ensue.
> >
> > There are some circumstances where this rule seems to be broken, for
> > example generating a javadocs artifact, a sources artifact, a src
> > distribution of the module (i.e. a complete buildable zip of the
> source)...
> > in these cases the attached artifacts are incidental to the build....
> this
> > is why I added the word "consumable" to the way most people state rule 1.
> > The javadocs, etc are not consumed by any other modules... therefore they
> > do not get in the way.
> >
> > w.r.t. Rule #2
> >
> > You generate different artifacts depending on which profile is active...
> > and I am going to take a wild stab in the dark and bet that the contents
> of
> > these different artifacts differs.
> >
> > Never mind what you think is supposed to happen when multiple profiles
> are
> > active!
> >
> > mvn -Prelease,debug
> >
> > That will do exactly what?
> >
> > If you insist on generating debug versions of the jars, etc... then your
> > build should *always* generate those artifacts in addition to the release
> > versions.
> >
> > The other side of Rule #2 is that the artifact contents should be
> identical
> > irrespective of the profiles activated (this is where lots of people
> abuse
> > profiles by changing the database that their webapp points to when the
> use
> > different profiles)
> >
> > Active profile information is not part of the record that gets deployed
> to
> > the maven repo (local or remote) so you loose all tracability of what
> > profiles were active when your artifact was built and deployed to the
> maven
> > repo... much fun ensues.
> >
> > Keep your life simple. Follow the rules.
> >
> > -Stephen
> >
> > On 17 August 2012 21:25, Dimitar Gospodinov <ma...@hotmail.com>
> wrote:
> >
> > > Hi,
> > >
> > > I have a project that consists of 3 modules:
> > > - P1
> > > - sample
> > > - distribution
> > >
> > > 'P1' is built first, then 'sample' and finally 'distribution'.
> > >
> > > 'P1' has Jar packing and additional artifact of type ZIP.
> > > 'sample' also has Jar packing and an additional ZIP artifact.
> > >
> > > The purpose of the 'distribution' module is simply to create a ZIP
> > > containing the ZIP artifacts from 'P1' and 'sample'.
> > > 'distribution' has 'P1' and 'sample' as dependencies.
> > >
> > > The project uses 2 profiles - 'release' and 'debug', with 'release'
> being
> > > the default profile.
> > > Everything works Ok in the 'release' profile.
> > >
> > > When issuing 'mvn package -P debug' the build fails in the assembly
> > > plug-in with this error:
> > >
> > > [ERROR] Failed to execute goal on project distribution: Could not
> resolve
> > > dependencies for project com.test:distribution:jar:1.0.0-SNAPSHOT:
> Could
> > > not find arti
> > > fact com.test:sample:zip:debug:1.0.0-SNAPSHOT -> [Help 1]
> > >
> > > If line 31, "<classifier>${buildClassifier}</classifier>" in the file
> > > distribution/pom.xml is commented out, the build is successful.
> > > However if you examine the content of distribution-1.0.0-SNAPSHOT.zip,
> you
> > > will see that it contains sample-1.0.0-SNAPSHOT.zip and there is not
> such
> > > file anywhere in the file system.
> > > It looks like the attached artifact classifier was not added for some
> > > reason, when creating the dependency on the 'sample' project.
> > > If you examine the output for the 'sample' module (directory
> > > sample/target-debug/) you will see file
> sample-1.0.0-SNAPSHOT-debug.zip,
> > > which is correct.
> > > If you compare sample-1.0.0-SNAPSHOT-debug.zip and
> > > sample-1.0.0-SNAPSHOT.zip (from distribution-1.0.0-SNAPSHOT.zip), they
> have
> > > exact same content.
> > >
> > > Also note, that everything works Ok for the 'P1' module -
> 'distribution'
> > > has exact same type of dependency on 'P1' as on 'sample'.
> > >
> > > Does anybody know what the problem is here?
> > >
> > > Attached is the project in question - mvn-test.zip.
> > > log.txt is the output from invoking 'mvn package -P debug -X' where the
> > > above mentioned error is shown.
> > >
> > > Thank you,
> > >
> > > Dimitar
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
>
>
RE: Classifier not added to artifact when building module
Posted by Dimitar Gospodinov <ma...@hotmail.com>.
Hi,
Thank you for the advises.
I am new to Maven and profiles was my first shot at the problem of generating release and debug versions of the code.
By using classifiers, my expectation was, I will be able to tell what came from where and how was it built.
I tried to generate release and debug versions in the same build, but it looked like that is not possible.
I did not see a way to compile exact same sources (Java), with different compiler options.
What I am trying to achieve is produce two versions of the exact same code, compiled with different parameters. If this can be done in the same build, it will actually be better.
Other than using separate POM-s, I do not see any other way how this can be done (removing profiles completely).
Is there a way?
Thank you,
Dimitar
> Date: Tue, 21 Aug 2012 14:43:36 +0100
> Subject: Re: Classifier not added to artifact when building module
> From: stephen.alan.connolly@gmail.com
> To: users@maven.apache.org
>
> Rule #1. One consumable artifact per module
> Rule #2. Active profiles should not affect the generated artifacts.
>
> You are breaking both rules.
>
> w.r.t. Rule #1
>
> You generate an assembly and a .jar from the same module... Much pain will
> ensue.
>
> There are some circumstances where this rule seems to be broken, for
> example generating a javadocs artifact, a sources artifact, a src
> distribution of the module (i.e. a complete buildable zip of the source)...
> in these cases the attached artifacts are incidental to the build.... this
> is why I added the word "consumable" to the way most people state rule 1.
> The javadocs, etc are not consumed by any other modules... therefore they
> do not get in the way.
>
> w.r.t. Rule #2
>
> You generate different artifacts depending on which profile is active...
> and I am going to take a wild stab in the dark and bet that the contents of
> these different artifacts differs.
>
> Never mind what you think is supposed to happen when multiple profiles are
> active!
>
> mvn -Prelease,debug
>
> That will do exactly what?
>
> If you insist on generating debug versions of the jars, etc... then your
> build should *always* generate those artifacts in addition to the release
> versions.
>
> The other side of Rule #2 is that the artifact contents should be identical
> irrespective of the profiles activated (this is where lots of people abuse
> profiles by changing the database that their webapp points to when the use
> different profiles)
>
> Active profile information is not part of the record that gets deployed to
> the maven repo (local or remote) so you loose all tracability of what
> profiles were active when your artifact was built and deployed to the maven
> repo... much fun ensues.
>
> Keep your life simple. Follow the rules.
>
> -Stephen
>
> On 17 August 2012 21:25, Dimitar Gospodinov <ma...@hotmail.com> wrote:
>
> > Hi,
> >
> > I have a project that consists of 3 modules:
> > - P1
> > - sample
> > - distribution
> >
> > 'P1' is built first, then 'sample' and finally 'distribution'.
> >
> > 'P1' has Jar packing and additional artifact of type ZIP.
> > 'sample' also has Jar packing and an additional ZIP artifact.
> >
> > The purpose of the 'distribution' module is simply to create a ZIP
> > containing the ZIP artifacts from 'P1' and 'sample'.
> > 'distribution' has 'P1' and 'sample' as dependencies.
> >
> > The project uses 2 profiles - 'release' and 'debug', with 'release' being
> > the default profile.
> > Everything works Ok in the 'release' profile.
> >
> > When issuing 'mvn package -P debug' the build fails in the assembly
> > plug-in with this error:
> >
> > [ERROR] Failed to execute goal on project distribution: Could not resolve
> > dependencies for project com.test:distribution:jar:1.0.0-SNAPSHOT: Could
> > not find arti
> > fact com.test:sample:zip:debug:1.0.0-SNAPSHOT -> [Help 1]
> >
> > If line 31, "<classifier>${buildClassifier}</classifier>" in the file
> > distribution/pom.xml is commented out, the build is successful.
> > However if you examine the content of distribution-1.0.0-SNAPSHOT.zip, you
> > will see that it contains sample-1.0.0-SNAPSHOT.zip and there is not such
> > file anywhere in the file system.
> > It looks like the attached artifact classifier was not added for some
> > reason, when creating the dependency on the 'sample' project.
> > If you examine the output for the 'sample' module (directory
> > sample/target-debug/) you will see file sample-1.0.0-SNAPSHOT-debug.zip,
> > which is correct.
> > If you compare sample-1.0.0-SNAPSHOT-debug.zip and
> > sample-1.0.0-SNAPSHOT.zip (from distribution-1.0.0-SNAPSHOT.zip), they have
> > exact same content.
> >
> > Also note, that everything works Ok for the 'P1' module - 'distribution'
> > has exact same type of dependency on 'P1' as on 'sample'.
> >
> > Does anybody know what the problem is here?
> >
> > Attached is the project in question - mvn-test.zip.
> > log.txt is the output from invoking 'mvn package -P debug -X' where the
> > above mentioned error is shown.
> >
> > Thank you,
> >
> > Dimitar
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
Re: Classifier not added to artifact when building module
Posted by Stephen Connolly <st...@gmail.com>.
Rule #1. One consumable artifact per module
Rule #2. Active profiles should not affect the generated artifacts.
You are breaking both rules.
w.r.t. Rule #1
You generate an assembly and a .jar from the same module... Much pain will
ensue.
There are some circumstances where this rule seems to be broken, for
example generating a javadocs artifact, a sources artifact, a src
distribution of the module (i.e. a complete buildable zip of the source)...
in these cases the attached artifacts are incidental to the build.... this
is why I added the word "consumable" to the way most people state rule 1.
The javadocs, etc are not consumed by any other modules... therefore they
do not get in the way.
w.r.t. Rule #2
You generate different artifacts depending on which profile is active...
and I am going to take a wild stab in the dark and bet that the contents of
these different artifacts differs.
Never mind what you think is supposed to happen when multiple profiles are
active!
mvn -Prelease,debug
That will do exactly what?
If you insist on generating debug versions of the jars, etc... then your
build should *always* generate those artifacts in addition to the release
versions.
The other side of Rule #2 is that the artifact contents should be identical
irrespective of the profiles activated (this is where lots of people abuse
profiles by changing the database that their webapp points to when the use
different profiles)
Active profile information is not part of the record that gets deployed to
the maven repo (local or remote) so you loose all tracability of what
profiles were active when your artifact was built and deployed to the maven
repo... much fun ensues.
Keep your life simple. Follow the rules.
-Stephen
On 17 August 2012 21:25, Dimitar Gospodinov <ma...@hotmail.com> wrote:
> Hi,
>
> I have a project that consists of 3 modules:
> - P1
> - sample
> - distribution
>
> 'P1' is built first, then 'sample' and finally 'distribution'.
>
> 'P1' has Jar packing and additional artifact of type ZIP.
> 'sample' also has Jar packing and an additional ZIP artifact.
>
> The purpose of the 'distribution' module is simply to create a ZIP
> containing the ZIP artifacts from 'P1' and 'sample'.
> 'distribution' has 'P1' and 'sample' as dependencies.
>
> The project uses 2 profiles - 'release' and 'debug', with 'release' being
> the default profile.
> Everything works Ok in the 'release' profile.
>
> When issuing 'mvn package -P debug' the build fails in the assembly
> plug-in with this error:
>
> [ERROR] Failed to execute goal on project distribution: Could not resolve
> dependencies for project com.test:distribution:jar:1.0.0-SNAPSHOT: Could
> not find arti
> fact com.test:sample:zip:debug:1.0.0-SNAPSHOT -> [Help 1]
>
> If line 31, "<classifier>${buildClassifier}</classifier>" in the file
> distribution/pom.xml is commented out, the build is successful.
> However if you examine the content of distribution-1.0.0-SNAPSHOT.zip, you
> will see that it contains sample-1.0.0-SNAPSHOT.zip and there is not such
> file anywhere in the file system.
> It looks like the attached artifact classifier was not added for some
> reason, when creating the dependency on the 'sample' project.
> If you examine the output for the 'sample' module (directory
> sample/target-debug/) you will see file sample-1.0.0-SNAPSHOT-debug.zip,
> which is correct.
> If you compare sample-1.0.0-SNAPSHOT-debug.zip and
> sample-1.0.0-SNAPSHOT.zip (from distribution-1.0.0-SNAPSHOT.zip), they have
> exact same content.
>
> Also note, that everything works Ok for the 'P1' module - 'distribution'
> has exact same type of dependency on 'P1' as on 'sample'.
>
> Does anybody know what the problem is here?
>
> Attached is the project in question - mvn-test.zip.
> log.txt is the output from invoking 'mvn package -P debug -X' where the
> above mentioned error is shown.
>
> Thank you,
>
> Dimitar
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>