On Tue, Jul 26, 2011 at 3:58 AM, Damian Bradicich <dbradic...@sonatype.com> wrote: > I'm still not seeing the problem, certainly a specific release of a parent > pom would be static, but if you need to update versions, you update the pom > and release a new version, then update your projects to use it as necessary. > It is a simple workflow, and leaves a single place where all versions are > defined, and will give you the least amount of trouble as you are not trying > to hack up some local repo metadata to achieve the exact same thing. > > I mean this is the _exact_ kind of thing maven excels at. You will forever > have the release of the parent pom, and will always be able to build older > releases of your projects (as i see benson has already mentioned in his > latest reply), anyone with simple pom knowledge can update the parent pom to > use a new version of plugin A/B/C. >
As I said, this is a solution, but in our case, unfortunately, only partial. You may have not aware that I'm working on building packages to be installed at system level in Gentoo Linux. The overhead that adds for a new parent pom like this is pretty high. I'll just say that there are complications (such as build-order, which package owns the pom, maven re-installations etc.) when it comes to packaging at operating system level. I have more than enough pom knowledge to update the pom if needed. But our pom handling and maven invocation is automated. Manually, editing the pom with the available plugin versions is much complicated, and may not be possible with the limitations imposed by the system. Anyway, I'm evaluating this solution deeply as well. I'm just looking for the optimal, and elegant solution that maven already has as I figured. In the given solutions, I like this most because this gives the needed control to some extent. > But I (like maven) can't force you into anything, just guide you to the best > solution ;-) I know, and I respect that. :) Thanks, --Kasun > > Damian > > On Mon, Jul 25, 2011 at 5:26 PM, Kasun Gajasinghe <kasu...@gmail.com> wrote: > >> On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich >> <dbradic...@sonatype.com> wrote: >> > But why ? simply have a top level parent pom that is solely for defining >> > your plugin versions (and anything else that may cover all of your >> > projects), you don't need any project specific logic in there. The >> parent >> > doesn't need to list any of the children that use it (and act as an >> > aggregator), that is just a common use of a parent. >> >> This would not work because the parent-pom file you are saying will be >> static. By static I meant that the parent pom file can not be modified >> later on after it goes in to the m2 repo. So, when a need arise to add >> a new plugin version, how it can be done? >> The way to do this is by maintaining maven-metadata.xml files which >> exists one per plugin under m2 repo (for example, for >> maven-compiler-plugin, it's in >> >> ~/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata*.xml). >> This way, I don't have a problem when a new plugin is added to the >> repo, right? >> >> It doesn't really matter whether this can be done via >> maven-metadata.xml or by some other means. We just need to make the >> setting details file per-plugin. >> >> --Kasun >> >> > >> > Damian >> > >> > On Mon, Jul 25, 2011 at 11:30 AM, Kasun Gajasinghe <kasu...@gmail.com >> >wrote: >> > >> >> On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich >> >> <dbradic...@sonatype.com> wrote: >> >> > err...pluginManagement section even ;) >> >> > >> >> > Damian >> >> > >> >> > On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich >> >> > <dbradic...@sonatype.com>wrote: >> >> > >> >> >> Why not define the pluginDependency section in a parent pom, then >> each >> >> of >> >> >> your projects uses this as a parent, and pulls in all the plugin dep >> >> >> versions defined in it (or overrides in project pom if necessary). >> >> Seems >> >> >> that would be simplest solution >> >> >> >> Since these projects are unrelated, they can't be glued together via a >> >> parent pom. >> >> >> >> Thanks, >> >> --Kasun >> >> >> >> >> >> >> >> Damian >> >> >> >> >> >> >> >> >> On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies < >> >> bimargul...@gmail.com>wrote: >> >> >> >> >> >>> I don't know about plugin-registry.xml, but you can distribute a >> >> >>> settings.xml for use with -gs that has an active-by-default profile >> >> >>> with a pluginManagement section that does the job. >> >> >>> >> >> >>> On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe < >> kasu...@gmail.com> >> >> >>> wrote: >> >> >>> > Hi, >> >> >>> > I have a requirement where I need to specify specific versions for >> a >> >> >>> > set of (basic) plugins. Adding the versions to the pom isn't an >> >> option >> >> >>> > because we need to set the plugin versions for a vast number of >> >> >>> > _unrelated_ builds. >> >> >>> > As I've found at [1], I've manually created a plugin-registry.xml >> >> file >> >> >>> > with needed plugin versions added. In addition to that, I've >> created >> >> >>> > maven-metadata-local.xml file in the m2 repo under the plugin >> >> >>> > directories, pointing to <latest> and <release> versions. >> >> >>> > >> >> >>> > But, unfortunately, these specified versions were not picked up by >> >> >>> > mvn. I needed latest maven-compiler-plugin version 2.3.2, but it >> >> >>> > always try to use 2.0.2. I've noticed that [1] is somewhat >> outdated >> >> >>> > because --check-plugin-latest parameter doesn't available anymore. >> >> So, >> >> >>> > I'm asking, does the plugin-registry.xml is still used by maven? >> If >> >> >>> > not what is the mechanism for specifying specific plugin versions >> >> >>> > (apart from current/parent pom)? >> >> >>> > >> >> >>> > (I've seen in some posts that the plugin-registry.xml isn't used >> >> >>> > anymore, but debug mode shows that mvn retrieves data from that >> file. >> >> >>> > ) Apparently, maven-metada-local.xml isn't created automatically >> for >> >> >>> > me either. How I can instruct mvn to do that? >> >> >>> > >> >> >>> > My plugin-registry.xml is at [2]. (There wasn't a template for >> that. >> >> >>> > So, hope the format is correct!). maven-metadata-local.xml of >> >> >>> > maven-compiler-plugin is at [3]. >> >> >>> > I'm using official apache maven-2.2.1 build. >> >> >>> > >> >> >>> > Your help is much appreciated. >> >> >>> > >> >> >>> > [1] >> >> >>> >> >> >> http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html >> >> >>> > [2] http://pastebin.com/yprQU2D2 >> >> >>> > [3] http://pastebin.com/Y375dwMg >> >> >>> > >> >> >>> > Thanks, >> >> >>> > --Kasun >> >> >>> > >> >> >>> > -- >> >> >>> > ~~~*******'''''''''''''*******~~~ >> >> >>> > Kasun Gajasinghe, >> >> >>> > University of Moratuwa, >> >> >>> > Sri Lanka. >> >> >>> > Blog: http://blog.kasunbg.org >> >> >>> > Twitter: http://twitter.com/kasunbg >> >> >>> > >> >> >>> > >> --------------------------------------------------------------------- >> >> >>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >> >>> > For additional commands, e-mail: dev-h...@maven.apache.org >> >> >>> > >> >> >>> > >> >> >>> >> >> >>> >> --------------------------------------------------------------------- >> >> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >> >>> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >>> >> >> >>> >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> ~~~*******'''''''''''''*******~~~ >> >> Kasun Gajasinghe, >> >> University of Moratuwa, >> >> Sri Lanka. >> >> Blog: http://blog.kasunbg.org >> >> Twitter: http://twitter.com/kasunbg >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >> >> >> > >> >> >> >> -- >> ~~~*******'''''''''''''*******~~~ >> Kasun Gajasinghe, >> University of Moratuwa, >> Sri Lanka. >> Blog: http://blog.kasunbg.org >> Twitter: http://twitter.com/kasunbg >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > -- ~~~*******'''''''''''''*******~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
