19 Mar
2009
19 Mar
'09
6:09 p.m.
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
19 Mar
19 Mar
7:37 p.m.
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/
9:52 p.m.
New subject: [xwiki-devs] [Proposal] Strategy for storing modified artifacts in XWiki's remote repo
On Mar 19, 2009, at 7:37 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
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.
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.
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
20 Mar
20 Mar
4:14 p.m.
Vincent Massol wrote:
On Mar 19, 2009, at 7:37 PM, Sergiu Dumitriu wrote:
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/
Vincent Massol wrote:
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. 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.
5:17 p.m.
New subject: [xwiki-devs] [Proposal] Strategy for storing modified artifacts in XWiki's remote repo
On Mar 20, 2009, at 4:14 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
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
On Mar 19, 2009, at 7:37 PM, Sergiu Dumitriu
wrote:
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, Vincent Massol wrote:
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. 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. 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.
5719
days inactive
5720
days old
4 comments
2 participants
participants (2)
-
Sergiu Dumitriu -
Vincent Massol