[
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318426#comment-318426
]
Henning Gross edited comment on MINSTALL-94 at 1/31/13 5:24 PM:
----------------------------------------------------------------
Hi Robert!
I think you did not get my use-case. Its in the nature of a
multi-module-project that there are dependencies between modules. For instance
lets say you have 3 or 4 libraries, a core-lib and maybe like 10 to 20
consumers. You cannot run "mvn test" on the parent as the dependencies will be
missing (or old if already deployed before). You would have to run mvn install
to make sure those artifacts are deployed. When running the install-goal there
are some other phases in the default lifecycle that are passed before. As we
have a rather large amount of war-files with overlays and a lot of javascript
and less-foo configured those phases like packaging take forever. With no
benefit at all. I think the test-install jar thing that I have in mind is a
pretty valid requirement and a lot of projects do need it. In huge projects it
is essential to save as much time as possible in the basic jenkins-Jobs to
allow feedback early.
The approach of running two jenkins-jobs (one that installs the libs and the
other one that runs the tests on the consumers) brings a lot of configuration
overhead. Modules need to be wrapped in profiles and a build-pipeline on
Jenkins is necessary to make sure you are getting exactly the jars that were
just build and not something deployed from anywhere.
To your last question ("what is wrong with the skip-parameter?"): Of course we
could configure the skip-parameter in every single consumer-module wrapped in a
profile but that feels like a hack to me and is a lot of overhead compared to
just one line in the parent. Dont you think so? Thank you anyway for that idea.
I will probably implement it as fast is more important than nice. But fast and
nice would be even better ;)
Can I ask you the other way around? What is wrong with making this behaviour
configurable? Other plugins also expose switches for fail-behaviour.
was (Author: gaffa):
Hi Robert!
I think you did not get my use-case. Its in the nature of a
multi-module-project that there are dependencies between modules. For instance
lets say you have 3 or 4 libraries, a core-lib and maybe like 10 to 20
consumers. You cannot run "mvn test" on the parent as the dependencies will be
missing (or old if already deployed before). You would have to run mvn install
to make sure those artifacts are deployed. When running the install-goal there
are some other phases in the default lifecycle that are passed before. As we
have a rather large amount of war-files with overlays and a lot of javascript
and less-foo configured those phases like packaging take forever. With no
benefit at all. I think the test-install jar thing that I have in mind is a
pretty valid requirement and a lot of projects do need it. In huge projects it
is essential to save as much time as possible in the basic jenkins-Jobs to
allow feedback early.
The approach of running two jenkins-jobs (one that installs the libs and the
other one that runs the tests on the consumers) brings a lot of configuration
overhead. Modules need to be wrapped in profiles and a build-pipeline on
Jenkins is necessary to make sure you are getting exactly the jars that were
just build and not something deployed from anywhere.
To your last question ("what is wrong with the skip-parameter?"): as I stated
and hopefully now explained: its not about skipping anything really. Its about
being able to install stuff w/o running all phases before install (which causes
eg wars to not being build). Of course we could configure the skip-parameter in
every single consumer-module wrapped in a profile but that feels like a hack to
me. Dont you think so? Also I do not have the source available right now. Is
the skip-param evaluated before the check for the artifact is done? That would
be necessary for this approach. Can I ask you the other way around? What is
wrong with making this behaviour configurable? Other plugins also expose
switches for fail-behaviour.
> Optional: limit install to packaging x and or make install plugin not fail if
> no artifacts were created for some modules.
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: MINSTALL-94
> URL: https://jira.codehaus.org/browse/MINSTALL-94
> Project: Maven 2.x Install Plugin
> Issue Type: Improvement
> Reporter: Henning Gross
> Attachments: MINSTALL-94.patch
>
>
> Background: I am working in a huge project with a lot of modules having a lot
> of javascript-optimization and stuff happening in lifecycle-steps after
> compile. This results in bad performance on jenkins. I would like to run
> mvn compile install:install as I only need the jars/libs to be installed and
> not the wars (and more important I do not need them to be built).
> Please introduce Parameters like
> <doNotInstall>war</doNotInstall>
> or
> <failIfNoArtifact>false<...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
