[hibernate-dev] HSEARCH - Assorted fixes to the pom files

[Gunnar Morling]

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 <sanne at hibernate.org>

> On 13 August 2013 09:12, Guillaume Smet <guillaume.smet at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>