> I know it sounds weird at first, but having a POM dependency is not that
> strange in the land of Maven. :-)
OK I think we have general agreement on this. @Bernd: We can always
change this approach later if it doesn't work out.
> 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.
This is easily fixed by checking out to myfaces-api instead of api. I
think the most common use case is to checkout out "current" to
"myfaces" in which case you will have the myfaces parent directory.
Or, in the case of the default naming scheme, the local directory will be called "current".
> 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/
Most seem to prefer the shorter names so I think we should leave them
as short names for now. Since the short names do not affect what goes
into the maven repo there is no harm in doing an svn change later it
we want to.
Okay, maybe we can revisit this later, although I did like your idea of getting it right the first time. :-)
> 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.
Would this be the same as my proposed myfaces-master?
No. This is just for metadata used during the build, and we have our cross-module pom.xml sitting above "adf-faces-api", "adf-faces-impl", etc, as shown in the directory listing for trunk above.
This would be
where the master pom lives. Also, because each module could
potentially be on its own release track, we can't really have a
meaningful top level pom (myfaces/pom.xml). Continuum is going to
build everything for us anyways so big deal.
Without the master pom.xml, you'll get lots of fine-grained build messages from Continuum, one per module. The ADF Faces Continuum build uses the master pom.xml to avoid this problem, and to prevent ongoing attempts to build adf-faces-impl when adf-faces-api is broken, for example.
Perhaps users could keep
a myfaces/pom.xml in their own *local* checkout dir and we can add it
to SVN ignore. This was you can do 'mvn install' on myfaces/pom.xml
and build everything real quick.
That could work, although it's extra hassle to setup per developer.
What's the downside of having a bare bones pom.xml with a <modules> defintion under myfaces/current?
> > 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?
Because it will include both api and impl. We need two separate jars
yet they will always be released together. So we have
myfaces/core/trunk/api and myfaces/core/trunk/impl instead of
myfaces/api/trunk and myfaces/impl/trunk. Tagging and branching is
also simplified. Finally, we can have a myfaces/core/assembly which
assembles everything into a single tarball. Since the final release
product needs to contain both, this seems to make the most sense.
Sorry, I meant what is the purpose of having a core module at all?
(not, why is it structured in this way)
In other words, who is going to use this module. Why does it need to exist?
> 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?
Not sure what you mean by this. Hopefully my explanation of core will
address your concerns. If not, please clarify.
The explanation of core was informative but unrelated to this point.
I'll try to clarify.
We all know how ClassLoaders work, right? All the JARs are on the ClassPath in a particular order, and each Class is accessed by a relative path, eg. org/apache/myfaces/application/NavigationHandlerImpl.class. Usually, due to cooperation between code authors to separate their Classes into different Packages, there are no duplicate entries on the ClassPath for the same relative path. When there are such duplicate entries for the same relative path, then only one will be visible to the ClassLoader, based on the order of the JARs on the ClassPath.
When MyFaces 1.1.x Runtime and MyFaces 1.1.x Tomahawk are both deployed as part of the same Web Application, then their classes will be accessed via the same ClassLoader, so if they have duplicate entries on the ClassPath for the same relative path, then only one of these duplicate entries will be visible to the ClassLoader. If both MyFaces 1.1.x Runtime and MyFaces 1.1.x Tomahawk contain identical overlapping code, then it doesn't matter which one is visible to the ClassLoader, as there will be no difference in behavior.
However, if MyFaces Tomahawk is upgraded to 1.1.x+1 then any changes to the overlapping code may or may not be picked up by the Web Application ClassLoader, depending on the ordering of MyFaces 1.1.x Runtime vs. MyFaces 1.1.x+1 Tomahawk. To make matters worse, the ClassPath ordering of JARs from WEB-INF/lib is unspecified, so there is no way to enforce a particular precedence.
So, in order to avoid this problem, we are forced to upgrade MyFaces 1.1.x+1 Runtime and MyFaces 1.1.x+1 Tomahawk in unison. Hopefully the developer is willing and able to upgrade MyFaces 1.1.x+1 Runtime as well, assuming there are no new bugs or changes in behavior that would negatively impact his Web Application.
When it comes to JavaEE 5, where JSF 1.2 is a required part of the container, I wonder if the JSF 1.2 implementation is on a ClassLoader that is isolated from the Web Application ClassLoader. If so, then it should be possible to have MyFaces 1.2.x Runtime on the JavaEE Container ClassLoader, and MyFaces 1.2.x Tomahawk on the Web Application ClassLoader, so that they would no longer collide despite having overlapping code, and could therefore be upgraded independently without impacting each other.
Can anyone confirm whether or not this analysis is correct?
Kind Regards,
John Fallows.
--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044
