Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 14053 invoked from network); 8 Nov 2010 22:15:11 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 8 Nov 2010 22:15:11 -0000 Received: (qmail 94163 invoked by uid 500); 8 Nov 2010 22:15:42 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 94059 invoked by uid 500); 8 Nov 2010 22:15:42 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 94052 invoked by uid 99); 8 Nov 2010 22:15:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Nov 2010 22:15:42 +0000 X-ASF-Spam-Status: No, hits=4.4 required=10.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lu4242@gmail.com designates 209.85.215.53 as permitted sender) Received: from [209.85.215.53] (HELO mail-ew0-f53.google.com) (209.85.215.53) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Nov 2010 22:15:38 +0000 Received: by ewy10 with SMTP id 10so3380500ewy.12 for ; Mon, 08 Nov 2010 14:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=xu/NCy+7X87YCUU5Lngb4KKpXaRERJTHOucyGb/lcQA=; b=qWsc+90xhFKUxPlAlkjCAtsku25OWCRTZz7UlZnv3bBfIAUZO31+DrefELiduXgnv7 ZQcoh4tALkQy5PaMWGnNhwmRdZ50a3fGplJjVdUkIxsjzj24WRJEJWUVXy0fxM3H0WN7 jHUquI58iPO6ArnhLC6tHZTQH7voPZPL54Kis= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=lcu+TSNIWQr4WKK+MilQnhwzpuTj/Kvjzo8omo9A9wWif3H6eP+ub5CRMiq0TlK8hl r1IFb3pDk1lBLgH9iSnlUs002Nll0shGjP/LGHLBVLgqsuPWu4OPeI1E5/G1IbKuv5RO 5n2POUZFtNE3YZVzBc0pIttlUlg4QWlipcJ0M= MIME-Version: 1.0 Received: by 10.216.243.195 with SMTP id k45mr706079wer.3.1289254515710; Mon, 08 Nov 2010 14:15:15 -0800 (PST) Received: by 10.216.186.67 with HTTP; Mon, 8 Nov 2010 14:15:15 -0800 (PST) In-Reply-To: References: <2682374A-016C-4A65-B2EF-280BA38FB91D@gmail.com> Date: Mon, 8 Nov 2010 17:15:15 -0500 Message-ID: Subject: Re: Use maven-shade-plugin to prevent duplicate code From: Leonardo Uribe To: MyFaces Development Content-Type: multipart/alternative; boundary=e0cb4e43ce696f1deb049491f5f8 --e0cb4e43ce696f1deb049491f5f8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi No, I understand well, but maybe we are talking about many possible enhancements at the same time. I know how shade plugin works, after all, I did the necessary changes to us= e it on implee6. That's the reason why I know well the problems involved. I tried to use it in myfaces-test but the conclusion was myfaces builder plugin unpack goal is better in that specific context. I also tried to do the same with shared, but again I found all previous problems. The code you have on the branch is similar to the attempt I did, but I investigated much more about it. I'll do a brief resume of the discussion. In that way we'll be sure we are taking of the same thing. Q: What do we want to do? The central point is how to refactor or change the way shared works, so we don't need to to a full build each time a change is done. Q: Which are the problems when using maven shade plugin? 1. Source jar file is not updated, so IDEs will have problems with it. 2. Maven shade plugin does not play well with bundle plugin. 3. Some shared_impl classes are public, so we can't change its package name= . without break backwards compatibility. Q: Could shared be a submodule on myfaces core project instead a separate project? Only if we can release shared in a independent way. In my opinion it is better let it as is. Q: Mojarra will provide an artifact with api and impl bundle together, coul= d we do the same? Yes, but for that artifact we need to generate a new manifest.mf file. By problem 2, the only option is use unpack goal. Configure that one will be tricky. I'll create a submodule for this one. Q: So, what alternative do we have at this point? 1. Keep public shared classes with package shared_impl. Maybe the only one is DelegateServlet. 2. Refactor impl module to use "org.apache.myfaces.shared" instead "org.apache.myfaces.shared_impl". 3. Use shade plugin and ignore the problem 2 (we can do it since those packages will not be exported). 4. Check manifest.mf and source jar to see if everything is ok. 5. Leave shared project as is. We don't need to do any changes there. That's what I'm thinking. Does that sounds good? Do you see any incongruenc= e or misunderstanding? It that so, just let me know. Suggestions are welcome. regards, Leonardo Uribe 2010/11/8 Jakob Korherr > Hi > > Leo, you are getting this all wrong. Please take a look at the > shade-branch, which I created, and then we can continue this > discussion. > > Thanks. > > Regards, > Jakob > > 2010/11/8 Leonardo Uribe : > > Hi > > > > 2010/11/8 Gerhard > >> > >> hi, > >> i didn't talk about copying the code to the impl. module. it would be = a > >> normal module (similar to the shared module) which gets shadded into t= he > >> impl. module. > >> actually both approaches are very similar. so you have the same > advantages > >> (compared to the shared module) and it's easier to handle during the > >> development process. > > > > Ok, but if that so, the advantage of the current configuration is we ca= n > > release > > shared code without release myfaces core. If we put shared code as a > > submodule > > of myfaces core and we need to release tomahawk or orchestra or other > > project > > that uses shared code we'll need to release core first. > > > > regards, > > > > Leonardo Uribe > > > >> > >> regards, > >> gerhard > >> > >> http://www.irian.at > >> > >> Your JSF powerhouse - > >> JSF Consulting, Development and > >> Courses in English and German > >> > >> Professional Support for Apache MyFaces > >> > >> > >> > >> 2010/11/8 Leonardo Uribe > >>> > >>> Hi > >>> > >>> 2010/11/8 Gerhard > >>>> > >>>> again - i agree with jakob! > >>>> such an >additional< all-in-one dist won't change the situation for > osgi > >>>> users. (for now) they just have to stick with the current jar files. > >>>> @shared: > >>>> the classes of the shared module would be in the impl. module, if we > >>>> don=92t (have to) share them with other myfaces sub-projects. > >>> > >>> The advantage of have shared in a separate module is we ensure all > shared > >>> code only depends > >>> of jsf api. If we put that code inside myfaces impl, we have the risk > of > >>> mix code and then > >>> well see ClassNotFoundException or things like that when libraries li= ke > >>> tomahawk or > >>> in the future portlet bridge are used with mojarra. > >>> > >>> regards, > >>> > >>> Leonardo Uribe > >>> > >>>> > >>>> > >>>> > >>>> regards, > >>>> gerhard > >>>> > >>>> http://www.irian.at > >>>> > >>>> Your JSF powerhouse - > >>>> JSF Consulting, Development and > >>>> Courses in English and German > >>>> > >>>> Professional Support for Apache MyFaces > >>>> > >>>> > >>>> > >>>> 2010/11/8 Jakob Korherr > >>>>> > >>>>> Hi, > >>>>> > >>>>> IMHO shared code ist just as private as myfaces-impl code. Not more= , > >>>>> not less. > >>>>> > >>>>> Adding the all-in-one-jar is not a change, but an improvement. It i= s > >>>>> just an additional (non-OSGi-ready) distribution form of MyFaces co= de > >>>>> and thus does not affect the problems we're having with > myfaces-shared > >>>>> and OSGi. > >>>>> > >>>>> Regards, > >>>>> Jakob > >>>>> > >>>>> 2010/11/8 Leonardo Uribe : > >>>>> > Hi > >>>>> > > >>>>> > 2010/11/8 Jakob Korherr > >>>>> >> > >>>>> >> Hi, > >>>>> >> > >>>>> >> Last week I created a branch (see [1]) to test the shade module > >>>>> >> integration of shared and also implee6 for MyFaces core. > >>>>> >> Coincidentally, Leonardo committed a similar solution to MyFaces > >>>>> >> core > >>>>> >> trunk, however only for the implee6 integration. > >>>>> >> > >>>>> >> The branch at [1] uses the shade plugin to include shared and > >>>>> >> implee6. > >>>>> >> For shared it uses a dependency to myfaces-shared-core (NOT > >>>>> >> shared-impl), which will then be shaded to org.apache.myfaces.* > >>>>> >> (without the shared-package) - however this is only a prototype. > To > >>>>> >> make this work I had to rename all imports in myfaces-impl from > >>>>> >> "shared_impl" to "shared". Everything works pretty well expect f= or > >>>>> >> the > >>>>> >> OSGi-issues mentioned by Leonardo. > >>>>> >> > >>>>> >> Using this branch you are able to work on MyFaces shared classes > in > >>>>> >> the context of MyFaces core and not having to do a whole maven > build > >>>>> >> when testing it, because your IDE uses shared directly as a > >>>>> >> dependency. Thus it really is an improvement to what we have now > and > >>>>> >> we should try to fix the OSGi issues in some way to really make > this > >>>>> >> work. I already did some work in this direction and I think that= a > >>>>> >> ResourceTransformer implementation for shade that creates the > >>>>> >> Manifest > >>>>> >> file for OSGi is the way to go, but we certainly have to discuss > >>>>> >> this > >>>>> >> (maybe also with the bundle-plugin team). WDYT Leo? > >>>>> >> > >>>>> > > >>>>> > Well, before try to do something like that (a ResourceTransformer > >>>>> > implementation) > >>>>> > it is good to ask if it is really necessary to do that. On a > previous > >>>>> > mail I > >>>>> > said that > >>>>> > "shared" code should be private, so there should not be used for > >>>>> > users > >>>>> > outside > >>>>> > myfaces impl. There are exceptions (DelegateServlet), so we have = to > >>>>> > identify > >>>>> > first > >>>>> > which code could not be relocated. The effect on maven bundle > plugin > >>>>> > is > >>>>> > shared packages are excluded from Export-Package header, but as > long > >>>>> > as > >>>>> > users > >>>>> > don't have code importing shared_impl package it is ok to ignore > this > >>>>> > side > >>>>> > effect. > >>>>> > > >>>>> >> > >>>>> >> However, please take a look at the branch at [1] and try to use = it > >>>>> >> in > >>>>> >> your IDE - I think it's really great! (... and furthermore I thi= nk > >>>>> >> it's much easier to understand for every myfaces-developer). > >>>>> >> > >>>>> >> > >>>>> >> I also totally agree with Gerhard that we should provide this > >>>>> >> all-in-one jar, even if it may cause problems in OSGi, because o= ur > >>>>> >> OSGi users will most certainly know that. It's really easy to do > >>>>> >> this > >>>>> >> using the shade plugin and it provides a very convenient way for > >>>>> >> developers to use MyFaces (especially when they're not using > maven). > >>>>> >> As Gerhard mentioned, Mojarra will do the same and furthermore > other > >>>>> >> projects like e.g. Weld also provide this all-in-one solution (-= -> > >>>>> >> weld-servlet). > >>>>> >> > >>>>> > > >>>>> > I disagree. Our first priority should be myfaces usage in differe= nt > >>>>> > environments, > >>>>> > and then enhance IDE support. Only if the two previous objections > can > >>>>> > be > >>>>> > solved, > >>>>> > the change can be made. > >>>>> > > >>>>> > regards, > >>>>> > > >>>>> > Leonardo Uribe > >>>>> > > >>>>> >> > >>>>> >> Regards, > >>>>> >> Jakob > >>>>> >> > >>>>> >> [1] > >>>>> >> > >>>>> >> > http://svn.apache.org/repos/asf/myfaces/core/branches/2_0_3_snapshot_shad= e_test/ > >>>>> >> > >>>>> >> 2010/11/8 Leonardo Uribe : > >>>>> >> > Hi > >>>>> >> > > >>>>> >> > 2010/11/8 Gerhard > >>>>> >> >> > >>>>> >> >> hi, > >>>>> >> >> @ide-support: > >>>>> >> >> since you get an additional all-in-one sources jar file, it > >>>>> >> >> should > >>>>> >> >> work. > >>>>> >> >> i've created external codi examples which use the all-in-one > jar > >>>>> >> >> of > >>>>> >> >> codi > >>>>> >> >> and the ide support works perfectly. > >>>>> >> > > >>>>> >> > Yes, that's true (I checked that code) but in shared you need = to > >>>>> >> > change > >>>>> >> > the > >>>>> >> > package name to org.apache.myfaces.shared_impl. > >>>>> >> > > >>>>> >> > Really that package renaming is questionable. Why? It exists > since > >>>>> >> > 1.1.x > >>>>> >> > but > >>>>> >> > I don't know why this is necessary. In theory, the code inside > >>>>> >> > shared > >>>>> >> > should > >>>>> >> > be "private", but the truth is we have one class that could be > >>>>> >> > consumed > >>>>> >> > by > >>>>> >> > users: > >>>>> >> > > >>>>> >> > > org.apache.myfaces.shared_impl.webapp.webxml.DelegatedFacesServlet. > >>>>> >> > That is the main reason why I moved the code proposed on > >>>>> >> > https://issues.apache.org/jira/browse/MYFACES-2944 to > myfaces-impl > >>>>> >> > package. > >>>>> >> > > >>>>> >> >> > >>>>> >> >> @osgi: > >>>>> >> >> if there are restrictions, we should improve the shade plugin= . > >>>>> >> >> (for now: osgi users just can't use this optional all-in-one > jar > >>>>> >> >> file - > >>>>> >> >> if > >>>>> >> >> we document it, it shouldn't be a problem.) > >>>>> >> > > >>>>> >> > There is a discussion of this issue here: > >>>>> >> > > >>>>> >> > https://issues.apache.org/jira/browse/FELIX-1184 > >>>>> >> > > >>>>> >> > It was reported here too: > >>>>> >> > > >>>>> >> > http://jira.codehaus.org/browse/MSHADE-51 > >>>>> >> > > >>>>> >> > The issue in maven is here: > >>>>> >> > > >>>>> >> > http://jira.codehaus.org/browse/MNG-2258 > >>>>> >> > > >>>>> >> > Unfortunately, the only hack I can see to make this work > correctly > >>>>> >> > is > >>>>> >> > create > >>>>> >> > a plugin with a maven lifecycle extension, and do that is very > >>>>> >> > nasty, > >>>>> >> > because we need to create a plugin just to do that. > >>>>> >> > > >>>>> >> >> > >>>>> >> >> @use-case: > >>>>> >> >> we should really get rid of the shared module. > >>>>> >> > > >>>>> >> > I agree. First we need a more explicit plan to do it. > Suggestions > >>>>> >> > are > >>>>> >> > welcome. > >>>>> >> > > >>>>> >> > regards, > >>>>> >> > > >>>>> >> > Leonardo Uribe > >>>>> >> > > >>>>> >> >> > >>>>> >> >> regards, > >>>>> >> >> gerhard > >>>>> >> >> http://www.irian.at > >>>>> >> >> > >>>>> >> >> Your JSF powerhouse - > >>>>> >> >> JSF Consulting, Development and > >>>>> >> >> Courses in English and German > >>>>> >> >> > >>>>> >> >> Professional Support for Apache MyFaces > >>>>> >> >> > >>>>> >> >> > >>>>> >> >> > >>>>> >> >> 2010/11/8 Leonardo Uribe > >>>>> >> >>> > >>>>> >> >>> Hi > >>>>> >> >>> > >>>>> >> >>> Unfortunately, maven-shade-plugin has some unwanted side > >>>>> >> >>> effects. > >>>>> >> >>> > >>>>> >> >>> - The source jar file is not updated too, so if we "shade" > >>>>> >> >>> shared, the > >>>>> >> >>> sources are not updated. In theory, the source jar is used b= y > >>>>> >> >>> IDEs > >>>>> >> >>> like > >>>>> >> >>> Eclipse or Netbeans to show the source file of a .class. > >>>>> >> >>> - It does not play well with osgi bundle plugin (the one tha= t > >>>>> >> >>> create > >>>>> >> >>> manifest.mf). The problem is the manifest is generated befor= e > >>>>> >> >>> "shade", > >>>>> >> >>> and > >>>>> >> >>> we need the later. Really that one is a problem related to > maven > >>>>> >> >>> itself. > >>>>> >> >>> > >>>>> >> >>> The only valid use case I found where maven-shade-plugin fit= s > >>>>> >> >>> well is > >>>>> >> >>> with implee6 module, but anyway it was required to do some > hacks > >>>>> >> >>> to > >>>>> >> >>> make > >>>>> >> >>> bundle plugin works well. > >>>>> >> >>> > >>>>> >> >>> regards, > >>>>> >> >>> > >>>>> >> >>> Leonardo Uribe > >>>>> >> >> > >>>>> >> > > >>>>> >> > > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> -- > >>>>> >> Jakob Korherr > >>>>> >> > >>>>> >> blog: http://www.jakobk.com > >>>>> >> twitter: http://twitter.com/jakobkorherr > >>>>> >> work: http://www.irian.at > >>>>> > > >>>>> > > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Jakob Korherr > >>>>> > >>>>> blog: http://www.jakobk.com > >>>>> twitter: http://twitter.com/jakobkorherr > >>>>> work: http://www.irian.at > >>>> > >>> > >> > > > > > > > > -- > Jakob Korherr > > blog: http://www.jakobk.com > twitter: http://twitter.com/jakobkorherr > work: http://www.irian.at > --e0cb4e43ce696f1deb049491f5f8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi

