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.
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).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
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
smime.p7s
Description: S/MIME Cryptographic Signature
