Hey David,

On Wed, Dec 23, 2009 at 10:32 PM, David Jencks <david_jen...@yahoo.com> 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 <xhh...@gmail.com> 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 <werner.p...@gmail.com>
>
> +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

Reply via email to