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 <maven...@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-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Reply via email to