+1 for the structural change +1 for myfaces-commons.jar Bruno
2005/11/30, Sean Schofield <[EMAIL PROTECTED]>: > I'm ok with commons (myfaces-commons.jar). > > -1 for moving it to jakarta commons (at least for now.) > > sean > > On 11/30/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > > +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 > > > > >
