Dependency Versions - Makeover

Lukas Krejci lkrejci at redhat.com
Mon Mar 18 09:26:04 UTC 2013


The only change I was proposing was to extract the versions of *ALL* the deps we use in the whole of RHQ (core?, it probably doesn't make sense to list the deps of plugins, because those should be by definition isolated from the rest of the RHQ and should therefore include the deps they need on their own) in a separate file referenced from the root POM. It would only slightly help the readability of the root POM by reducing its line count but otherwise would not have any other side-effects, I think.

When looking at our build, I think the way we organize stuff by declaring common setup and deps and versions in parent poms (and then requiring the "children" to declare specific modules as their parents) is better for our purpose than using a BOM. For example, our rhq-plugins-parent defines deps, profiles and other config common to all plugins, which then (by declaring this module as their parent) inherit all of the setup. This is better than declaring the deps in a BOM, because a) in order to use any of the deps from the BOM, any plugin would still have explicitly depend on an artifact (without specifying the version) and b) any other stuff like profiles, common build plugin configurations, etc. would not be solved by the inclusion of the BOM into the plugin's dependencyManagement.

A BOM makes sense for projects like Arquillian that have a lot of interdependent optional modules that the target user might or might not use. Therefore declaring the compatible versions of such optional modules in a BOM and the let the users pick and choose the modules they want without requiring them to resolve the version compatibility themselves makes a lot of sense. I think our situation is slightly different though because we generally don't provide that kind of setup nor do we have to deal with such large number of independently versioned modules.

Our goal should be to make the "leaf" modules (i.e. plugins of all sorts) as easy to configure and build as possible. By moving all the "magic" into parent poms and requiring the leaf modules to declare specific (documented) modules as their parents, I think we can achieve that goal - I actually think our current build is almost there. We just have to clean up and solve last few remaining idiosyncrasies (like the large ant chunks), which is exactly what you and Thomas are after.
 
So in another words I am completely +1 on your proposal.

----- Original Message -----
> From: "Stefan Negrea" <snegrea at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Friday, March 15, 2013 6:51:32 PM
> Subject: Re: Dependency Versions - Makeover
> 
> 
> ----- Original Message -----
> > From: "Lukas Krejci" <lkrejci at redhat.com>
> > To: rhq-devel at lists.fedorahosted.org
> > Sent: Friday, March 15, 2013 12:13:56 PM
> > Subject: Re: Dependency Versions - Makeover
> > 
> > What about a BOM to contain the deps? Just to separate them out of
> > the root pom and have a dedicated file to contain only the dep
> > versions.
> > Not sure if an imported BOM is inherited by the child modules (so
> > that we don't have to import the BOM in every module).
> > 
> > http://stackoverflow.com/questions/6281422/clean-up-maven-dependency-management
> > 
> > This is essentially the same as your current proposal, the only
> > change is the dedicated file for dep version declarations to keep
> > the sizes of the "real" poms down to the minimum making them easier
> > to comprehend.
> 
> 
> The idea of a BOM project is interesting but I am not sure how we
> would use it on sub-modules. We will have to make all the
> sub-modules inherit from it? In which case we are back to having
> everything in the root pom as the BOM for the project.
> 
> 
> Could you elaborate a little bit more on how we could create & use
> BOMs?
> 
> 
> Thank you,
> Stefan Negrea
> 
> 
> > 
> > ----- Original Message -----
> > > From: "Stefan Negrea" <snegrea at redhat.com>
> > > To: rhq-devel at lists.fedorahosted.org
> > > Sent: Friday, March 15, 2013 5:59:29 PM
> > > Subject: Re: Dependency Versions - Makeover
> > > 
> > > So the plan would be:
> > > 
> > > 1) Properties with versions in root pom:
> > > <jboss-jmx.version>4.2.3.GA</jboss-jmx.version>
> > > 
> > > 2) Root pom will have dependencies with versions in
> > > dependencyManagement section:
> > > <dependency>
> > >   <groupId>jboss</groupId>
> > >   <artifactId>jboss-jmx</artifactId>
> > >   <version>${jboss-jmx.version}</version>
> > > </dependency>
> > > 
> > > 3) Root pom will have plugins with versions in pluginManagement
> > > section (build/pluginManagement):
> > > <plugin>
> > >   <groupId>org.codehaus.mojo</groupId>
> > >   <artifactId>clirr-maven-plugin</artifactId>
> > >   <version>${clirr.version}</version>
> > > </plugin>
> > > 
> > > 4) All submodules would use plugins and dependencies without
> > > version:
> > > <dependency>
> > >   <groupId>antlr</groupId>
> > >   <artifactId>antlr</artifactId>
> > >   <scope>provided</scope>
> > > </dependency>
> > > 
> > > <plugin>
> > >   <groupId>org.codehaus.mojo</groupId>
> > >   <artifactId>clirr-maven-plugin</artifactId>
> > >   ....
> > > </plugin>
> > > 
> > > 
> > > The versions to be extract in properties would be the full name
> > > of
> > > the dependency/plugin + version. For example:
> > > clirr-maven-plugin.version and not the current clirr.version.
> > > 
> > > I really like this because we will have a single pattern for
> > > dependencies. Only one rule to follow.
> > > 
> > > 
> > > 
> > > Thank you,
> > > Stefan Negrea
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "John Mazzitelli" <mazz at redhat.com>
> > > > To: rhq-devel at lists.fedorahosted.org
> > > > Sent: Friday, March 15, 2013 11:39:15 AM
> > > > Subject: Re: Dependency Versions - Makeover
> > > > 
> > > > > So you would rather see all the dependencies declared in the
> > > > > dependencyManagement section of the root pom of the project?
> > > > > And
> > > > > then apply the option 2 from below across all the
> > > > > sub-modules?
> > > > > The
> > > > > only concern that I have with this option is that we will
> > > > > have
> > > > > a
> > > > > huge!! section for dependency management. Aside from the huge
> > > > > section in the root pom I think it is a cleaner approach.
> > > > 
> > > > I like the idea of having everything like this defined in one
> > > > place
> > > > (the root pom). If its large, so be it. The alternative is
> > > > going
> > > > through our large set of poms to adjust things that we need.
> > > > _______________________________________________
> > > > rhq-devel mailing list
> > > > rhq-devel at lists.fedorahosted.org
> > > > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > > > 
> > > _______________________________________________
> > > rhq-devel mailing list
> > > rhq-devel at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > > 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list