No, I understand well, but maybe we are talking about many possib= le
enhancements at the same time.

I know how shade plugin works,= after all, I did the necessary changes to use
it on implee6. That's= the reason why I know well the problems involved. I tried
to use it in myfaces-test but the conclusion was myfaces builder plugin unp= ack
goal is better in that specific context. I also tried to do the same= with shared,
but again I found all previous problems. The code you have= on the branch is
similar to the attempt I did, but I investigated much more about it.
I'll do a brief resume of the discussion. In that way we'll be sur= e we are taking
of the same thing.

Q: What do we want to do?

The central point is how to refactor or change the way shared works, so= we don't
need to to a full build each time a change is done.
Q: Which are the problems when using maven shade plugin?

1. Source = jar file is not updated, so IDEs will have problems with it.
2. Maven shade plugin does not play well with bundle plugin.
3. Some sha= red_impl classes are public, so we can't change its package name.
= =A0=A0=A0 without break backwards compatibility.

Q: Could shared be = a submodule on myfaces core project instead a separate project?

Only if we can release shared in a independent way. In my opinion it is= better let it
as is.

Q: Mojarra will provide an artifact with ap= i and impl bundle together, could we do the same?

Yes, but for that = artifact we need to generate a new manifest.mf file. By problem 2, the only= option
is use unpack goal. Configure that one will be tricky. I'll create a su= bmodule for this one.

