[xwiki-devs] [Proposal] Strategy for storing modified artifacts in XWiki's remote repo
Hi, So far we've used the strategy of using a "xwiki" classifier when we mad changes to artifacts or their poms (we actually forgot to do that for some but that's another story...). The problem is that classifier don't work since: * there's a single pom file for all classifiers * the pom is retrieved before the artifact * if there's another remote repo before the xwiki repo and that pom file exists in this other remote repo it'll be used instead of ours For the record we had 2 problems with jfreechart and jackrabbit which caused this issue to appear. Solution: I propose to publish modified artifacts (the artifact itself of its pom) into our own groupId (best practice) and I propose to prefix them with "xwiki.". For example for "org.apache.jackrabbit" that would become "xwiki.org.apache.jackrabbit". I've done that for jfreechart and jackrabbit here: http://maven.xwiki.org/externals/xwiki/ WDYT? Thanks -Vincent
Vincent Massol wrote:
Hi,
So far we've used the strategy of using a "xwiki" classifier when we mad changes to artifacts or their poms (we actually forgot to do that for some but that's another story...). The problem is that classifier don't work since: * there's a single pom file for all classifiers * the pom is retrieved before the artifact * if there's another remote repo before the xwiki repo and that pom file exists in this other remote repo it'll be used instead of ours
For the record we had 2 problems with jfreechart and jackrabbit which caused this issue to appear.
Solution:
I propose to publish modified artifacts (the artifact itself of its pom) into our own groupId (best practice) and I propose to prefix them with "xwiki.".
For example for "org.apache.jackrabbit" that would become "xwiki.org.apache.jackrabbit".
I've done that for jfreechart and jackrabbit here: http://maven.xwiki.org/externals/xwiki/
WDYT?
First of all, why do we have these modified dependencies? I don't like changing the group Id. I know that using a classifier doesn't work, but we can use a keyword in the version (<version>1.0-xwiki</version>). This should work, and it prevents duplicate jars. For example, if we package a dependency that is also used by another transitively, we'd have to manually exclude it. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Mar 19, 2009, at 7:37 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
Hi,
So far we've used the strategy of using a "xwiki" classifier when we mad changes to artifacts or their poms (we actually forgot to do that for some but that's another story...). The problem is that classifier don't work since: * there's a single pom file for all classifiers * the pom is retrieved before the artifact * if there's another remote repo before the xwiki repo and that pom file exists in this other remote repo it'll be used instead of ours
For the record we had 2 problems with jfreechart and jackrabbit which caused this issue to appear.
Solution:
I propose to publish modified artifacts (the artifact itself of its pom) into our own groupId (best practice) and I propose to prefix them with "xwiki.".
For example for "org.apache.jackrabbit" that would become "xwiki.org.apache.jackrabbit".
I've done that for jfreechart and jackrabbit here: http://maven.xwiki.org/externals/xwiki/
WDYT?
First of all, why do we have these modified dependencies?
We have quite a few of them. It would be too long to explain here. Just look at the pom.xml, there are comments for each modified artifacts explaining why we had to do this. What should be done is that we need to periodically review to see if whatever issue there was is solved to drop our custom artifacts.
I don't like changing the group Id. I know that using a classifier doesn't work, but we can use a keyword in the version (<version>1.0-xwiki</version>). This should work, and it prevents duplicate jars. For example, if we package a dependency that is also used by another transitively, we'd have to manually exclude it.
That was the other option but I consulted withe maven gurus before proposing the groupId. As I mentioned this is the best practice in the maven community it seems. When you modify an artifact it becomes yours and the groupId is the way to signal an artifact is yours. Thanks -Vincent
Vincent Massol wrote:
On Mar 19, 2009, at 7:37 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
Hi,
So far we've used the strategy of using a "xwiki" classifier when we mad changes to artifacts or their poms (we actually forgot to do that for some but that's another story...). The problem is that classifier don't work since: * there's a single pom file for all classifiers * the pom is retrieved before the artifact * if there's another remote repo before the xwiki repo and that pom file exists in this other remote repo it'll be used instead of ours
For the record we had 2 problems with jfreechart and jackrabbit which caused this issue to appear.
Solution:
I propose to publish modified artifacts (the artifact itself of its pom) into our own groupId (best practice) and I propose to prefix them with "xwiki.".
For example for "org.apache.jackrabbit" that would become "xwiki.org.apache.jackrabbit".
I've done that for jfreechart and jackrabbit here: http://maven.xwiki.org/externals/xwiki/
I don't like changing the group Id. I know that using a classifier doesn't work, but we can use a keyword in the version (<version>1.0-xwiki</version>). This should work, and it prevents duplicate jars. For example, if we package a dependency that is also used by another transitively, we'd have to manually exclude it.
That was the other option but I consulted withe maven gurus before proposing the groupId. As I mentioned this is the best practice in the maven community it seems. When you modify an artifact it becomes yours and the groupId is the way to signal an artifact is yours.
Well, I agree somehow with the part that changing an artifact means that it no longer belongs to the original group. However, the main problem is that you always have to be careful to exclude the original artifact from transitive dependencies, at least until http://jira.codehaus.org/browse/MNG-1977 is fixed. And I also think that minor changes are not that important to be considered a different artifact. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Mar 20, 2009, at 4:14 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
On Mar 19, 2009, at 7:37 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
Hi,
So far we've used the strategy of using a "xwiki" classifier when we mad changes to artifacts or their poms (we actually forgot to do that for some but that's another story...). The problem is that classifier don't work since: * there's a single pom file for all classifiers * the pom is retrieved before the artifact * if there's another remote repo before the xwiki repo and that pom file exists in this other remote repo it'll be used instead of ours
For the record we had 2 problems with jfreechart and jackrabbit which caused this issue to appear.
Solution:
I propose to publish modified artifacts (the artifact itself of its pom) into our own groupId (best practice) and I propose to prefix them with "xwiki.".
For example for "org.apache.jackrabbit" that would become "xwiki.org.apache.jackrabbit".
I've done that for jfreechart and jackrabbit here: http://maven.xwiki.org/externals/xwiki/
I don't like changing the group Id. I know that using a classifier doesn't work, but we can use a keyword in the version (<version>1.0-xwiki</version>). This should work, and it prevents duplicate jars. For example, if we package a dependency that is also used by another transitively, we'd have to manually exclude it.
That was the other option but I consulted withe maven gurus before proposing the groupId. As I mentioned this is the best practice in the maven community it seems. When you modify an artifact it becomes yours and the groupId is the way to signal an artifact is yours.
Well, I agree somehow with the part that changing an artifact means that it no longer belongs to the original group. However, the main problem is that you always have to be careful to exclude the original artifact from transitive dependencies,
Good point. I've discussed it again on the maven irc channel and we agreed that it's slightly better to do this: 1) use a version suffix 2) use a dependencyManagement section to ensure our version is picked. Otherwise even if you change a version from 1.0 to 1.0-xwiki you might still need to exclude the 1.0 version if that's used somewhere else. Actually when comparing versions maven will think 1.0-xwiki is older than 1.0... So I'm changing my proposal to use a suffixed version instead of a different groupid. Thanks -Vincent
at least until http://jira.codehaus.org/browse/MNG-1977 is fixed. And I also think that minor changes are not that important to be considered a different artifact.
participants (2)
-
Sergiu Dumitriu -
Vincent Massol