Now that I have thought about Manfred's proposal its starting to make more sense to me. Here is my revised proposal. It will allow us to make progress on this and still defer the final decision for several days.
1.) Create a "shared" subproject. Leave the trunk empty and copy the existing commons code to a new 2.0 branch. 2.) Refactor the code in the shared branch to org.apache.myfaces.shared 3.) Create an shared-impl project beneath the shared subproject. Inside this dir will be a POM that will take care of creating the new myfaces-shared-impl.jar artifact Use maven trickery to search and replace so that refs are now org.apache.myfaces.shared.impl 4.) Publish the new myfaces-shared-impl.jar as a 2.0.0-SNAPSHOT 5.) Refactor the current *branch* of the core to use the new snapshot. Tweak the maven build so that it explodes the snapshot jar and dumps the classes into the target/classes. Resulting myfaces-impl.jar now has its own "frozen snapshot" of the shared code built in. This will allow Manfred to procede without delay and we still have time to debate the merits of this approach. If we decide to vote +1 to this then we would move the commons trunk to the new shared trunk and retire the commons subproject (until we have a true commons someday.) I believe this will allow us to eventually merge the branch down to the trunk even though we have renamed everything. Ideally we make little to no changes on the commons trunk while this is going on. Of course tomahawk trunk would then be refactored to use the new shared package names. I have lots more ideas/questions but I need to head to my day job. I do think that we should consider resolving this ASAP and before the core release. Lets get this right so we don't have to introduce a commons.jar Sean On 2/22/06, Sean Schofield <[EMAIL PROTECTED]> wrote: > This is a really big issue to wrap our collective heads around. Maybe > we should focus on the immediate problem first? The immediate > problem, as I see it, is that we are about to release the core and it > has shared code that will potentially conflict with the same shared > code in tomahawk. > > It will be easier (for me) at least if we limit our discussion to this > unless the potential solution being discussed would make it much > harder down the line to do some of these long run ideas. > > Sean > > On 2/22/06, Stan Silvert <[EMAIL PROTECTED]> wrote: > > > Once our refactoring of commons classes into namespace > > > org.apache.myfaces.commons.* is done we can easily change namespace > > > for inlining by doing String search and replace on source level: > > > replace "org.apache.myfaces.commons" by > > > "org.apache.myfaces.impl-commons" (or alike) > > > I already have a working proof-of-concept prototype on my local disk, > > > but we need the org.apache.myfaces.* --> org.apache.myfaces.commons.* > > > refactoring first. > > > > > > Manfred > > > > I don't think that will quite do it. You still have a versioning > > problem. > > > > As I understand it, this will meant that commons doesn't have a standard > > release cycle. Without a standard release, the commons API would be in > > constant flux. > > > > At the very least, you would have to tag commons every time you do a > > release of a project that relies on it. This has its problems too. > > > > (Sorry for the length of this :-) ) > > Suppose there is a method Foo.foo(StringBuffer s) in commons, written by > > a developer in project A. However, this developer doesn't consider this > > to be a stable API. He's still working things out. > > > > The developer in Project B likes the Foo.foo() method and decides to use > > it in 1.0. > > > > Project B 1.0 is released. > > > > The Project A developer decides that passing in a mutable object is > > dangerous, so he changes it to Foo.foo(String s). > > > > Now Project B relies on a method that no longer exists. In fact, he was > > even relying on the mutability of s. This is generally a bad thing to > > do, but for some reason, it makes sense for Project B. > > > > So what does he do if he needs to fix something in a patch branch? He > > can check out the tagged version of commons, but what if he needs to > > patch commons itself? Now he's stuck. > > > > The more I think about the weird scenarios, the more I think that > > commons needs its own stable release. > > > > Stan > > > > > > > > > > > On 2/22/06, Stan Silvert <[EMAIL PROTECTED]> wrote: > > > > > To reduce the risk of version conflicts and to make the release > > cycle > > > > > of core and tomahawk really independent, the shared classes should > > not > > > > > be released as JAR, but should automatically be repackaged and > > > > > "inlined" into impl, tomahawk, tobago, etc. > > > > > > > > > > Thoughts? > > > > > > > > > > Manfred > > > > > > > > Interesting idea. Do you know of a tool that can easily pull this > > off? > > > > > > > > Stan > > > > > > >
