On Dec 14, 2006, at 3:42 AM, Craig McClanahan wrote:
It's just what the POM says, but I don't know how to override it. In
1.1.1 MyFaces used the "myfaces" groupId and now they use
"org.apache.myfaces". Because of this Maven doesn't know that my
dependency on MyFaces 1.1.5 should override Shale's dependency on
1.1.1. I thought I saw a way somewhere to work around that, but I
can't find it now.
Yah, dependencies that rename themselves can definitely be a
problem :-(. I
kiboshed the idea of renaming Commons Digester 1.8's group id for
essentially the same issue. The theoretical solution to this is
that your
downstream dependency (MyFaces in this case) would publish a
"redirect" pom
that says any reference to "myfaces:myfaces-api" now referes to "
org.apache.myfaces:myfaces-api" (and the same for the impl jar), but
apparently this is not trivially simple yet with Maven.
That's right, the redirect. I'll look that up and see if I can use
it while we're working on the next release.
Ideally, we should be able to incorporate an arbitrary set of Shale
modules
into a "release", while other modules might be releaseable
separtely. Later
on, we need to be able to merge something that becomes mature (say,
shale-tiles), while also being able to omit something that is -- at
that
point in time -- undergoing some destabilizing development.
I'm hoping our resident Maven/SVN geniuses can help identify viable
strategies for executing on these ideals. If not, we might have to
go with
the alternative of a combined release with different quality grades
(which
it sounds like Struts2 is going to do).
Let me make sure I understand what we have. Please correct any
misunderstandings below.
shale-master.pom - This is the base POM for the whole project. It
inherits from an org.apache parent. We only have to release a new
version of this if the information contained in it changes, right
(i.e. add new committer, mailing list, svn changes, etc.) And we can
release it independently of everything else?
shale-parent.pom - The base POM for shale subprojects. It defines
the modules, base dependencies, etc. If we release anything (shale-
remoting, for example), we also have to release shale-parent, which
means we have to release everything, right?
I guess one brute force method to release only certain artifacts
would be to remove the modules we don't want to release from the
parent POM, then replace them after running the release process.
Kinda sucks, but it might work. Before we roll a release at work we
have to comment out a bunch of SNAPSHOT plugins in the POM that don't
really apply to the released artifacts.
Greg
