-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ralph,
>>> Hi there, >>> >>> absolutely everybody having large maven projects is >>> annoyed by maintaining the versions in all the poms. >>> >> >> Are you using the release plugin? > > This problem probably goes away for anyone able to use the release > plugin, but only because the release plugin does all the work, not > because the need for the work goes away. If, for whatever reason, you > can't use the release plugin, then this is a real pain. Yep, I am having this pain and I now dozens of others that have the same problems. >> >> >> >>> >>> Additionally the complete solution is quite simple >>> and seems to be quite common sense: >>> >>> 1. Allow to omitt versions in <parent> as well >>> as in <dependency> that is available in the reactor. >>> >> >> Omitting the parent is complicated. Ralph started an implementation >> but we >> found some issues with it at ApacheCon. I don't think it's gotten beyond >> that yet. > > Actually, the guys I work with started to complain about this again last > week and want me to fix it. They suggested that rather than tackling > both accepting a missing parent version and fixing the pom so that the > pom written to the repository is fully resolved (i.e. the parent version > is present in the deployed pom) that just accepting the missing parent > would be enough. I'm not sure, but I'd be willing to look at it. > > I'm also not sure how much things have changed since I created the > branch. I'll have to check. I have read your comments. Well thanks so far for all your work and invest. I hope you have NOT lost your faith ;) > > The only real problem with what was on the MNG-624 branch was that it > requires a place to create the resolved pom.xml. To do that it assumed a > hardcoded location of "target". If a parent pom redefines the build > directory (it seems really odd to me that this is even allowed) then > this is wrong. But trying to find the definition of the target variable > requires looking at every parent, even if it isn't local, which is > something I was trying to avoid. I did not yet get the point, why you have to write a new pom.xml to the disc. My naive illusion was that there is a central component that reads and parses the POM in maven where you can hook into and perform the transformation. Then all additional work is to assure, that plugins such as the install plugin do NOT simply copy the pom.xml to the local repo but include the transformation. Here we might run into the problem that the POM XML is de-serialized with a parser (was it XPP or is it StAX) and the internal representation looses information so it can NOT be serialized again without loosing indentation, comments, etc. of the original pom.xml. > > Anyone is free to look at the branch and improve on it. >> >> >> You can use dependency management or properties to deal with omitting the >> dependencies. I personally never assume what will be contained in a >> reactor >> and structure my builds so that any module can always be built in >> isolation. >> Therefore, I can't see why you would want to omit the dependency for >> something in a reactor that may not be in the reactor all the time. The >> release plugin handles this for you when it's time to bump the versions. >> >> >>> >>> 2. Ensure that omitted version as well as variables >>> in <groupId> <artifactId> and <version> are replaced >>> when a pom is installed in the repository. >>> >> >> Agree with this. > > Yes, the fix in MNG-624 does a really good job of this. So your patch also resolves variables and NOT only in parent but also in dependencies-section? Havent seen that... >> >> >> >>> >>> However I totally lost where we are and what is going on. >>> >>> http://jira.codehaus.org/browse/MNG-624 >>> http://jira.codehaus.org/browse/MNG-2971 >>> http://jira.codehaus.org/browse/MNG-3267 >>> http://jira.codehaus.org/browse/MNG-2971 >>> >>> I could not find the one to omitt version in <depdency>. >>> Can anybody remember. Or do I have to open a new one. >>> >>> I can not really tell how hard it is to make this >>> work, but be sure that we can make millions of users >>> happy with this! > > Where we are in this is that I have been totally booked writing code for > other projects - mostly commons VFS and commons configuration. I have the same problem. The main reason why I am here is because I am using maven in all my other OSS-projects and I love it but sometimes I also hate it and hope that the tiny parts that are not already perfect will go away some day... > As Brian > mentioned, he and I discussed this at the last ApacheCon US and found > the issue noted above. I simply have not had the time to figure out how > to solve that. Even if you can't contribute a patch a really good idea > would be welcomed. I will try to give it a little dive - but I have NOT done much other than some MOJO-coding so far and sometimes get lost with mercury, plexus, wagon, etc. and I have just little time. Still looking for someone who likes to pay me for doing OOS development ;) > > Ralph Thanks Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkoJ57MACgkQmPuec2Dcv/8lRwCYiBT7/U3Bo2eEmIFuuFYQVIZD lwCfciC00lLjkyFkorTYoItBFD/igEA= =ZSsP -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
