Hi Paul, Simon and others, I guess those are valid concerns, but I see one evolutivity problem, even with a private copy. Let say you have:
1. Shared class A with method foo() in shared x.y.1 2. Core 1.2.1 uses that method as well as Tomahawk 1.2.1 3. For Core 1.2.2, a change is required to foo's contract, releasing shared x.y.2. For now everything is good since Tomahawk has a private copy of x.y.1 4. Tomahawk 1.2.2 also need a change to foo's contract, but not the same as Core 1.2.2 and furthermore excluding the changes needed so applying the change to shared from x.y.1 base, causing a new release of shared x.y.3. Still everything is fine. >From that point onward though, foo method will have to get reverted back and forth for both projects in order to include other fixes and improvements, no? As for the current structure, I'm not adamantly against it, so given we keep it, do you think I shared rebranch it for 2.0 or try to use 3.0.x? Regards, ~ Simon On Tue, Sep 30, 2008 at 9:01 AM, Simon Kitching <[EMAIL PROTECTED]>wrote: > 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 >> >> >> >> >> >
