Different behavior when building a project as a module or "stand-alone"

[Philippe Lagardère <ph...@gmail.com>]

Hello,

When trying to set up an assembly for a project, I ran into a problem I
can't seem to find an explanation for.
My project has a basic multi-module structure, like this :



The thing is, I get two different results for executing /mvn clean package/,
whether I run it from /project-core/ or from /project/.

*From project-core*


*From project*


And indeed, the .jar is empty (safe a couple of metadata files), which cause
the build to fail on /project-web/, which depends on /project-core/

The main oddities I have set up for the build are :
 1) maven-dependency-plugin:purge-local-repository, executed at
/prepare-package/ for /project-core/ only
 2) maven-assembly-plugin:single, executed at /package/ for the web and
batch projects, but the global build fails before they even kick in ;)

I did not configure the /maven-jar-plugin/, so this is what I have in the
effective pom :



I'm using Maven 3.0.3, and a 1.6.0_24 JDK if it makes any difference.
Sorry if this problem is common knowledge, I just didn't know what to search
for in the mailing list !

Thank you !


Philippe

--
View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5607081.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Different behavior when building a project as a module or "stand-alone"

[Wayne Fay <wa...@gmail.com>]

> My project has a basic multi-module structure, like this :
>
> The thing is, I get two different results for executing /mvn clean package/,
> whether I run it from /project-core/ or from /project/.
>
> *From project-core*
>
> *From project*

Just an FYI. No one on the mailing list saw parts of what you posted,
probably because Nabble ate the XML or because this mailing list does
not support attachments.

Convert your email to 100% plain text and try again.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Different behavior when building a project as a module or "stand-alone"

[Wayne Fay <wa...@gmail.com>]

> Our project depends on various corporate libraries which are not
> "Mavenized". In order to use these libraries, we frequently use
> deploy:deploy-file to drop them on our repository, with a fixed version
> (given that new versions are duly tested and obsolete older versions).

I want to be sure that I understand what you are saying here. The
versions are DIFFERENT each time you run deploy-file, right? It is a
basic premise of Maven and most sane build systems that that a given
artifact with a particular version number must be immutable. Otherwise
you have no idea if your file versioned 2.3.2 is the "right one" vs
another file with version 2.3.2 that exists somewhere else.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Different behavior when building a project as a module or "stand-alone"

[Wayne Fay <wa...@gmail.com>]

> looked at a couple of third party plugins (this one, for instance :
> http://mojo.codehaus.org/versions-maven-plugin/), but I couldn't find what I

I don't see why you would look to versioning things yourself. The
artifact should be delivered with a version associated with it from
the group responsible for producing it.

> each of the corporate libraries managed this way. We acknowledged that this
> was definitely not the intended way of managing libraries, but we didn't see
> that one problem you pointed out.

Ah yes this one, tiny, problem was unforseen. ;-)

> As I mentioned above, these problem originate from the fact that I am not
> managing these corporate libraries the way I should. I will revert to

Somehow, you should force the party providing you these artifacts to
VERSION them. And ideally they could also DEPLOY them into your
Nexus/Artifactory instance so that you could merely depend on them in
your own projects.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Different behavior when building a project as a module or "stand-alone"

[Philippe Lagardère <ph...@gmail.com>]

> Are you using a Maven repo such as Nexus?
> 
> Can you not give your corporate libraries GAV designations that are
> controlled so the version numbers are monotonically increasing?

We do use a Maven repo, although we had to abandon Nexus in favor of
Artifactory. 

Originally, we used versions when deploying those corporate libraries, but
we didn't know how to automate the whole thing (namely, upgrading the
version numbers). The easiest I could come up with was antrun + external
properties files. This was considered going overboard for a basic use case,
so we abandoned that idea, in favor of using a single version.

There must be simpler ways to do this out there, but I did not manage to
find them.
Since there are no SCM interactions, release plugin didn't seem to fit. I
looked at a couple of third party plugins (this one, for instance :
http://mojo.codehaus.org/versions-maven-plugin/), but I couldn't find what I
was looking for. The solution might be right in front of me, but I can't
find it.

I'd appreciate a lot some pointers on this "issue". The problem I
encountered would probably be void if I was doing things right.

> I want to be sure that I understand what you are saying here. The
> versions are DIFFERENT each time you run deploy-file, right? It is a
> basic premise of Maven and most sane build systems that that a given
> artifact with a particular version number must be immutable. Otherwise
> you have no idea if your file versioned 2.3.2 is the "right one" vs
> another file with version 2.3.2 that exists somewhere else. 

This is a problem we failed to take into consideration. We are effectively
using a single, fixed version, which means there is only one jar/pom for
each of the corporate libraries managed this way. We acknowledged that this
was definitely not the intended way of managing libraries, but we didn't see
that one problem you pointed out. 
It is somewhat lessened by the fact that only one person updates these
libraries, and that my project is the only one to resolve these dependencies
from our Maven repository, but clearly, this will become problematic at some
point.

As I mentionned above, these problem originate from the fact that I am not
managing these corporate libraries the way I should. I will revert to
manual, version enabled deployment for the time being, but I remain
extremely interested in automating the process (basically, how to
automatically increment the version using maven plugins, or something not
too far-fetched).

Any help on this matter will be greatly appreciated !


Philippe

--
View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5614606.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Different behavior when building a project as a module or "stand-alone"

[Ron Wheeler <rw...@artifact-software.com>]

Are you using a Maven repo such as Nexus?

Can you not give your corporate libraries GAV designations that are 
controlled so the version numbers are monotonically increasing?

Ron

On 02/04/2012 11:53 AM, Philippe Lagard�re wrote:
> Indeed, our use case for purge-local-repository is a bit dodgy and definitely
> sub-optimal.
>
> Our project depends on various corporate libraries which are not
> "Mavenized". In order to use these libraries, we frequently use
> deploy:deploy-file to drop them on our repository, with a fixed version
> (given that new versions are duly tested and obsolete older versions).
> Clearly, this is not the best way of doing things, but it was by far the
> easiest solution for us, and we expected it to be somewhat sustainable.
>
> The purge-local-repo goal (with the right set of exclusions) was used in
> order to ensure the latest versions of there corporate libraries were used
> whenever we release a new version of the project. I configured an execution
> as it was the first idea I had in order to have the goal run once for a
> multi-module build.
>
> Now, since it doesn't seem to work all that well, it probably won't be too
> hard finding another way around, so I suppose we can say my problem is
> closed.
>
> But I'm still curious as to why this problem occurred, can anyone fill me in
> on that ? No biggie if it's not possible, but I do wonder what I did wrong
> there (aside from the management of non-maven libraries ;) ) !
>
> Anyway, thanks for your insight, Wayne !
>
>
> Philippe
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5612860.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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

