I recollected all the issues, ideas, and feedback and tried to summarize them (from my personal POV):
========================================== Here is a "management summary" of what we could/should end with: * A "myfaces-shared" project, housing all MyFaces-specific classes shared between impl and the MyFaces component libs. * A "myfaces-commons" project with helpers, utils and goodies that are useful for the whole JSF community. * myfaces-shared itself will never be released and none of the MyFaces subprojects will have a direct dependency on it. Alternatively, every project that needs shared classes will be provided a custom shared lib with private namespace, so that shared classes of different versions won't clash during runtime. * myfaces-commons will have a well defined and stable API and have it's own release cycle once in a bright future. ========================================== And here are the details: * We create a new "shared" SVN module (artifactId = "myfaces-shared") that starts off with all classes currently in commons. Namespace will be "org.apache.myfaces.shared.*" * myfaces-shared will have sub-modules that represent the custom dependency libs with private namespace for each MyFaces subproject that needs shared classes (only impl and tomahawk so far). All (=both) artifacts will automatically be created from the same source that sits in the Maven parent module "myfaces-shared: - Artifact "myfaces-shared-impl" with namespace "org.apache.myfaces.impl.shared.*" - Artifact "myfaces-shared-tomahawk" with namespace "org.apache.myfaces.tomahawk.shared.*" * We flush everything from "commons" and plan to refill it with real commons classes - ie. classes with public interest that make sense outside the MyFaces scope as well AND which have a well designed and stable API. To achieve this the new "commons" subproject will be divided into an api and an impl part (as suggested by the John and Adam): myfaces-commons-api-x.y.z.jar and myfaces-commons-impl-x.y.z.jar ========================================== And now the "How?": Sean, anything that speaks against creating a shared SVN module in trunk right now? I think we could do the following to get our core released ASAP: 1. Forget about already released myfaces-commons-1.1.2.jar (we "unrelease" it somehow) and go back to the start. 2. Create the "shared" SVN module with the two submodules "shared-impl" and "shared-tomahawk". 3. Move everything from commons to shared and change namespace to "org.apache.myfaces.shared.*". 4. Build the two dependency libs myfaces-shared-impl and myfaces-shared-tomahawk. 5. Refactor impl to use the org.apache.myfaces.impl.shared.* classes 6. Refactor tomahawk to use the org.apache.myfaces.tomahawk.shared.* classes At this point we are ready to start the (now really independent!) release processes for impl-1.1.2 and tomahawk-1.1.2 Thougths? Please consider carefully. IMO this all sounds more complicated than it really is. I know there is some pressure for the release. And many of you will have the feeling that it's better to release fast and do massive refactoring afterwards. The point is: once we have an official core release out in the wild that dependes on an official commons release, the chance for doing this all without "collateral damage" (oh, I hate this term) is gone. Manfred On 2/22/06, Sean Schofield <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > > >
