> > Are you using the release plugin? > > Nope! I tried it and came to the point that is no good for me. > I also had a discussion with the developers long time ago > and filed some feature request. Anyhow I still think this > is the wrong approach for me. >
Can you give more details about what doesn't work or doesn't match your process? > > >> > >> > >> 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. > > I have read parts of this. I hope there is a chance to see this in the > future. > > > > >> 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. > > I see your point. But I am always building from toplevel. > Anyhow I am also dreaming of a cmd-option in maven 3 that enables > a mode where maven walks up to the loplevel pom (as far as locally > available) and creates the entire reactor while still building > just the module where it was invoked. This could solve the problem you > pointed out as well as many other problems, e.g. to do dependent builds > of local modules. > > Anyhow this would just be a feature that does not hurt and > would not cause downward compatibility problems if assured, > that install/deploy will fill in the omitted version. > The new reactor modes are in 2.1.0 that can do some similar things. > > > >> > >> > >> 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. > > Great. So I hope for MNG-2971. Anybody out there > can let me know if this is just waiting for contribution. > I might work on this one if it is just about that feature > in the install-plugin. If there is some more general architectural > change needed in order to make this also work with release-plugin > and many others let me know - I might not see all possible problems. > I think I also read some ideas about POM-Transformation in maven 3... > Some of this is already done in 2.1.0 > > >> > >> > >> 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! > >> > >> Thanks > >> Jörg > > Regards > Jörg > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoG0h4ACgkQmPuec2Dcv/8zqgCghlevEs/YlVRLaaTIWQl6yi5W > kJYAn00C5R0sjXjIl6Z08EtMCFEFIMHN > =yhX0 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
