3:12 a.m.
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.
- same for the Maven plugins;
- 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.
- remove the commons-logging API altogether and use slf4j and its
wrapper for commons-logging
- 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)
- update the activemq dependency if it's not too much of a pain as
it's only a test dependency;
- remove outdated comments: I'm especially thinking about the one for
the log4j dependency: the problem has been fixed a while ago;
- 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);
- 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;
- remove the luceneRegexJakartaVersion property: it's not used anywhere.
Interested in a couple of +1/-1 before starting this work.
--
Guillaume
3:58 a.m.
On 13 August 2013 09:12, Guillaume Smet <guillaume.smet(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:10 a.m.
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(a)hibernate.org>
On 13 August 2013 09:12, Guillaume Smet
<guillaume.smet(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:41 a.m.
On Tue, Aug 13, 2013 at 10:58 AM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
On 13 August 2013 09:12, Guillaume Smet
<guillaume.smet(a)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.
You can do whatever you want by overriding the dependency management.
It's the only way to really fix the problem of transitive
dependencies.
If you want a specific version for a child module, just define it in
your local dependency management, it's going to override the one of
the parent.
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 don't use the versions plugin but I just did some tests with our
parent pom (which is *huge*) and it perfectly understand properties.
It even has goals to update them.
My point is it's a little weird to have a mix of properties and hard
coded versions.
> - 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
OK.
> - 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.
I don't know jboss logging that well. Does it provide wrappers similar
to what slf4j is doing?
My point in removing commons-logging is to have all logging
dependencies satisfied with slf4j and its wrappers. commons-logging is
a pain: the first time we had to completely remove it was because of
problems with Weblogic IIRC.
But we can keep it this way if you prefer.
> - 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.
Of course. I was talking about Solr 3.6.2.
Ideally we should try to guarantee to stay in synch. Am I
understanding correctly that enforcer can do that via dependency
convergence ?
Not exactly. What I usually recommend is the following:
- define your dependencies versions in your dependencyManagement;
- don't define the versions of the transitive dependencies: they will
update themselves accordingly;
- EXCEPT if you have a conflict: and it's where the dependency
convergence rules helps you: it detects the conflicts and breaks the
build.
But it doesn't detect any conflict if your dependency is managed via
dependency management.
In the case of commons-io, if it's only coming from Solr, my advice is
to remove it from the dependency management and let Solr choose the
correct version. If one day, another dependency needs a different
version, the enforcer plugin will warn us and we'll have to choose a
common version which is working for both of them.
From my experience of 5 years of maintaining a Maven based framework,
base dependencies are usually very stable and we keep them in synch
with upstream without too much pain.
> - 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.
I'm talking about this comment:
<!--
Defining log4j here, but due to a bug in Shrinkwrap we
still need to define the version explicitly
in the sub modules. See HSEARCH-970
-->
The issue is fixed so we can remove the comment I think (but not the
dependency).
> - 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.
Sorry, not a JBoss guy (yet) :).
I'm not very aware of this module thing.
> - 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.
OK.
> - remove the luceneRegexJakartaVersion property: it's not
used anywhere.
+1
OK.
Thanks for the in-depth analysis! very nice
Thanks for the feedback!
--
Guillaume
6:18 a.m.
I am all for cleaning up. Aside the things discussed here I would like to follow up on
HSEARCH-933.
The database profiles defined in the parent pom have imo no business there. They just
create unnecessary noise.
Initially I thought we could use a separate settings.xml, but I think you cannot add
dependencies to settings.xml.
Maybe the profiles can go into a separate pom/module or we could do something along the
ORM line and have
some test matrix thingy. Either way, the QA testing profiles have no business in the
parent pom (I could go on now
how this is a general Maven problem, but I leave this to others ;-))
--Hardy
6:28 a.m.
On 13 August 2013 10:41, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
On Tue, Aug 13, 2013 at 10:58 AM, Sanne Grinovero
<sanne(a)hibernate.org> wrote:
> On 13 August 2013 09:12, Guillaume Smet <guillaume.smet(a)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.
You can do whatever you want by overriding the dependency management.
It's the only way to really fix the problem of transitive
dependencies.
If you want a specific version for a child module, just define it in
your local dependency management, it's going to override the one of
the parent.
I'm fine with doing it. Just saying that occasionally we won't stick with it,
possibly by overriding as you suggest.
> 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 don't use the versions plugin but I just did some tests with our
parent pom (which is *huge*) and it perfectly understand properties.
It even has goals to update them.
Usually it doesn't work ;-)
Careful with it, and since I see no point in using properties for the
plugins I wonder if the risk is worth it.
pluginManagement served us fine so far?
Properties are useful for our main dependencies as they highlight
stuff which matters; plugins are not that important (as long as they
do their job we don't care).
My point is it's a little weird to have a mix of properties and hard
coded versions.
>> - 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
OK.
>> - 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.
I don't know jboss logging that well. Does it provide wrappers similar
to what slf4j is doing?
Yes, it has the same kind of front-end facade with multiple backends,
just that it's much faster
as the front end facade has a better API. Also the backend - when
deployed on AS7 - is much faster than log4j,
but when deployed elsewhere it can write to log4j or others, depending
on what it finds.
But I doubt you can change the third party libraries to use it.
My point in removing commons-logging is to have all logging
dependencies satisfied with slf4j and its wrappers. commons-logging is
a pain: the first time we had to completely remove it was because of
problems with Weblogic IIRC.
But we can keep it this way if you prefer.
I would prefer removing it, I mean that I don't think you can manage
to remove them. Feel free to try.
>> - 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.
Of course. I was talking about Solr 3.6.2.
+1 Just making sure we're on the same page ;)
> Ideally we should try to guarantee to stay in synch. Am I
> understanding correctly that enforcer can do that via dependency
> convergence ?
Not exactly. What I usually recommend is the following:
- define your dependencies versions in your dependencyManagement;
- don't define the versions of the transitive dependencies: they will
update themselves accordingly;
- EXCEPT if you have a conflict: and it's where the dependency
convergence rules helps you: it detects the conflicts and breaks the
build.
But it doesn't detect any conflict if your dependency is managed via
dependency management.
In the case of commons-io, if it's only coming from Solr, my advice is
to remove it from the dependency management and let Solr choose the
correct version. If one day, another dependency needs a different
version, the enforcer plugin will warn us and we'll have to choose a
common version which is working for both of them.
From my experience of 5 years of maintaining a Maven based framework,
base dependencies are usually very stable and we keep them in synch
with upstream without too much pain.
Sounds very good. Let's see how it works out in practice.
>> - 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.
I'm talking about this comment:
<!--
Defining log4j here, but due to a bug in Shrinkwrap we
still need to define the version explicitly
in the sub modules. See HSEARCH-970
-->
The issue is fixed so we can remove the comment I think (but not the
dependency).
>> - 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.
Sorry, not a JBoss guy (yet) :).
I'm not very aware of this module thing.
No worries, synch-up the version is the necessary first step anyway.
>> - 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.
OK.
>> - remove the luceneRegexJakartaVersion property: it's not used anywhere.
>
> +1
OK.
> Thanks for the in-depth analysis! very nice
Thanks for the feedback!
--
Guillaume
9:25 a.m.
Hi,
Here we go for the current state of my work and what I would like to do:
https://hibernate.atlassian.net/browse/HSEARCH-1392
I created a PR so that we can discuss the changes already made:
https://github.com/hibernate/hibernate-search/pull/472
Thanks for your feedback.
--
Guillaume
4168
days inactive
4169
days old
6 comments
4 participants
participants (4)
-
Guillaume Smet -
Gunnar Morling -
Hardy Ferentschik -
Sanne Grinovero