http://svn.apache.org/viewvc?view=revision&revision=893759
David, thanks for the patch -Matthias On Thu, Dec 24, 2009 at 2:19 PM, Scott O'Bryan <[email protected]> wrote: > Yah guys, thanks for clearing that up. Your right that I didn't take > a look at the patch and mis understood your proposal. +1 to the patch. > > Sent from my iPhone > > On Dec 24, 2009, at 2:27 AM, Matthias Wessendorf <[email protected]> > wrote: > >> Hey David, >> >> On Wed, Dec 23, 2009 at 10:32 PM, David Jencks >> <[email protected]> wrote: >>> I'm afraid there is still a lot of confusion about the proposed >>> patch. The >>> comments don't appear to me to relate to the patch. I'm not sure >>> how to >>> proceed other than through excessive and rather obnoxious >>> repetition, for >>> which I apologize. >> >> :-) No worries >> >>> If there is some more information I could provide to >>> clear things up please let me know what it is. I could provide >>> before-and-after manifest.mf but in my experience these are really >>> hard to >>> see what is going on in due to the rather opaque formatting rules, >>> I think >>> the maven-bundle-plugin configuration from the patch is a lot >>> clearer. >> >> +1 on a patch >> >>> On Dec 22, 2009, at 2:26 PM, Scott O'Bryan wrote: >>> >>> I think I agree with Matthias that this may be problematic. If you >>> compile >>> something against Servlet 3.0 classes, you very well may run into >>> some >>> runtime issues if you then try to use those binaries in a Servlet >>> 2.5 type >>> environment. You generally *WILL NOT* run into problems if you do >>> the >>> reverse. >>> >>> True, but irrelevant to the change proposed in the patch. The >>> patch does >>> not change any dependencies. >> >> I think that was misunderstood ? >> >>> >>> Now that's not to say it's impossible. Trinidad, for instance, >>> builds >>> against the Portlet 2.0 jars yet we work in Portlet 1.0 as well, >>> but we had >>> to use a bunch of proxy objects attached to interfaces and a lot of >>> reflection to get this to work correctly. >>> >>> I guess I'm wondering what issue you have right now with the current >>> dependencies. >>> >>> None, I'm not proposing changing any dependencies. >> >> I think it is now more clear >> >>> >>> Just because myfaces depends on Servlet 2.5 does not mean that >>> geronimo >>> can't depend on Servlet 3.0. They should both be "provided" >>> dependencies. >>> >>> The patch does not relate to maven dependencies in any way. >> >> Yes, correct >> >>> >>> If you *DO* need Servlet 3.0 support as a library, I would suggest >>> adding it >>> as a profile which DOES NOT run by default.. Just my $.02.. >>> >>> A profile would not be able to affect this issue, since we need >>> different >>> osgi metadata in the published jars. We don't care what myfaces >>> builds >>> against. >> >> fair enough :-) >> >>> >>> So, here's the patch: >>> Index: impl/pom.xml >>> =================================================================== >>> --- impl/pom.xml (revision 892639) >>> +++ impl/pom.xml (working copy) >>> @@ -223,13 +223,13 @@ >>> javax.ejb;resolution:=optional, >>> javax.el;version="[1.0.0, 3.0.0)", >>> javax.naming, >>> - javax.persistence;version="[1.0.0, >>> 2.0.0)";resolution:=optional, >>> - javax.portlet;version="[1.0.0, >>> 2.0.0)";resolution:=optional, >>> - javax.servlet;version="[2.5.0, 3.0.0)", >>> - javax.servlet.http;version="[2.5.0, 3.0.0)", >>> - javax.servlet.jsp;version="[2.1.0, 3.0.0)", >>> + javax.persistence;version="[1.0.0, >>> 2.1)";resolution:=optional, >>> + javax.portlet;version="[1.0.0, >>> 2.1)";resolution:=optional, >>> + javax.servlet;version="[2.5.0, 3.1)", >>> + javax.servlet.http;version="[2.5.0, 3.1)", >>> + javax.servlet.jsp;version="[2.1.0, 3.1)", >>> javax.servlet.jsp.jstl.core;version="[1.1.2, >>> 2.0.0)", >>> - javax.servlet.jsp.tagext;version="[2.1.0, 3.0.0)", >>> + javax.servlet.jsp.tagext;version="[2.1.0, 3.1)", >>> javax.xml.parsers, >>> org.apache;resolution:=optional, >>> org.apache.commons.beanutils;version="[1.7.0, >>> 2.0.0)", >>> Index: api/pom.xml >>> =================================================================== >>> --- api/pom.xml (revision 892639) >>> +++ api/pom.xml (working copy) >>> @@ -221,12 +221,12 @@ >>> </Export-Package> >>> <Import-Package> >>> javax.el;version="[1.0.0, 3.0.0)", >>> - javax.servlet;version="[2.5.0, 3.0.0)", >>> - javax.servlet.http;version="[2.5.0, 3.0.0)", >>> - javax.servlet.jsp;version="[2.1.0, 3.0.0)", >>> + javax.servlet;version="[2.5.0, 3.1)", >>> + javax.servlet.http;version="[2.5.0, 3.1)", >>> + javax.servlet.jsp;version="[2.1.0, 3.1)", >>> javax.servlet.jsp.jstl.core;version="[1.1.2, >>> 2.0.0)", >>> javax.servlet.jsp.jstl.sql;version="[1.1.2, >>> 2.0.0)", >>> - javax.servlet.jsp.tagext;version="[2.1.0, 3.0.0)", >>> + javax.servlet.jsp.tagext;version="[2.1.0, 3.1)", >>> org.apache.commons.logging;version="[1.1.1, >>> 2.0.0)", >>> javax.faces.*;version="${project.version}" >>> </Import-Package> >>> I think it's fairly clear that this does not change the maven >>> dependencies >>> or what myfaces is building against. All it does is allow myfaces >>> to be >>> used in an osgi environment with a servlet 3 spec jar. That is >>> currently >>> not possible. This is blocking geronimo-myfaces 2 integration. I >>> can't >>> imagine any scenario that currently works that this proposed change >>> would >>> affect, all it does is allow myfaces to be used in more >>> environments. If >>> you think this change will prevent a currently working scenario >>> from working >>> please explain what it is and how. >> >> >> I think I am totally fine on the <Import-Package> changes. >> Let me give your patch a try. >> >> David, thanks for bugging you on that, again. >> >> -Matthias >> >>> thanks >>> david jencks >>> >>> >>> Scott >>> >>> David Jencks wrote: >>> >>> Matthias, >>> I'm not sure you understand what Ivan is requesting. The osgi >>> package >>> version metadata does not specify what jar myfaces is built >>> against, but >>> does restrict which package versions myfaces can be used with in an >>> osgi >>> environment. While the osgi package version metadata is not part >>> of javaee >>> specs, there seems to be general agreement that the spec version >>> should be >>> used as the package version for api jars. So, in order for myfaces >>> to be >>> used in a javee 6 environment, it needs to allow wiring to a >>> servlet 3.0 >>> spec jar. That doesn't mean that you need to build myfaces against a >>> servlet 3 jar, nor does it prevent myfaces from working with >>> servlet 2.5 >>> spec jars in, say, a javaee 5 environment. >>> I'd appreciate it if someone could update trunk for this so we can >>> continue >>> with integrating myfaces 2 in geronimo. I've attached a suitable >>> patch to >>> MYFACES-2290 as >>> https://issues.apache.org/jira/secure/attachment/12428613/allow-ee6-versioned-apis.diff >>> With this patch we can at least start a server that has loaded >>> myfaces 2. >>> Hopefully soon we'll be able to run the ee6 version of the tck. >>> many thanks >>> david jencks >>> On Nov 26, 2009, at 6:23 AM, Matthias Wessendorf wrote: >>> >>> Ivan, >>> >>> we can't use servlet 3.0.0 yet. Not yet final ... >>> and jsf 2.0 has _no_ dependency to it... >>> >>> -Matthias >>> >>> On Thu, Nov 26, 2009 at 3:17 PM, Ivan <[email protected]> wrote: >>> >>> Hi, is it possible to update the accepted servlet spec version to >>> 3.0.0 in >>> >>> the configurations of maven-bundle-plugin? >>> >>> Thanks ! >>> >>> 2009/11/26 Werner Punz <[email protected]> >>> >>> +1 >>> >>> Leonardo Uribe schrieb: >>> >>> Hi, >>> >>> I was running the needed tasks to get the 2.0.0-alpha release of >>> Apache >>> >>> MyFaces core out. >>> >>> Please note that this vote concerns all of the following parts: >>> >>> 1. Maven artifact group "org.apache.myfaces.shared" v4.0.1-alpha >>> [1] >>> >>> 2. Maven artifact group "org.apache.myfaces.test" v1.0.0-alpha [1] >>> >>> 3. Maven artifact group "org.apache.myfaces.core" v2.0.0-alpha [1] >>> >>> The artifacts are deployed to my private Apache account ([1] and [3] >>> >>> for binary and source packages). >>> >>> The release notes could be found at [4]. >>> >>> Also the clirr test does not show binary incompatibilities with >>> >>> myfaces-api. >>> >>> Please take a look at the "2.0.0-alpha" artifacts and vote! >>> >>> Please note: This vote is "majority approval" with a minimum of three >>> >>> +1 votes (see [3]). >>> >>> ------------------------------------------------ >>> >>> [ ] +1 for community members who have reviewed the bits >>> >>> [ ] +0 >>> >>> [ ] -1 for fatal flaws that should cause these bits not to be >>> released, >>> >>> and why.............. >>> >>> ------------------------------------------------ >>> >>> Thanks, >>> >>> Leonardo Uribe >>> >>> [1] http://people.apache.org/~lu4242/myfaces200alpha >>> >>> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes >>> >>> [3] http://people.apache.org/~lu4242/myfaces200alphabinsrc >>> >>> [4] >>> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&styleName=Html&version=12313389 >>> >>> >>> >>> >>> >>> -- >>> >>> Ivan >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
