Hi Guillaume, Sounds great, nothing much to add to what Sanne said.
Regarding properties for versions, I think it's only worth it in case a given version is used several times (e.g. by several "modules" of a dependency which all should be pulled in in the same version). Otherwise I think it enough/easier to specify the version directly within the concerned dependencyManagement/pluginManagement entry. Big +1 for using the dependency convergence. You might also try adding the "requirePluginVersions" check. --Gunnar 2013/8/13 Sanne Grinovero <sa...@hibernate.org> > On 13 August 2013 09:12, Guillaume Smet <guillaume.s...@gmail.com> wrote: > > Hi, > > > > I'm planning to work on the pom files in the next few days. > > > > Here is more or less the plan I have in mind: > > - centralize all dependencies versions in the properties of the parent > > pom file. A couple of them are directly in the dependencyManagement > > block. It's easier to update them this way. > > +0 > It might no longer be the case, but there have been situations in > which we would test - for example - integration with JGroups 2.9x in > search-engine to make sure backwards compatibility would work, but > need to override this to 3.2.x when used in combination with > Infinispan. Basically that serves to verify against a broader range of > versions than what we can do with a single version. > End users use single versions (at least we hope so) but it's often > impossible for them to solve the dependency puzzle if we (and other > frameworks) don't allow compatibility with a somewhat more relaxed > range of versions, that brings to different definitions of "best > practices" depending if you're building a library or an application. > > Feel free to reorganize this but we're not going to enforce a hard > rule about it, we occasionally need to be able to achieve some > flexibility and the parent pom strategy in Maven isn't always good > enough. > > > - same for the Maven plugins; > > -1 for properties > I keep them up to date them via "mvn versions:[xyz]" and this doesn't > understand properties, I would need to track them all down manually. > > +1 to move all plugin versions in the <pluginManagement> section if > they aren't already (I see now that one is missing). > > > - I would like to enforce the dependency convergence rule via the > > enforcer plugin: a few additional dependency management declaration > > will be needed to get everything right. See > > > http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html > > for more information. > > +1 > > > - remove the commons-logging API altogether and use slf4j and its > > wrapper for commons-logging > > Not sure I understand? We don't use neither commons-logging nor slf4j. > You're welcome to convince all our dependencies to move to JBoss > Logger :-D > I'd rather remove both if that where possible. > > > - update a few core dependencies (especially Javassist to the version > > used in ORM, slf4j, log4j, commons-io which is a solr dependency and > > Solr is now using 2.1, not 1.4) > > +100 we need to stay in synch, that could be a bug > But pick the versions used by our dependencies, what is used by > "latest" Solr doesn't matter of course. > Ideally we should try to guarantee to stay in synch. Am I > understanding correctly that enforcer can do that via dependency > convergence ? > > > - update the activemq dependency if it's not too much of a pain as > > it's only a test dependency; > > +1 very glad if you could do that > > > - remove outdated comments: I'm especially thinking about the one for > > the log4j dependency: the problem has been fixed a while ago; > > Are you sure it's fixed? It creates a hell of problems during the > release process. > Ideally I'd drop it, if only we could. > > > - in latest JBoss EAP, Jackson is in a custom version of 1.9.9 (there > > is a "redhat" qualifier in the version string): maybe, I was thinking > > about upgrading the dependency to at least 1.9.9, instead of 1.9.2 > > (which is effectively the version used in AS 7.1); > > +1 > Also would be nice to depend on the "jackson module" provided by AS > rather than bringing our copy. > > > - remove the lucene-regex dependency management definition: this > > dependency isn't declared anywhere, except in the modules file. I > > think it's a leftover of something and we should get rid of it > > altogether; > > -1 > It's needed in the modules. It contains optional analyzers and helpers > which appear to be popular among users, since we package the module > for AS7 / EAP6 it's meant to be included in there. > > > - remove the luceneRegexJakartaVersion property: it's not used anywhere. > > +1 > > > > > Interested in a couple of +1/-1 before starting this work. > > Thanks for the in-depth analysis! very nice > Cheers, > Sanne > > > > > -- > > Guillaume > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
