Hi Jörg,
There's a little of confusion here: you're talking about the effective
pom, which is the fully resolved pom. However, you seem to be talking
about a consumer pom, as we started to call it since our thread about
model 5.0.0 [1]. Here we try to make a clear separation between the
information to *build* this project and to *use* this project. This
separation will give us a chance to upgrade the pom.xml with a list of
long standing requests.
As long as this is not implemented, we need to thing of another way. Right
now the correct way would be: have a Maven Plugin generate the consumer
pom.xml and bind it to the Maven Project, probably during the
'package'-phase.
This way the rest of the plugins can depend on this new pom.xml, so
there's no need to change the maven-install-plugin or maven-deploy-plugin.
The problem will be solved "the Maven Way". Control over the pom.xml has
been moved from specific parameters for the install and deploy plugin to
this single new plugin and has become much more handy (to quote with your
own words ;) ).
thanks,
Robert
[1] http://markmail.org/thread/eqsv7pkel5eczndl
Op Sun, 16 Feb 2014 16:39:03 +0100 schreef Jörg Hohwiller
<jo...@j-hohwiller.de>:
Am 04.02.2014 20:42, schrieb Robert Scholte:
Hi Jörg,
Hi Robert,
thanks for your response.
if we would change this for the maven-install-plugin, you'll hit it
again with the maven-deploy-plugin.
I know. The feature also used to work with the older version of
maven-deploy-plugin and this would then be my next request.
This should indicate there's something wrong with the process.
This seems to be the answer I am getting all the time from the maven
community. What am I doing wrong?
1. I was asking for a removed feature to come back or some workaround
for it.
2. IMHO a build tool should not dictate the process and the philosophy
in a way that things get not handy any more. I was describing an actual
problem and see a flaw in maven, when you have a large project and want
to release parts of the project (not sub-trees but single modules) and
you need to maintain the inter-module dependencies and ensure consistent
releases.
If there is any other solution with maven that I am missing please let
me know. Otherwise it would be lovely to hear some constructive
suggestion for the problem.
I will try to write a MOJO and test if project.setFile will help. Then I
can write the minified POM within that MOJO directly as the
effective-pom was only a workaround for the actual goal to install and
deploy a POM with only the config that is required for runtime.
And maybe there are other plugins which expect the same change.
Right. maven-gpg-plugin for instance.
In my opinion, the pom.xml which is copied/uploaded during the
install/deploy should also be the file used to build this project. I
think there are 2 solutions:
- build the project with the effective pom.xml
- let a plugin calculate the effective pom and bind it to the
MavenProject
These are solid solutions, which ensure that the jar/ear/etc. can
really be built with that pom.xml
As I already wrote my opinion differs and I want and need to distinguish
between information required to tell maven how to build the project and
information that is required for deployment and runtime. I do not need
to install the effective POM but a POM where dependencies to parent POM,
unnecessary indirections (e.g. variables, dependency management, etc.)
are stripped off and simplified.
Imagine if maven would have been designed this way already, then all the
nice features that have been discussed in the last years but have been
dropped due to compatibility could have been realized easily.
I am aware that there are also features and workflows possible due to
the fact that the development configuration can be distributed via a
repository but we could have the best of both worlds (e.g. if there is
an option to tell maven what you want).
FYI: the parameter has been marked as deprecated in favor of the
installAtEnd support.
Such feature (long standing) in Maven Core would have a huge impact,
so by moving it to the plugins we offered a solution which works for
the average Maven Project. There are still some rare cases which
aren't covered, though.
What is the average Maven Project?
I always thought Maven is addressed and designed for complex projects.
Am I wrong?
Thanks,
Robert
Thanks Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
