myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manfred Geiler" <>
Subject Re: warning - use of class.getName() in shared
Date Thu, 09 Mar 2006 19:34:32 GMT
On 3/9/06, Stan Silvert <> wrote:
> I assume this was all discussed before, but I'm glad the discussion has
> been raised again.  I have also been having trouble understanding what
> is going on and why.
> My current understanding is as follows:
> 1)  There is some common code that both core and tomahawk (and others?)
> use.

Yes, and depending on where it is in use it will reside in
 * myfaces-shared = code that is redundant for impl (core) and tomahawk
 * commons-jsf (does not yet exist) = functionality that is convenient
for impl, tomahawk and others (JSF component authors, JSF webapp
developers, ...)

Please note that I used the following naming conventions to make it
more clear from the name:
 "myfaces-shared": code that is shared within the myfaces umbrella project
 "commons-jsf": code that is independent of myfaces and useful for
every JSF developer

> 2)  We want core and tomahawk to have different release schedules.

Yes. Core will become stable sometime (hopefully!) and time between
releases will become longer.
Tomahawk will be released more often. New features, new components,
new magic stuff, ...

> 3)  We want tomahawk to be usable with the RI

Yes. RI or any other JSF impl - is there one?!  :-)

> 4)  The decision was to let the common code's source become bound to
> each project at build time by a global package name change.


> Please correct me if I have this wrong.
> This is an interesting approach, but it is also one I have never
> encountered before.  I'm surprised nobody has come forward and said,
> "Don't do that!! We did that on X project and it caused Y problems."
> So, maybe this approach has merit.  Time will tell.

Yes. Good phrased.
And I also wonder why nobody said: "Hey this is going back to
stone-age when we had to decide between dynamically or statically
linking C libraries."
Sorry, don't meant to offend any current C programmer of course - if
any one is listening... ;-)

But in fact: What we are doing here is static linking in Java.
Interesting, isn't it?

> Besides the issues that have been raised in this thread, the thing I
> have worried about is how we can recreate a release.  Since the modified
> common source is not checked in, how would you recreate a tomahawk build
> with the proper version of the common source?

Rest assured. It's even better. Not only do we tag/branch the shared
code when we decide to either release core or tomahawk. What is more,
we could even deploy and release the myfaces-shared-impl.jar and
myfaces-shared-tomahawk.jar if we decided to do that. So, Maven
automatically gives you the right version of shared classes. Although
I'm not sure if that is really necessary, because you can always
rebuild them from the tagged source.

> Another thing I was wondering.  Why not make a clean break right now?
> That is, let each project have its own version of the common source that
> gets checked in today?  Then they can be maintained independently.

DRY principle! (don't repeat yourself)
We should not have redundant code in impl and tomahawk, right?


> Stan Silvert
> JBoss, Inc.
> callto://stansilvert
> > -----Original Message-----
> > From: Mike Kienenberger []
> > Sent: Thursday, March 09, 2006 11:32 AM
> > To: MyFaces Development
> > Subject: Re: warning - use of class.getName() in shared
> >
> > I'm completely +1 for what Manfred is saying here.   I don't think
> > there's ever been a clearer explanation of what we're doing and why
> > with the current setup.  In fact, I never completely understood the
> > details until this mesage.
> >
> > Note that I'm probably the most-adversely-affected person by this (I
> > don't have any Maven knowledge, and I am an Eclipse user, so I'm
> > dependent on Werner/Mario/others for telling me how to make all of
> > this work together).
> >
> > But I don't see any problems with what Manfred has suggested from an
> > IDE (Eclipse-centric) point of view.
> >
> > And as he points out, if there's an issue revealed by this change,
> > then it's a real dependency issue between tomahawk and Impl that needs
> > to be fixed rather than re-hidden.
> >
> >
> > On 3/9/06, Manfred Geiler <> wrote:
> > > Mario,
> > > As mentioned earlier, yes, there is some pain with the new shared
> > > structure. But my feeling is that most of the pain is due to the
> fact
> > > that we have to break with some (bad) habits.
> > >
> > > Please think of the two libs shared_impl and shared_tomahawk as two
> > > *different* things. This affects debugging as well. There is no such
> > > thing as a breakpoint in shared. Because there is no such thing as a
> > > shared lib from the view of impl or tomahawk. You must really
> discard
> > > that kind of thinking from your brain. The shared module is a *tool*
> > > to create the two different libraries shared_impl and
> shared_tomahawk.
> > > Nothing more! There is no (and there must not be any) single
> > > dependency on shared from core or tomahawk. So, from the perspective
> > > of core and tomahawk there are the two jars shared_impl and
> > > shared_tomahawk. They differ in nothing to other (third-party) libs
> > > that core and tomahawk depend on. Even more, there exists a
> > > *-source.jar for each of them that can be used for convenience in
> > > IDEs. You can debug or set a breakpoint within commons-logging code,
> > > can't you? So, I do not see any reason why one should not be able to
> > > debug shared_impl or shared_tomahawk in any IDE.
> > >
> > > The other issue is the class.getName() (or FQN-Strings) problem.
> > > Yes, of course, this can be a problem now. I feared things like that
> > > and I will try to help resolve those issues ASAP. Let's look at the
> > > key of the problem here: Why is it an issue when shared_impl and
> > > shared_tomahawk have different FQN-Strings during runtime? Actually
> > > having a problem with that is a sign for having a *functional
> > > dependency* between shared_impl and shared_tomahawk - which is a
> > > no-no! We must get rid of any functional dependency between them
> > > because otherwise
> > >  * we still are away from beeing able to release core and tomahawk
> in
> > > different release cycles, and
> > >  * we have no guarantee that tomahawk is independent of myfaces core
> -
> > > ie. that tomahawk is able to run on top of another JSF impl
> > >
> > > Sorry, I do not see a practicable alternative to our current
> > > architecture. But, of course, we can discuss everything, no
> question!
> > > Please, tell me if, if there are still unclear issues.

View raw message