OK,
We have been discussing a few important maven-related decisions these
past few days. Its time to make a decision and move on. Here is my
proposal. I'd like to see a couple of +1's and then we can get back
to business. Everything is held up by this matter so lets bring it to
a close.
1.) Make the master pom an official artifact of myfaces. Its a little
weird to have a POM only artifact in the public maven repository but
who cares? Its not a big deal. Everything is downloaded
automatically. This seems to make more sense then hiding it in
api/pom.xml (where it is now.) The master pom is needed my all
modules therefore its a dependency. It could sit in myfaces/pom.xml
except each of the modules is releasable on its own schedule so IMO
there is no other logical alternative.
I know it sounds weird at first, but having a POM dependency is not that strange in the land of Maven. :-)
2.) Directory names vs. artifiact names. Bernd has suggested a
preference for the two matching but this is definitely not a
requirement for maven. I propose core/trunk/api instead of
core/trunk/myfaces-api. There is no *technical* reason for doing this
*either way.* My personal preference is to keep the directory names
as short as possible. The final product will be call myfaces-api.jar
either way.
I agree with Bernd, my preference would be for these to match as well.
When you svn checkout with TortoiseSVN, the local directory name defaults to the last part of the checkout path.
So, if folks are checking out just "api", then there's not enough context in the "api" name for their default local directory name.
Similarly, if folks are checking out trunk, and leave the default name "trunk" for the local directory, then subdirectories of "api", "impl", etc do not provide sufficient context. I've seen this "trunk" checkout technique many times among my colleagues, especially as they were starting out with SVN.
ADF Faces uses the following directory structure:
trunk/
pom.xml
adf-faces-api/
adf-faces-impl/
adf-faces-demo/
adf-faces-build/
Note: this last module, "adf-faces-build" contains metadata that is used at build time, so it's a little different from the "build" module in MyFaces.
3.) Establish a core module. So we have myfaces/core/trunk/api and
myfaces/core/trunk/impl. Bernd and I had started down this road and
stopped at his request. I think the issues that concerned us then can
be addressed now. So can we agree to do this?
What is the purpose of having such a core module?
I would be concerned about releasing code in the same package for both the runtime and the component libraries, where each is versioned and released independently.
Upgrading to a new version of a component library needs to guarantee zero impact on the runtime and having code in overlapping packages violates that principle when both are executed in the context of the same ClassLoader, as only one copy of the overlapping packages can take precedence.
Does this problem get any better or worse in JavaEE 5, where the container is required to include a JSF 1.2 implementation? Would the ClassLoader of the JSF 1.2 implementation be sufficiently isolated from the ClassLoader of each Web Application to not be impacted by having two versions of the overlapping packages?
John Fallows.
--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044
