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 > > > >
