Isn't having a separate 'shared' jar project an issue? Either it is tied to the impl or to the components. We can't tie the 'shared' jar's release to both; it would put the impl our-of-sync with the components or visa-versa. Releasing the shared jar with the impl makes sense to me.
+1 for the original proposal. (Although I'm OK with any additional packaging permutations) > -----Original Message----- > From: Sean Schofield [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 16, 2005 5:55 AM > To: MyFaces Development > Subject: Re: Project structure and release policy (was Re: Components subproject) > > > 2. The "Apache MyFaces Implementation" (sub)-project > > This is the Main Project consisting of three parts: > > - MyFaces JSR-127 API > > - MyFaces Shared classes > > - MyFaces Implementation > > I think this is a worthy goal but there are some things to consider. > As you say, shared is shared between the components and > implementation. What if there are changes to be made in shared that > are required for a new component? > > A slight variation on your proposal might include four subprojects to > the main project > > 1.) API > 2.) Impl > 3.) Shared > 4.) Components > > Whenever releasing a new Impl you would probably also release a new > Shared. Same for components. > > > All three parts get released as separate jars, but have the same release > > number which is in turn in sync with the JSF spec version. So, first > > official release number we should target at after having passed TCK is 1.1.0 > > All three parts are released in separate jars called: > > myfaces-api-1.1.0.jar > > myfaces-shared-1.1.0.jar > > myfaces-impl-1.1.0.jar > > I like the numbering scheme being consistent with the JSF API. We > would definitely regret *not* doing this. > > > 3. The "Apache MyFaces Components" sub-project > > The MyFaces extended and custom components. > > The release numbering is independent from "Apache MyFaces > > Implementation", but should also be in sync with the JSF Spec. > > Again, I agree with your numbering suggestion. > > > We release the components > > - as a separate jar called myfaces-components-1.x.y (depending on a > > specific myfaces-shared-x.x.x.jar) > > - as an all-in-one jar called myfaces-full-1.x.y (containing shared, > > impl and components - but not the API!) > > > > IMHO, there is no need for a components+shared jar as longs as we > > document the dependency clearly. Quite the contrary, every additional > > jar would make things worse and confuse people that are too lazy to read > > docs (like me) and just copy every jar they find into their lib dir. Ok, > > forget about that. Of course I would never do things like that! ;-) > > Why get rid of components+shared but still have a component + shared + > impl + components? I think you have a good point about confusion with > the different "combination" jars (plus the larger file sizes for the > nightlies.) So why not get rid of all of them and just have the four > separate jars (api, impl, shared and components?) > > > Manfred > > sean >
