That's a pretty good summary.
The existing setup was created precisely because the old approach (a
plain old shared jar that multiple projects depended on) was a major
pain for the reasons listed by Paul below.
Note that even with the existing setup, other projects can use the
shared jar. They just use their own *copy* of it. The current approach
of having the shared project create orchestra/tomahawk/shared flavours
of itself is not optimal; really there should be one shared jar, and
other projects should "copy-and-repackage" as needed. However that's a
little tricky to set up and hasn't been high on anyone's todo list as
the current approach works.
The fact that when core, tomahawk and orchestra are all used in a single
project then there are 3 copies of the shared classes in memory is
really not significant. I cannot imagine anyone using myfaces in a
mobile java system for example. One con of the existing approach that
was not listed is debugging: it is a minor nuisance to make sure that
your breakpoints in shared code is actually on the one in the
appropriate package. But that isn't terribly hard.
Simon, imagine if there was one jar. Before releasing core-2.0.x would
you really retest tomahawk and orchestra to see if the new version of
shared breaks them? And do you really trust tomahawk and orchestra
release managers to thoroughly test myfaces-core releases against a new
shared release before it is made? With the current setup, such testing
is not so important; a mistake can break snapshot builds but never
production deployments because the shared code changes don't get
"forced" onto other projects. This is particularly important given the
pretty poor unit-test-coverage percentage on myfaces projects.
The binary-compatibility issue below is also very important. A shared
jar means binary-incompatible changes in shared become impossible,
forever. That's pretty scary. With the "private copy" approach an
incompatible change still needs agreement by all projects (svn trunk on
each project needs to be updated to match) but it is possible.
And handling user bugreports becomes exponentially harder too when they
can have various versions of shared lib in their classpath. Yecch.
I would be very reluctant to see a return to a plain jar. I don't want
to have to be paranoid about code changes breaking core or tomahawk
production releases when I just want to fix an orchestra bug that is due
to something in shared.
Regards,
Simon K.
Paul Rivera schrieb:
Hi Simon,
There's another discussion on this here:
http://www.mail-archive.com/[email protected]/msg32495.html
These are basically the main points of the discussion:
pros of an external dependency
* no duplicate code
* other projects can use it
cons of an external dependency
* fundamental projects (core, trinidad) would then depend on an
extra jar
* placing code shared between projects into a normal jar means that
upgrading one project may force the shared jar to be updated,
which can break the other project - unless we enforce 100% binary
and semantic
compatibility between releases of that jar.
I hope this helps you.
I'm a fairly new member of this community. Perhaps someone else can
give a deeper insight on this?
Best Regards,
Paul Rivera
--- On *Mon, 9/29/08, Simon Lessard /<[EMAIL PROTECTED]>/* wrote:
From: Simon Lessard <[EMAIL PROTECTED]>
Subject: Re: MyFaces shared question
To: "MyFaces Development" <[email protected]>,
[EMAIL PROTECTED]
Date: Monday, September 29, 2008, 8:43 AM
Hi Paul,
Thanks for the link, it makes the whole thing clearer. However, is
that point still debatable? I quite disagree about the conclusion
about forcing the upgrade of the core if you upgrade Tomahawk.
Upgrading Tomahawk might force the upgrade of shared, but not
necessarily if the former doesn't depend on a latest change to
shared. Furthermore you don't need to upgrade core if you upgrade
shared if the latter enforce backward compatibility.
Personally I must admit that I don't really like the preprocessing
since it means having two of the same class on the classpath but
in different packages if you use both core and Tomahawk.
Regards,
~ Simon
On Mon, Sep 29, 2008 at 12:10 AM, Paul Rivera
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Hi Simon,
I think this link explains it best:
http://wiki.apache.org/myfaces/Source_Code_Packaging
Best Regards,
Paul Rivera
--- On *Sun, 9/28/08, Simon Lessard
/<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>/* wrote:
From: Simon Lessard <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
Subject: MyFaces shared question
To: "MyFaces-Devs" <[email protected]
<mailto:[email protected]>>
Date: Sunday, September 28, 2008, 7:38 AM
Hi all,
Anyone knows why myfaces-shared is unpacked with a plugin
by Maven instead of being a standard dependency?
Thanks,
~ Simon
