myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manfred Geiler" <manfred.gei...@gmail.com>
Subject Commons refactoring - reloaded [was: Once more: Commons refactoring and releasing]
Date Thu, 23 Feb 2006 12:57:13 GMT
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 <sean.schofield@gmail.com> 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 <sean.schofield@gmail.com> 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 <stan.silvert@jboss.com> 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 <stan.silvert@jboss.com> 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
> > > > >
> > >
> >
>

Mime
View raw message