Q: So, what alternative do we have at this po= int?

1. Keep public shared classes with package shared_impl. Maybe t= he only one is DelegateServlet.
2. Refactor impl module to use "org.apache.myfaces.shared" instea= d "org.apache.myfaces.shared_impl".
3. Use shade plugin and ig= nore the problem 2 (we can do it since those packages will not be exported)= .
4. Check manifest.mf and source jar to see if everything is ok.
5. Leave= shared project as is. We don't need to do any changes there.

Th= at's what I'm thinking. Does that sounds good? Do you see any incon= gruence or
misunderstanding? It that so, just let me know.

Suggestions are welc= ome.

regards,

Leonardo Uribe

2010/11/8 Jakob Korherr <jakob.korherr@gmail.com>
Hi

Leo, you are getting this all wrong. Please take a look at the
shade-branch, which I created, and then we can continue this
discussion.

Thanks.

Regards,
Jakob

2010/11/8 Leonardo Uribe <lu4242@gma= il.com>:
> Hi
>
> 2010/11/8 Gerhard <ge= rhard.petracek@gmail.com>
>>
>> hi,
>> i didn't talk about copying the code to the impl. module. it w= ould be a
>> normal module (similar to the shared module) which gets shadded in= to the
>> impl. module.
>> actually both approaches are very similar. so you have the same ad= vantages
>> (compared to the shared module) and it's easier to handle duri= ng the
>> development process.
>
> Ok, but if that so, the advantage of the current configuration is we c= an
> release
> shared code without release myfaces core. If we put shared code as a > submodule
> of myfaces core and we need to release tomahawk or orchestra or other<= br> > project
> that uses shared code we'll need to release core first.
>
> regards,
>
> Leonardo Uribe
>
>>
>> regards,
>> gerhard
>>
>> http://www.irian= .at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>>
>>
>> 2010/11/8 Leonardo Uribe <l= u4242@gmail.com>
>>>
>>> Hi
>>>
>>> 2010/11/8 Gerhard <gerhard.petracek@gmail.com>
>>>>
>>>> again - i agree with jakob!
>>>> such an >additional< all-in-one dist won't chang= e the situation for osgi
>>>> users. (for now) they just have to stick with the current = jar files.
>>>> @shared:
>>>> the classes of the shared module would be in the impl. mod= ule, if we
>>>> don=92t (have to) share them with other myfaces sub-projec= ts.
>>>
>>> The advantage of have shared in a separate module is we ensure= all shared
>>> code only depends
>>> of jsf api. If we put that code inside myfaces impl, we have t= he risk of
>>> mix code and then
>>> well see ClassNotFoundException or things like that when libra= ries like
>>> tomahawk or
>>> in the future portlet bridge are used with mojarra.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>>
>>>>
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>> http://w= ww.irian.at
>>>>
>>>> Your JSF powerhouse -
>>>> JSF Consulting, Development and
>>>> Courses in English and German
>>>>
>>>> Professional Support for Apache MyFaces
>>>>
>>>>
>>>>
>>>> 2010/11/8 Jakob Korherr <jakob.korherr@gmail.com>
>>>>>
>>>>> Hi,
>>>>>
>>>>> IMHO shared code ist just as private as myfaces-impl c= ode. Not more,
>>>>> not less.
>>>>>
>>>>> Adding the all-in-one-jar is not a change, but an impr= ovement. It is
>>>>> just an additional (non-OSGi-ready) distribution form = of MyFaces code
>>>>> and thus does not affect the problems we're having= with myfaces-shared
>>>>> and OSGi.
>>>>>
>>>>> Regards,
>>>>> Jakob
>>>>>
>>>>> 2010/11/8 Leonardo Uribe <lu4242@gmail.com>:
>>>>> > Hi
>>>>> >
>>>>> > 2010/11/8 Jakob Korherr <jakob.korherr@gmail.com>
>>>>> >>
>>>>> >> Hi,
>>>>> >>
>>>>> >> Last week I created a branch (see [1]) to tes= t the shade module
>>>>> >> integration of shared and also implee6 for My= Faces core.
>>>>> >> Coincidentally, Leonardo committed a similar = solution to MyFaces
>>>>> >> core
>>>>> >> trunk, however only for the implee6 integrati= on.
>>>>> >>
>>>>> >> The branch at [1] uses the shade plugin to in= clude shared and
>>>>> >> implee6.
>>>>> >> For shared it uses a dependency to myfaces-sh= ared-core (NOT
>>>>> >> shared-impl), which will then be shaded to or= g.apache.myfaces.*
>>>>> >> (without the shared-package) - however this i= s only a prototype. To
>>>>> >> make this work I had to rename all imports in= myfaces-impl from
>>>>> >> "shared_impl" to "shared"= . Everything works pretty well expect for
>>>>> >> the
>>>>> >> OSGi-issues mentioned by Leonardo.
>>>>> >>
>>>>> >> Using this branch you are able to work on MyF= aces shared classes in
>>>>> >> the context of MyFaces core and not having to= do a whole maven build
>>>>> >> when testing it, because your IDE uses shared= directly as a
>>>>> >> dependency. Thus it really is an improvement = to what we have now and
>>>>> >> we should try to fix the OSGi issues in some = way to really make this
>>>>> >> work. I already did some work in this directi= on and I think that a
>>>>> >> ResourceTransformer implementation for shade = that creates the
>>>>> >> Manifest
>>>>> >> file for OSGi is the way to go, but we certai= nly have to discuss
>>>>> >> this
>>>>> >> (maybe also with the bundle-plugin team). WDY= T Leo?
>>>>> >>
>>>>> >
>>>>> > Well, before try to do something like that (a Res= ourceTransformer
>>>>> > implementation)
>>>>> > it is good to ask if it is really necessary to do= that. On a previous
>>>>> > mail I
>>>>> > said that
>>>>> > "shared" code should be private, so the= re should not be used for
>>>>> > users
>>>>> > outside
>>>>> > myfaces impl. There are exceptions (DelegateServl= et), so we have to
>>>>> > identify
>>>>> > first
>>>>> > which code could not be relocated. The effect on = maven bundle plugin
>>>>> > is
>>>>> > shared packages are excluded from Export-Package = header, but as long
>>>>> > as
>>>>> > users
>>>>> > don't have code importing shared_impl package= it is ok to ignore this
>>>>> > side
>>>>> > effect.
>>>>> >
>>>>> >>
>>>>> >> However, please take a look at the branch at = [1]=A0and try to use it
>>>>> >> in
>>>>> >> your IDE - I think it's really great! (..= . and furthermore I think
>>>>> >> it's much easier to understand for every = myfaces-developer).
>>>>> >>
>>>>> >>
>>>>> >> I also totally agree with Gerhard that we sho= uld provide this
>>>>> >> all-in-one jar, even if it may cause problems= in OSGi, because our
>>>>> >> OSGi users will most certainly know that. It&= #39;s really easy to do
>>>>> >> this
>>>>> >> using the shade plugin and it provides a very= convenient way for
>>>>> >> developers to use MyFaces (especially when th= ey're not using maven).
>>>>> >> As Gerhard mentioned, Mojarra will do the sam= e and furthermore other
>>>>> >> projects like e.g. Weld also provide this all= -in-one solution (-->
>>>>> >> weld-servlet).
>>>>> >>
>>>>> >
>>>>> > I disagree. Our first priority should be myfaces = usage in different
>>>>> > environments,
>>>>> > and then enhance IDE support. Only if the two pre= vious objections can
>>>>> > be
>>>>> > solved,
>>>>> > the change can be made.
>>>>> >
>>>>> > regards,
>>>>> >
>>>>> > Leonardo Uribe
>>>>> >
>>>>> >>
>>>>> >> Regards,
>>>>> >> Jakob
>>>>> >>
>>>>> >> [1]
>>>>> >>
>>>>> >> http://sv= n.apache.org/repos/asf/myfaces/core/branches/2_0_3_snapshot_shade_test/=
>>>>> >>
>>>>> >> 2010/11/8 Leonardo Uribe <lu4242@gmail.com>:
>>>>> >> > Hi
>>>>> >> >
>>>>> >> > 2010/11/8 Gerhard <gerhard.petracek@gmail.com>
>>>>> >> >>
>>>>> >> >> hi,
>>>>> >> >> @ide-support:
>>>>> >> >> since you get an additional all-in-o= ne sources jar file, it
>>>>> >> >> should
>>>>> >> >> work.
>>>>> >> >> i've created external codi examp= les which use the all-in-one jar
>>>>> >> >> of
>>>>> >> >> codi
>>>>> >> >> and the ide support works perfectly.=
>>>>> >> >
>>>>> >> > Yes, that's true (I checked that cod= e) but in shared you need to
>>>>> >> > change
>>>>> >> > the
>>>>> >> > package name to org.apache.myfaces.share= d_impl.
>>>>> >> >
>>>>> >> > Really that package renaming is question= able. Why? It exists since
>>>>> >> > 1.1.x
>>>>> >> > but
>>>>> >> > I don't know why this is necessary. = In theory, the code inside
>>>>> >> > shared
>>>>> >> > should
>>>>> >> > be "private", but the truth is= we have one class that could be
>>>>> >> > consumed
>>>>> >> > by
>>>>> >> > users:
>>>>> >> >
>>>>> >> > org.apache.myfaces.shared_impl.webapp.we= bxml.DelegatedFacesServlet.
>>>>> >> > That is the main reason why I moved the = code proposed on
>>>>> >> > https://issues.apache.org/jira/bro= wse/MYFACES-2944 to myfaces-impl
>>>>> >> > package.
>>>>> >> >
>>>>> >> >>
>>>>> >> >> @osgi:
>>>>> >> >> if there are restrictions, we should= improve the shade plugin.
>>>>> >> >> (for now: osgi users just can't = use this optional all-in-one jar
>>>>> >> >> file -
>>>>> >> >> if
>>>>> >> >> we document it, it shouldn't be = a problem.)
>>>>> >> >
>>>>> >> > There is a discussion of this issue here= :
>>>>> >> >
>>>>> >> > https://issues.apache.org/jira/brows= e/FELIX-1184
>>>>> >> >
>>>>> >> > It was reported here too:
>>>>> >> >
>>>>> >> > http://jira.codehaus.org/browse/MSHADE-51
>>>>> >> >
>>>>> >> > The issue in maven is here:
>>>>> >> >
>>>>> >> > http://jira.codehaus.org/browse/MNG-2258=
>>>>> >> >
>>>>> >> > Unfortunately, the only hack I can see t= o make this work correctly
>>>>> >> > is
>>>>> >> > create
>>>>> >> > a plugin with a maven lifecycle extensio= n, and do that is very
>>>>> >> > nasty,
>>>>> >> > because we need to create a plugin just = to do that.
>>>>> >> >
>>>>> >> >>
>>>>> >> >> @use-case:
>>>>> >> >> we should really get rid of the shar= ed module.
>>>>> >> >
>>>>> >> > I agree. First we need a more explicit p= lan to do it. Suggestions
>>>>> >> > are
>>>>> >> > welcome.
>>>>> >> >
>>>>> >> > regards,
>>>>> >> >
>>>>> >> > Leonardo Uribe
>>>>> >> >
>>>>> >> >>
>>>>> >> >> regards,
>>>>> >> >> gerhard
>>>>> >> >> http://www.irian.at
>>>>> >> >>
>>>>> >> >> Your JSF powerhouse -
>>>>> >> >> JSF Consulting, Development and
>>>>> >> >> Courses in English and German
>>>>> >> >>
>>>>> >> >> Professional Support for Apache MyFa= ces
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> 2010/11/8 Leonardo Uribe <lu4242@gmail.com>
>>>>> >> >>>
>>>>> >> >>> Hi
>>>>> >> >>>
>>>>> >> >>> Unfortunately, maven-shade-plugi= n has some unwanted side
>>>>> >> >>> effects.
>>>>> >> >>>
>>>>> >> >>> - The source jar file is not upd= ated too, so if we "shade"
>>>>> >> >>> shared, the
>>>>> >> >>> sources are not updated. In theo= ry, the source jar is used by
>>>>> >> >>> IDEs
>>>>> >> >>> like
>>>>> >> >>> Eclipse or Netbeans to show the = source file of a .class.
>>>>> >> >>> - It does not play well with osg= i bundle plugin (the one that
>>>>> >> >>> create
>>>>> >> >>> manifest.mf). The problem is the= manifest is generated before
>>>>> >> >>> "shade",
>>>>> >> >>> and
>>>>> >> >>> we need the later. Really that o= ne is a problem related to maven
>>>>> >> >>> itself.
>>>>> >> >>>
>>>>> >> >>> The only valid use case I found = where maven-shade-plugin fits
>>>>> >> >>> well is
>>>>> >> >>> with implee6 module, but anyway = it was required to do some hacks
>>>>> >> >>> to
>>>>> >> >>> make
>>>>> >> >>> bundle plugin works well.
>>>>> >> >>>
>>>>> >> >>> regards,
>>>>> >> >>>
>>>>> >> >>> Leonardo Uribe
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Jakob Korherr
>>>>> >>
>>>>> >> blog: http://www.jakobk.com
>>>>> >> twitter: http://twitter.com/jakobkorherr
>>>>> >> work: http://www.irian.at
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jakob Korherr
>>>>>
>>>>> blog: http://www.jakobk.com
>>>>> twitter: http://twitter.com/jakobkorherr
>>>>> work: http://www.irian.at
>>>>
>>>
>>
>
>



--

--e0cb4e43ce696f1deb049491f5f8--