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.
Despite from the fact that modifications of shared classes should not happen too often, any changes (can) have impact to the implementation.
Let's say we have a modification in one of the shared classes because we need a new feature or we change some behaviour.
Two possible scenarios:
S1. Shared classes are part of "Apache MyFaces Implementation"
The modification is counted a minor change and we have to release a new minor release for "Apache MyFaces Implementation".
S2. Shared classes are a separate project (let's call it "Apache MyFaces Shared")
We release a new version of "Apache MyFaces Shared". Now, the "Apache MyFaces Implementation" is no longer in sync with the latest shared release: Current Implementation is possibly not compatible to this latest Shared release. So, what to do?
- We could document, that latest Impl is compatible to penultimate Shared 1.2.3 and is compatible/not compatible to latest Shared 1.2.4 --> Bad for people who seldom read docs
- We could held the release numbers of Impl and Shared always in sync. So, in this case we would instantly release a new Impl version 1.2.4 --> Lazy doc readers feel confident --> but we have nothing won compared to scenario 1
quod erat demonstrandum ;-)
So, I'm +1 for helding api+shared+impl together
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?)
agreed, +1 for having only four jars
Manfred
