On 12/13/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
On Dec 13, 2006, at 5:47 PM, Craig McClanahan wrote: > The 1.0.3 release does not work out of the box for us >> because we are using MyFaces 1.1.5 and Shale 1.0.3 depends on MyFaces >> 1.1.1. > > Is it actually a hard dependency or just what the Maven POM says. > Can't say > that I have actually tried that combination. 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. Besides, I really do want to see us get another
release out - hopefully one that can go GA.
Me too :-)
One thing that might affect Greg's enthusiasm :-) I'd like to see > us do is > try to position for a GA release of everything except shale-tiles, > either by > marking it with a separate release grade when we ultimately vote, > or by > making it available separately as its own release. I think we can > be ready > to have API stability on everything else in just a short while. I agree. I don't think the tiles piece should hold up the whole project from going GA. I want to have a way to promote components to GA as they are ready. I think I prefer the approach of marking separate release grades over creating separate releases. It seems like there's too much to do to roll out a release for each component to have its own cycle. We already distribute everything as separate packages, right? It doesn't seem like it would be too hard to apply a quality label to each package individually.
I agree with you philosophically :-). The devil, however, is in the details of how we manage branches and tags. The MyFaces folks went through an extended discussion on this topic, and ended up lumpting all their artifacts together. I don't think that's the optimum response, but I haven't thought through an overall strategy for dealing with the minutae. 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).
Longer term, I'd also like us to think of the following strategy > when we do > achieve a 1.0.x GA-graded release: > > * Branch the 1.0 codebase at that point > > * Start working on 1.1 things on the trunk > > * Put new features only into the trunk > > * As we fix bugs in the trunk, backport relevant ones to the 1.0 > branch I really like this idea. This is basically the way we're doing it at work. It was the only way I could think of to be able to apply emergency patches to a stable codebase without deploying unstable features.
Cool -- I like it for the same reason. Craig
