[xwiki-devs] Keeping uniform jar versions across modules
Hi, I have frequently encountered this problem that versions of third party jars across modules are not uniform. Like the xwiki-core uses commons-lang of version 2.1 and lucene 2.3. Similarly some module uses xerces-impl of version 2.0.2 where as some other 2.8.1. As the xwiki build can be made of different modules as per custom requirements, when we bring these modules together there is a conflict in the jar versions. This way different jars of same version end up in the lib directory and causes class not found exceptions. I don't know what is the best way to avoid such a problem, but best I can think is when building the pom we should ensure that version of the third party jar stays uniform atleast across xwiki-platform. Thanks Sachin ----- http://www.assembla.com/wiki/show/sachin_mittal about me: -- View this message in context: http://www.nabble.com/Keeping-uniform-jar-versions-across-modules-tp16194595... Sent from the XWiki- Dev mailing list archive at Nabble.com.
On Mar 21, 2008, at 8:01 AM, Sachin Mittal wrote:
Hi, I have frequently encountered this problem that versions of third party jars across modules are not uniform. Like the xwiki-core uses commons-lang of version 2.1 and lucene 2.3. Similarly some module uses xerces-impl of version 2.0.2 where as some other 2.8.1.
As the xwiki build can be made of different modules as per custom requirements, when we bring these modules together there is a conflict in the jar versions.
This way different jars of same version end up in the lib directory and causes class not found exceptions.
I don't know what is the best way to avoid such a problem, but best I can think is when building the pom we should ensure that version of the third party jar stays uniform atleast across xwiki-platform.
Yes you're right. The solution is to use dependencyManagement in Maven in the top level POM. The way to find the different version is to run the convergence report. Please feel free to submit patches. Thanks -Vincent
You can make the commons-lang version 2.3 in xwiki-core pom.xml Thanks Sachin vmassol wrote:
On Mar 21, 2008, at 8:01 AM, Sachin Mittal wrote:
Hi, I have frequently encountered this problem that versions of third party jars across modules are not uniform. Like the xwiki-core uses commons-lang of version 2.1 and lucene 2.3. Similarly some module uses xerces-impl of version 2.0.2 where as some other 2.8.1.
As the xwiki build can be made of different modules as per custom requirements, when we bring these modules together there is a conflict in the jar versions.
This way different jars of same version end up in the lib directory and causes class not found exceptions.
I don't know what is the best way to avoid such a problem, but best I can think is when building the pom we should ensure that version of the third party jar stays uniform atleast across xwiki-platform.
Yes you're right.
The solution is to use dependencyManagement in Maven in the top level POM. The way to find the different version is to run the convergence report.
Please feel free to submit patches.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
----- http://www.assembla.com/wiki/show/sachin_mittal about me: -- View this message in context: http://www.nabble.com/Keeping-uniform-jar-versions-across-modules-tp16194595... Sent from the XWiki- Dev mailing list archive at Nabble.com.
Sachin Mittal wrote:
Hi, I have frequently encountered this problem that versions of third party jars across modules are not uniform. Like the xwiki-core uses commons-lang of version 2.1 and lucene 2.3. Similarly some module uses xerces-impl of version 2.0.2 where as some other 2.8.1.
As the xwiki build can be made of different modules as per custom requirements, when we bring these modules together there is a conflict in the jar versions.
This way different jars of same version end up in the lib directory and causes class not found exceptions.
I don't know what is the best way to avoid such a problem, but best I can think is when building the pom we should ensure that version of the third party jar stays uniform atleast across xwiki-platform.
That should happen, but I think this is a maven bug: when declaring a dependency if type "war", the sub-dependencies are not considered, as it is assumed that they are already bundled. 1. When building the platform-web, platform-core along with a bunch of dependencies are placed inside the resulting war. 2. When building product-enterprise-web, for example, the platform-web war is expanded, and the plugins along with their dependencies are added. Now, some plugins use different versions of the dependencies than the core, but since Maven discarded the platform-web -> platform-core dependencies, it doesn't know that different versions are in there already, so it adds the new dependencies required by the plugins, without removing the old ones from the platform-web expanded war. We should fix the different dependency versions (which I already did for Lucene, as it is not really needed in the core, just in the lucene-plugin). I also noticed the two commons-lang that show up in the XE libs, and was planning to investigate it later. -- Sergiu Dumitriu http://purl.org/net/sergiu/
I was thinking about using a <dependencyManagement> section in the top level POM but I'm hesitating now... It should be possible for each product to have different versions of dependencies and thus I don't think it's correct to set common dep versions in the top level POM. I think the dependencyManagement sections should be set in the products. Now that raises the question of the platform... Do we want to force the same versions in the plugins and in the core for example? The answer is probably yes since otherwise it won't be possible to have the plugins+core in the same product. All that said, it would be better to have the same version for all modules so I'm tempted to commit my dependencyManagement stuff in the top level POM for now. I'm not convinced this is the best thing to do but I'll commit it and revert it if need be. Let me know what you think. BTW we should run the dependency convergence report (ex: http://maven.apache.org/ref/2.1-SNAPSHOT/dependency-convergence.html) to find all discrepancies. Thanks -Vincent On Mar 21, 2008, at 5:24 PM, Sergiu Dumitriu wrote:
Sachin Mittal wrote:
Hi, I have frequently encountered this problem that versions of third party jars across modules are not uniform. Like the xwiki-core uses commons-lang of version 2.1 and lucene 2.3. Similarly some module uses xerces-impl of version 2.0.2 where as some other 2.8.1.
As the xwiki build can be made of different modules as per custom requirements, when we bring these modules together there is a conflict in the jar versions.
This way different jars of same version end up in the lib directory and causes class not found exceptions.
I don't know what is the best way to avoid such a problem, but best I can think is when building the pom we should ensure that version of the third party jar stays uniform atleast across xwiki-platform.
That should happen, but I think this is a maven bug: when declaring a dependency if type "war", the sub-dependencies are not considered, as it is assumed that they are already bundled.
1. When building the platform-web, platform-core along with a bunch of dependencies are placed inside the resulting war.
2. When building product-enterprise-web, for example, the platform-web war is expanded, and the plugins along with their dependencies are added. Now, some plugins use different versions of the dependencies than the core, but since Maven discarded the platform-web -> platform-core dependencies, it doesn't know that different versions are in there already, so it adds the new dependencies required by the plugins, without removing the old ones from the platform-web expanded war.
We should fix the different dependency versions (which I already did for Lucene, as it is not really needed in the core, just in the lucene-plugin). I also noticed the two commons-lang that show up in the XE libs, and was planning to investigate it later. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mar 22, 2008, at 12:43 AM, Vincent Massol wrote:
I was thinking about using a <dependencyManagement> section in the top level POM but I'm hesitating now...
It should be possible for each product to have different versions of dependencies and thus I don't think it's correct to set common dep versions in the top level POM. I think the dependencyManagement sections should be set in the products.
Now that raises the question of the platform... Do we want to force the same versions in the plugins and in the core for example? The answer is probably yes since otherwise it won't be possible to have the plugins+core in the same product.
All that said, it would be better to have the same version for all modules so I'm tempted to commit my dependencyManagement stuff in the top level POM for now. I'm not convinced this is the best thing to do but I'll commit it and revert it if need be.
Let me know what you think.
BTW we should run the dependency convergence report (ex: http://maven.apache.org/ref/2.1-SNAPSHOT/dependency-convergence.html) to find all discrepancies.
BTW I've deployed it here: http://maven.xwiki.org/site/xwiki-core-parent/xwiki-core-component/dependenc... -Vincent
On Mar 21, 2008, at 5:24 PM, Sergiu Dumitriu wrote:
Sachin Mittal wrote:
Hi, I have frequently encountered this problem that versions of third party jars across modules are not uniform. Like the xwiki-core uses commons-lang of version 2.1 and lucene 2.3. Similarly some module uses xerces-impl of version 2.0.2 where as some other 2.8.1.
As the xwiki build can be made of different modules as per custom requirements, when we bring these modules together there is a conflict in the jar versions.
This way different jars of same version end up in the lib directory and causes class not found exceptions.
I don't know what is the best way to avoid such a problem, but best I can think is when building the pom we should ensure that version of the third party jar stays uniform atleast across xwiki-platform.
That should happen, but I think this is a maven bug: when declaring a dependency if type "war", the sub-dependencies are not considered, as it is assumed that they are already bundled.
1. When building the platform-web, platform-core along with a bunch of dependencies are placed inside the resulting war.
2. When building product-enterprise-web, for example, the platform- web war is expanded, and the plugins along with their dependencies are added. Now, some plugins use different versions of the dependencies than the core, but since Maven discarded the platform-web -> platform-core dependencies, it doesn't know that different versions are in there already, so it adds the new dependencies required by the plugins, without removing the old ones from the platform-web expanded war.
We should fix the different dependency versions (which I already did for Lucene, as it is not really needed in the core, just in the lucene-plugin). I also noticed the two commons-lang that show up in the XE libs, and was planning to investigate it later. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol wrote:
I was thinking about using a <dependencyManagement> section in the top level POM but I'm hesitating now...
It should be possible for each product to have different versions of dependencies and thus I don't think it's correct to set common dep versions in the top level POM. I think the dependencyManagement sections should be set in the products.
Now that raises the question of the platform... Do we want to force the same versions in the plugins and in the core for example? The answer is probably yes since otherwise it won't be possible to have the plugins+core in the same product.
All that said, it would be better to have the same version for all modules so I'm tempted to commit my dependencyManagement stuff in the top level POM for now. I'm not convinced this is the best thing to do but I'll commit it and revert it if need be.
Let me know what you think.
We can override dependencies per module or per product.
BTW we should run the dependency convergence report (ex: http://maven.apache.org/ref/2.1-SNAPSHOT/dependency-convergence.html) to find all discrepancies.
Thanks -Vincent
On Mar 21, 2008, at 5:24 PM, Sergiu Dumitriu wrote:
Sachin Mittal wrote:
Hi, I have frequently encountered this problem that versions of third party jars across modules are not uniform. Like the xwiki-core uses commons-lang of version 2.1 and lucene 2.3. Similarly some module uses xerces-impl of version 2.0.2 where as some other 2.8.1.
As the xwiki build can be made of different modules as per custom requirements, when we bring these modules together there is a conflict in the jar versions.
This way different jars of same version end up in the lib directory and causes class not found exceptions.
I don't know what is the best way to avoid such a problem, but best I can think is when building the pom we should ensure that version of the third party jar stays uniform atleast across xwiki-platform.
That should happen, but I think this is a maven bug: when declaring a dependency if type "war", the sub-dependencies are not considered, as it is assumed that they are already bundled.
1. When building the platform-web, platform-core along with a bunch of dependencies are placed inside the resulting war.
2. When building product-enterprise-web, for example, the platform-web war is expanded, and the plugins along with their dependencies are added. Now, some plugins use different versions of the dependencies than the core, but since Maven discarded the platform-web -> platform-core dependencies, it doesn't know that different versions are in there already, so it adds the new dependencies required by the plugins, without removing the old ones from the platform-web expanded war.
We should fix the different dependency versions (which I already did for Lucene, as it is not really needed in the core, just in the lucene-plugin). I also noticed the two commons-lang that show up in the XE libs, and was planning to investigate it later.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (3)
-
Sachin Mittal -
Sergiu Dumitriu -
Vincent Massol