It is a realistic scenario if you think about JBoss including MyFaces (the implementation) 1.1.0 as a standard somewhere in the server - and you want to upgrade to 1.1.1 in your webapp for the newest and best in the tomahawk components.
regards, Martin On 10/22/05, Keijo Nurmes <[EMAIL PROTECTED]> wrote: > Granted but is it a realistic scenario? > > Does someone want to deploy in same container for example > > myfaces-api.jar 1.1.0 > myfaces-impl.jar 1.1.0 > tomahawk.jar 1.1.1 > > would't it be safer just compile custom build from sources. > I dont know, newer happened to me. > > It just seemed the most natural approach to the MYFACES-663 issue for me. :) > > Alltogether this is not so important to me. I can live with all of > these suggestions. > > How about that release number stuff in jar names. > > Regards, Keijo > > > Martin Marinschek wrote: > > >It's not quite the same. > > > >with John's approach, you can use the tomahawk library in whatever > >version with whatever version of the implementation you would like to > >use. Partticularly, the shared library can co-exist in two different > >versions peacefully. > > > >With Keijo's approach, you are locked in to _one_ special version of share. > > > >regards, > > > >Martin > > > >On 10/22/05, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote: > > > > > >>hear hear! (or is it here here? ;-) ) > >> > >>On 22 Oct 2005, at 12:51, Keijo Nurmes wrote: > >> > >> > >> > >>>Greetings to everyone. > >>> > >>>There is also a third choice . One could separate shared code to its > >>>own jar . (myfaces-shared.jar) > >>>In that way users can decide what to use. > >>> > >>>a) All in one > >>>myfaces-all.jar (Contains tomahawk, impl, api, shared and optionally > >>>sandbox) > >>> > >>>b) Separated pure myfaces > >>>myfaces-api.jar > >>>myfaces-impl.jar > >>>myfaces-shared.jar > >>>tomahawk.jar > >>>(sandbox.jar) > >>> > >>>c) Tomahawk with other implementation > >>>myfaces-shared.jar > >>>tomahawk.jar > >>>(sandbox.jar) other-implementation jars > >>> > >>>If the shared code is meant to be shared in myfaces project, the > >>>duplication is mistake. (My opinion) > >>>Automatic repackaging always duplicates the runtime and working > >>>with such a code is difficult > >>>with modern IDE:s > >>>This is already done in > >>> > >>>http://issues.apache.org/jira/browse/MYFACES-663 > >>> > >>> > >>>I would also prefer release number added in jar-names like > >>>myfaces-api-1.1.1RC3.jar > >>>and I can provide patches for this. (with or without separating shared > >>>:) ) > >>>Regards Keijo > >>> > >>> > >>> > >>> > >>> > >>>John Fallows wrote: > >>> > >>> > >>> > >>>>Hi Everyone, > >>>> > >>>>On 10/19/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>> > >>>>>Well, if we could do b) somewhat automatically, this would be great. > >>>>> > >>>>>John Fallows had proposed something like this for the shared classes > >>>>>of Apache MyFaces - to make sure that Tomahawk and the impl always > >>>>>use > >>>>>the correct implementation of the shared classes. > >>>>> > >>>>>John - I think this is the time at which you could convince us of > >>>>>your > >>>>>suggestion ;) > >>>>> > >>>>> > >>>>> > >>>>Thanks for the segue, Martin. :-) > >>>> > >>>>The Apache MyFaces shared codebase is currently duplicated in both > >>>>MyFaces runtime implementation and the MyFaces Tomahawk extensions. > >>>> > >>>>The major reason for duplicating is to allow the MyFaces Tomahawk > >>>>extensions to have all the classes they need when executing on a > >>>>non-MyFaces Runtime, such as the RI. Otherwise, MyFaces Tomahawk > >>>>would only run in MyFaces Runtime, which would be a non-starter. > >>>> > >>>>However, since there is duplication, then upgrading either of these > >>>>(Runtime / Tomahawk) in a deployed environment independently would > >>>>cause the shared classes to be upgraded as well, for both of the > >>>>projects. This assumes the classpath is setup to place the newest JAR > >>>>last, which might not be the case. This problem leads to a "version > >>>>conflict" for the duplicated shared code. > >>>> > >>>>It seems there are at least two possible resolutions to this problem. > >>>> 1) repackage the shared code in each project to eliminate the impact > >>>>of independent upgrades > >>>> 2) require a specific version combination of MyFaces Runtime / > >>>>MyFaces Tomahawk to ensure the same shared code is present in both > >>>>projects, making classpath ordering unimportant > >>>> > >>>>As far as I know, we currently use #2. However, this places MyFaces > >>>>Runtime at an unnecessary disadvantage compared to the RI. For > >>>>example, any version of MyFaces Tomahawk can run on any version of the > >>>>RI (assuming TCK passes!) However, each version of MyFaces Tomahawk > >>>>is guaranteed to run on (and not adversely impact) exactly one version > >>>>of the MyFaces Runtime. > >>>> > >>>>Therefore, I would recommend that we investigate solution #1 in the > >>>>short term to eliminate these concerns. The same approach can be > >>>>applied for other dependencies that we decide to duplicate in our > >>>>codebase as discussed in this thread. > >>>> > >>>>In general, we should minimize (not eliminate) dependencies, and > >>>>(automatically?) duplicate code only when we decide that a particular > >>>>dependency has shown a track record of being sufficiently incompatible > >>>>across releases. Once that dependency stabilizes, we can stop the > >>>>duplication and establish the (now reliable) dependency. > >>>> > >>>>As far as reporting dependencies is concerned, it might be useful to > >>>>deliver a built-in MyFaces ViewHandler that can serve an XML document > >>>>describing the Classpath and other useful debugging information. Then > >>>>end-users can include that information when filing issues in JIRA, or > >>>>by request on the mailing list. > >>>> > >>>>Kind Regards, > >>>>John Fallows. > >>>> > >>>> > >>>> > >>>> > >>>>>On 10/19/05, Werner Punz <[EMAIL PROTECTED]> wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Simon Kitching wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Hi guys, > >>>>>>> > >>>>>>>Well, you should check out some of the email discussions held on > >>>>>>>commons-dev about this. The general conclusion was that even > >>>>>>>commons > >>>>>>>components should avoid dependencies on other commons components > >>>>>>>where > >>>>>>>feasable. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>Well commons are absolute base libs, but there always is a huge > >>>>>>issue if > >>>>>>you have too much deps, because other stuff has those deps as well > >>>>>>and > >>>>>>you might end up in a conflict once you try to merge myfaces into > >>>>>>other > >>>>>>subsystems. Even commons does not manage it to be outside of > >>>>>>commons deps. > >>>>>> > >>>>>>But as others have stated, there is no sanity in having a copy > >>>>>>paste of > >>>>>>commons classes into the core codebase, because you end up in a > >>>>>>maintenment mess bigger than Mount Everest. > >>>>>> > >>>>>>There are two ways: > >>>>>>a) Try to keep the number of deps as small as possible and > >>>>>>restricted to > >>>>>>the absolut core libs. Commons Lang is probably save, while > >>>>>>commons-httpclient would be probably a different issue. > >>>>>> > >>>>>>b) Push the commons stuff into its own safe namespace so that it > >>>>>>does > >>>>>>not conflict with external namespaces of the same namespace. > >>>>>>(I did that recently by pushing a httpclient and its dependency > >>>>>>into a > >>>>>>supportive.org.apache.xxx namespaces) > >>>>>>This can be done relatively easy via refactoring tools but it is a > >>>>>>huge > >>>>>>codeupdate. Sun for instance did that as well with their own Xerces > >>>>>>bundle which they have bundled with JDK 5.0. > >>>>>>(They pushed it into sun.org.apache.xerces or something similar) > >>>>>> > >>>>>>A total independence of external libs would be good bug only b) > >>>>>>would > >>>>>>allow that in a sane manner and still it is sort of a maintenance > >>>>>>nightmare, because with every release you have to do the refactoring > >>>>>>cycle all over again. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>-- > >>>>> > >>>>>http://www.irian.at > >>>>>Your JSF powerhouse - > >>>>>JSF Trainings in English and German > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>Met vriendelijke groeten, > >> > >>Jan Dockx > >> > >>PeopleWare NV - Head Office > >>Cdt.Weynsstraat 85 > >>B-2660 Hoboken > >>Tel: +32 3 448.33.38 > >>Fax: +32 3 448.32.66 > >> > >>PeopleWare NV - Branch Office Geel > >>Kleinhoefstraat 5 > >>B-2440 Geel > >>Tel: +32 14 57.00.90 > >>Fax: +32 14 58.13.25 > >> > >>http://www.peopleware.be/ > >>http://www.mobileware.be/ > >> > >> > >> > >> > >> > > > > > >-- > > > >http://www.irian.at > >Your JSF powerhouse - > >JSF Trainings in English and German > > > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
