+1 on the structural change
+0 on name change either way - An argument can be made for any of
the 3 proposed names (share, core or commons) so I'm open to any of
them and let those with passion on one of the 3 sort it out ;-)
TTFN,
-bd-
On Nov 30, 2005, at 1:10 AM, Manfred Geiler wrote:
2005/11/30, Sean Schofield <[EMAIL PROTECTED]>:
I wanted to resurrect one of our favorite threads ... "Should the
shared code be in its own jar?"
The reason why I bring this up now is that I'm starting to experiment
with an M2 build for MyFaces. In addition to some of the arguments
made earlier we can now add Maven to the list of reasons why we might
want to consider this.
From my early exploration of Maven it seems like the shared stuff can
be handled best by making the impl and tomahawk subprojects have a
dependency on the share project. In the past I have not been too
wild
about the shared jar idea but I think Maven may be able to help keep
us and our users informed as to the exact dependencies when using
MyFaces or Tomahawk.
First off, I would suggest we call it *core* instead of share. I
think "core" helps to imply that it is mandatory. They already know
they need api and impl (if they have read the JSF spec.) The "core"
wording will let them know they need this also.
Maven has some cool stuff for maintaining and documenting
dependencies. The tomahawk page of the website can automatically be
updated so that for each new release of tomahawk, the dependency list
will be updated. Its also possible that we can have tomahawk depend
on an earlier version of the core then the impl. So we can compile
against older versions that might be in the third party J2EE distros
(like JBoss). Anyways, the point is that Maven may finally provide
the best solution to this problem so far.
This confirms my feelings that I always had. Although I nearly know
nothing about Maven I start to like it ;-)
My definite
+1 on having a separate jar with all the stuff from the share dir
Regarding the name: I agree that "share" might not be the best of all
names for the end user jar. Although - from a source code view - this
name perfectly describes what it stands for and how the code is used.
Having said that I'm not too happy with "core" as an alternative name.
-0.5 on "core", because:
As I understand it, the core of a software product is the part where
all strings are tied up and the basic processing is done. The core of
MyFaces sits in Impl and API. FacesServlet, UIComponentBase and
UIComponentTag are those classes that come to my mind when I think of
the "core".
The shared classes are a loosely coupled set of utilities, helpers and
convenient base classes. Think of it as kind of commons classes for
JSF. Not having doublechecked this yet, I have the feeling that most
classes of our shared code are even compatible to foreign
implementations (RI). So, why not give it a life of its own and head
for that "commons" direction? So, my proposal is to call it
"myfaces-commons.jar" in the meantime while heading for
"commons-jsf.jar" in the long run - after having coordinated this with
Apache Jakarta Commons guys, of course. We already have some good
connections to the Jakarta team, right?
Yes, sure, comparing our code to Jakarta Commons quality (javadoc in
particular), this might be a long and cumbersome path... ;-)
What do you think?
Manfred
