myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Fallows <>
Subject Re: [maven] We need to make a decision
Date Mon, 16 Jan 2006 18:29:34 GMT
On 1/16/06, Sean Schofield <> wrote:
> 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:


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

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?

Kind Regards,
John Fallows.

Author Pro JSF and Ajax: Building Rich Internet Components

View raw message