Re: Different behavior when building a project as a module or "stand-alone"

[Philippe Lagardère <ph...@gmail.com>]

Indeed, our use case for purge-local-repository is a bit dodgy and definitely
sub-optimal.

Our project depends on various corporate libraries which are not
"Mavenized". In order to use these libraries, we frequently use
deploy:deploy-file to drop them on our repository, with a fixed version
(given that new versions are duly tested and obsolete older versions).
Clearly, this is not the best way of doing things, but it was by far the
easiest solution for us, and we expected it to be somewhat sustainable.

The purge-local-repo goal (with the right set of exclusions) was used in
order to ensure the latest versions of there corporate libraries were used
whenever we release a new version of the project. I configured an execution
as it was the first idea I had in order to have the goal run once for a
multi-module build.

Now, since it doesn't seem to work all that well, it probably won't be too
hard finding another way around, so I suppose we can say my problem is
closed.

But I'm still curious as to why this problem occurred, can anyone fill me in
on that ? No biggie if it's not possible, but I do wonder what I did wrong
there (aside from the management of non-maven libraries ;) ) !

Anyway, thanks for your insight, Wayne !


Philippe

--
View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5612860.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Different behavior when building a project as a module or "stand-alone"

[Wayne Fay <wa...@gmail.com>]

> between the two builds. It happens during the execution of
> dependency:purge-local-repository. As you can see in the "build" pastebins

I have a lot of projects that are built with Maven, and not a single
one uses purge-local-repo. Why are you using it?

> below, there's only one library affected (profilage-lse). But, it's
> re-downloaded once during the standalone build, and twice during the
> "multi-module" build. Might seem benign, but when I comment out the
> execution for that goal, the warning disappears, and the "multimodule" build
> is successful.

I would eliminate your usage of purge-local-repo if at all possible
since it sounds like that would solve your problem.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Different behavior when building a project as a module or "stand-alone"

[Philippe Lagardère <ph...@gmail.com>]

Thanks for your answer, Wayne. I'll refrain from using Nabble's formatting
options from now on.
Here are the informations from my first message, in plain text this time.

=== === ===

My project has a basic multi-module structure, like this :

project
 |_project-core
 |_project-web
 |_project-batch

The thing is, I get two different results for executing mvn clean package,
whether I run it from project-core or from project.

>From project-core

[INFO]
[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ profilage-core ---
[INFO] Building jar: D:\ozp6kz\Mes
Documents\eclipse_workspace\ProjetProfilage\profilage-core\target\profilage-core-0.1.jar

>From project

[INFO]
[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ profilage-core ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar: D:\ozp6kz\Mes
Documents\eclipse_workspace\ProjetProfilage\profilage-core\target\profilage-core-0.1.jar
[INFO]

Basically, as a stand-alone, the project builds perfectly well, which allows
in turn the other modules to build correctly.
But when built as part of the global, multi-module project, there's this one
[WARNING] line which throws off the rest of the build.

=== === ===

When preparing my code for paste-bins, I (finally) noticed the difference
between the two builds. It happens during the execution of
dependency:purge-local-repository. As you can see in the "build" pastebins
below, there's only one library affected (profilage-lse). But, it's
re-downloaded once during the standalone build, and twice during the
"multi-module" build. Might seem benign, but when I comment out the
execution for that goal, the warning disappears, and the "multimodule" build
is successful.
I'm definitely at a loss as to why this happens, so any explanation would be
greatly appreciated !


Here are the pastebins from poms and builds, expurged of information
unrelated :

pom.xml - core module : http://commitcode.com/p/r/57wI2E5ovTY.html
pom.xml - project parent : http://commitcode.com/p/r/57wI4xQmdLk.html
pom.xml - corporate parent : http://commitcode.com/p/r/xX96TKUHndS.html
pom.xml - help:effective-pom : http://commitcode.com/p/r/57wI8D7a2eV.html
build - standalone : http://commitcode.com/p/r/xX97siekqj5.html
build - as a module : http://commitcode.com/p/r/57wIbt2oV2v.html


Philippe

--
View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5611840.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Different behavior when building a project as a module or "stand-alone"

[Wayne Fay <wa...@gmail.com>]

> And indeed, the .jar is empty (safe a couple of metadata files), which cause
> the build to fail on /project-web/, which depends on /project-core/

Generally this should "just work" no matter where you have started
your build. If it isn't working, that usually suggests you have
configured something improperly in a pom somewhere.

Is your source code in src/main/java as it should be? Or are you doing
something funky with <sourceDirectory> that might involve ".."?

In short, what does your pom file for the project-core look like? Post
it to pastebin or gist and send a link here. Perhaps also post the
help:effective-pom output.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org