Sean Schofield wrote:
I wanted to resurrect one of our favorite threads ... "Should the
shared code be in its own jar?"
The reason why I bring this up now is that I'm starting to experiment
with an M2 build for MyFaces. In addition to some of the arguments
made earlier we can now add Maven to the list of reasons why we might
want to consider this.
From my early exploration of Maven it seems like the shared stuff can
be handled best by making the impl and tomahawk subprojects have a
dependency on the share project. In the past I have not been too wild
about the shared jar idea but I think Maven may be able to help keep
us and our users informed as to the exact dependencies when using
MyFaces or Tomahawk.
First off, I would suggest we call it *core* instead of share. I
think "core" helps to imply that it is mandatory. They already know
they need api and impl (if they have read the JSF spec.) The "core"
wording will let them know they need this also.
Maven has some cool stuff for maintaining and documenting
dependencies. The tomahawk page of the website can automatically be
updated so that for each new release of tomahawk, the dependency list
will be updated. Its also possible that we can have tomahawk depend
on an earlier version of the core then the impl. So we can compile
against older versions that might be in the third party J2EE distros
(like JBoss). Anyways, the point is that Maven may finally provide
the best solution to this problem so far.
How about the idea of moving the few external dependencies myfaces
nowadays has into their own namespace to avoid conflicts between
versions of those libraries used by myfaces and those used by the
application servers/webapps
(I am talking about stuff like apache commons, which could be moved into
their own respective namespaces, like dependency.org.apache....)
This way we could get rid of most if not all version conflicts which
could arise between the collaboration of myfaces and various app servers.
