Re: maven-install-plugin:install not supporting pomFile property anymore?

[Jörg Hohwiller]

hi,

Hi Robert,

The install:install goal[1] doesn't have the the pomFile parameter, however the install:install-file[2] does.

I am aware of that.

So I'm not sure which goal you are actually using.

I am using the install goal. And it honors the pomFile parameter in version 2.3.1 just as I wrote. It does not work in 2.5.1. As I tried to explain my goal is that "mvn install" or "mvn deploy" will not install/deploy the pom.xml as is but instead the effective pom. Therefore I need to tell the maven-install-plugin:install goal and maven-deploy-plugin:deploy goal what file to use instead of ${basedir}/pom.xml.

There's a small change regarding the install-file which might affect this.

I am not sure if you get your point here...

It is not anymore required to specify the pom if the artifact was already built by Maven. The plugin will go through all the jar entries in search for a pom file and uses is the install.[3]

As I wrote, I am not talking about install-file. I thought my mail was clear enough but it seems I was wrong...

Robert

Thanks
  Jörg

[1] http://maven.apache.org/plugins/maven-install-plugin/install-mojo.html [2] http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html [3] http://maven.apache.org/plugins/maven-install-plugin/examples/custom-pom-installation.html

Op Thu, 30 Jan 2014 23:46:42 +0100 schreef Jörg Hohwiller <jo...@j-hohwiller.de>:

Dear Maven-Developers,

I am using a mechanism so that maven installs and deploys the effective
POM instead of the actual
raw pom.xml. Therefore I used the pomFile parameter of
maven-install-plugin. This works fine with
version 2.3.1 but refuses to work with 2.5.1. Has this been removed on
purpose?


Here is why I need this approach:
For years I was searching for a solution to keep maintenance of large
multi-module-projects with
inter-module dependencies that are versioned and released independently
at a low level.
I tried hard to use maven-release-plugin but it is simply not addressing
my use-case.
As suggested long time ago during discussion, I created a page in
confluence and jira issues:
http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance
http://jira.codehaus.org/browse/MNG-4161

Unfortunately I never made it deep enough into maven to create a patch
myself and I got demotivated
as others did and their work has been rejected (MNG-624). Also I created
pom-maven-plugin in the mojo project
sandbox that can refactor POMs in large maven projects automatically but
was told to stop on it as there
is already versions-maven-plugin with overlapping features.

I still think that maven should distinguish between development
information read from the local disc
and originated from the version control system
and what is installed and deployed in a maven repository. Maybe
something to consider for maven 4.
I have seen that gradle works this way but I am a fan of maven from the
start and do not want to


However, I found an excellent workaround for my problem that can be
found here:
https://github.com/m-m-m/mmm/blob/master/pom.xml
Search for "effective" to find all the relevant spots. I simply write
the effective pom to disk
and install and deploy this file instead of the original pom.xml. This
way I can only once deploy
empty parent POM files with a version 1.0.0 that never changes. Now I
can modify the checked in
parent POMs and update dependency management and variables without
taking care to trackle their
versions and update references all over the POMs in the project. This
way I can concentrate on
features for my OSS project rather than maintenance of pom.xml files and
am more safe from errors
when releasing/deploying sub-projects.

Now some day I will have to update to a new version of
maven-install-plugin and if my workaround
then stops working I am lost in space. Any ideas?

Thank you very much
   Jörg

Can someone explain me how to solve this? Any workarounds or plans on this? leave the maven ecosystem. Thanks to all of you for your good work on this.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

smime.p7s
Description: S/MIME Cryptographic Signature