Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 81414 invoked from network); 8 Nov 2010 21:05:41 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 8 Nov 2010 21:05:41 -0000 Received: (qmail 4346 invoked by uid 500); 8 Nov 2010 21:06:11 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 4262 invoked by uid 500); 8 Nov 2010 21:06:11 -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 4253 invoked by uid 99); 8 Nov 2010 21:06:10 -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 21:06:10 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gerhard.petracek@gmail.com designates 74.125.82.41 as permitted sender) Received: from [74.125.82.41] (HELO mail-ww0-f41.google.com) (74.125.82.41) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Nov 2010 21:06:06 +0000 Received: by wwb39 with SMTP id 39so397456wwb.0 for ; Mon, 08 Nov 2010 13:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=84LJpNfMHnzp2+YOza7GWkT1SyjkGk/CkOu+hL4e0sU=; b=f59dHyTDd9stbV7RmyFFYZJgPjmvjH7wq5zmxKz8LmS5PHrtWPg0YcRc1aYX/4gMV4 iKzSAAb5YzEI1RWe9PoNSblgAKOdHnOviCtebqJlxQ/ErCoMOzxG+k00Y/84qZNsMjUB 3JYiqf2VRaiY3Ix17rbUJv+syW4YPE/5R2oh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=Iq4v2dAKdYZXgil9ZWXUhe0zQyS/8R54UzcUjG8bi7IOJTzCNica8hO/DhcFzNXBOU khfBCktODaYEXgxAOVKFNX+obmN8s1qxyoZp+2MXxjEudE6ehBHyA+dXq9B7AJg1tcZ1 WJXbeCxyFnDLwGrvcyriNRufMfkuWq+DE4oAU= Received: by 10.227.163.7 with SMTP id y7mr5869744wbx.35.1289250343600; Mon, 08 Nov 2010 13:05:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.147.83 with HTTP; Mon, 8 Nov 2010 13:05:23 -0800 (PST) In-Reply-To: References: <2682374A-016C-4A65-B2EF-280BA38FB91D@gmail.com> From: Gerhard Date: Mon, 8 Nov 2010 22:05:23 +0100 Message-ID: Subject: Re: Use maven-shade-plugin to prevent duplicate code To: MyFaces Development Content-Type: multipart/alternative; boundary=00248c0d766cc1c20a049490fc60 --00248c0d766cc1c20a049490fc60 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 the 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. 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 like > 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, no= t >>> less. >>> >>> Adding the all-in-one-jar is not a change, but an improvement. 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 : >>> > 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 cor= e >>> >> trunk, however only for the implee6 integration. >>> >> >>> >> The branch at [1] uses the shade plugin to include shared and implee= 6. >>> >> 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 for t= he >>> >> 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 Manife= st >>> >> file for OSGi is the way to go, but we certainly have to discuss thi= s >>> >> (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 user= s >>> > 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 i= n >>> >> 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 should provide this >>> >> all-in-one jar, even if it may cause problems in OSGi, because our >>> >> OSGi users will most certainly know that. It's really easy to do thi= s >>> >> 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 different >>> > 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_sh= ade_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 shoul= d >>> >> >> 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" share= d, >>> the >>> >> >>> sources are not updated. In theory, the source jar is used by ID= Es >>> >> >>> like >>> >> >>> Eclipse or Netbeans to show the source file of a .class. >>> >> >>> - It does not play well with osgi bundle plugin (the one that >>> create >>> >> >>> manifest.mf). The problem is the manifest is generated before >>> "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 fits we= ll >>> 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 >>> >> >> > --00248c0d766cc1c20a049490fc60 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
hi,

i didn't talk about copying the code to th= e impl. module. it would be a normal module (similar to the shared module) = which gets shadded into the impl. module.
actually both approaches are = very similar. so you have the same advantages (compared to the shared modul= e) and it's easier to handle during the development process.

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 = <lu4242@gmail.com<= /a>>
Hi

2010/11/8 Gerhard <gerhard.petracek@gmail.com>
again - i agree with jakob!

such = an >additional< all-in-one dist won't change the situation for os= gi users. (for now) they just have to stick with the current jar files.

@shared:
the classes of the shared module would be in the im= pl. module, if we don=92t (have to) share them with other myfaces sub-proje= cts.


The a= dvantage of have shared in a separate module is we ensure all shared code o= nly depends
of jsf api. If we put that code inside myfaces impl, we have the risk of mi= x code and then
well see ClassNotFoundException or things like that when= libraries like tomahawk or
in the future portlet bridge are used with m= ojarra.

regards,

Leonardo Uribe
=A0
=A0
regards,
gerhard

http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses i= n 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 code. Not more, not le= ss.

Adding the all-in-one-jar is not a change, but an improvement. 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<= br> 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 test the shade module >> integration of shared and also implee6 for MyFaces core.
>> Coincidentally, Leonardo committed a similar solution to MyFaces c= ore
>> trunk, however only for the implee6 integration.
>>
>> The branch at [1] uses the shade plugin to include shared and impl= ee6.
>> 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. T= o
>> make this work I had to rename all imports in myfaces-impl from >> "shared_impl" to "shared". Everything works pr= etty well expect for the
>> OSGi-issues mentioned by Leonardo.
>>
>> Using this branch you are able to work on MyFaces shared classes i= n
>> the context of MyFaces core and not having to do a whole maven bui= ld
>> when testing it, because your IDE uses shared directly as a
>> dependency. Thus it really is an improvement to what we have now a= nd
>> we should try to fix the OSGi issues in some way to really make th= is
>> work. I already did some work in this direction and I think that a=
>> ResourceTransformer implementation for shade that creates the Mani= fest
>> file for OSGi is the way to go, but we certainly have to discuss t= his
>> (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 id= entify
> first
> which code could not be relocated. The effect on maven bundle plugin i= s
> shared packages are excluded from Export-Package header, but as long a= s
> users
> don't have code importing shared_impl package it is ok to ignore t= his 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 t= hink
>> 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 our=
>> 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 m= aven).
>> As Gerhard mentioned, Mojarra will do the same and furthermore oth= er
>> projects like e.g. Weld also provide this all-in-one solution (--&= gt;
>> weld-servlet).
>>
>
> I disagree. Our first priority should be myfaces usage in different > 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/as= f/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-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 i= nside shared
>> > should
>> > be "private", but the truth is we have one class th= at could be consumed
>> > by
>> > users:
>> > org.apache.myfaces.shared_impl.webapp.webxml.DelegatedFacesSe= rvlet.
>> > 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 pl= ugin.
>> >> (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 corr= ectly is
>> > create
>> > a plugin with a maven lifecycle extension, and do that is ver= y 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. Suggest= ions 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 <lu4242@gmail.com>
>> >>>
>> >>> Hi
>> >>>
>> >>> Unfortunately, maven-shade-plugin has some unwanted s= ide effects.
>> >>>
>> >>> - The source jar file is not updated too, so if we &q= uot;shade" shared, the
>> >>> sources are not updated. In theory, the source jar is= used by IDEs
>> >>> like
>> >>> Eclipse or Netbeans to show the source file of a .cla= ss.
>> >>> - It does not play well with osgi bundle plugin (the = one that create
>> >>> manifest.mf). The problem is the manifest is generate= d before "shade",
>> >>> and
>> >>> we need the later. Really that one is a problem relat= ed to maven
>> >>> itself.
>> >>>
>> >>> The only valid use case I found where maven-shade-plu= gin 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://w= ww.jakobk.com
>> twitter: http://twitter.com/jakobkorherr
>> work: http://www= .irian.at
>
>



--



--00248c0d766cc1c20a049490fc60--