Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 83374 invoked from network); 26 Jul 2010 20:30:22 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 26 Jul 2010 20:30:22 -0000 Received: (qmail 19223 invoked by uid 500); 26 Jul 2010 20:30:21 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 18962 invoked by uid 500); 26 Jul 2010 20:30:20 -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 18948 invoked by uid 99); 26 Jul 2010 20:30:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Jul 2010 20:30:20 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gerhard.petracek@gmail.com designates 209.85.214.181 as permitted sender) Received: from [209.85.214.181] (HELO mail-iw0-f181.google.com) (209.85.214.181) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Jul 2010 20:30:15 +0000 Received: by iwn42 with SMTP id 42so3585909iwn.12 for ; Mon, 26 Jul 2010 13:29:53 -0700 (PDT) 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=K8XgmDUcK6KpQ3NwsdKDmjpXjPM4Pbe1dbcnQZGHTC8=; b=fJuHKBBUa780qGejwrq2/o2SQux39+8On9tFWI211q8CCsFVnr/BgtmkasMCAVymBL ZuLP7GFWrexqVgkpL8vRZa+7qZFlRuR9Tw73EthQkTYz2HV3aol/qFWLyEldT6183c32 U/QZssrIDpkjZu4OkiYylenQYC2sRFpEN/qiw= 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=RNuZ/LHTFhdWZ8sdglsjZWzl58YiXYC3Yt9M/7+Dxv5vw67fCuqx164bbH1/owX3HO r/HsvmDov6LTlYf8FOX0N4kTpj8HViw8qc7X9JGy+O1dRfGO7+7CHMslrPZYqkaYVYdg gT6NqMjaWC0K7TD60ik8xKyMQC53zbCR3XPj4= Received: by 10.231.146.205 with SMTP id i13mr9177230ibv.30.1280176193624; Mon, 26 Jul 2010 13:29:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.152.194 with HTTP; Mon, 26 Jul 2010 13:29:33 -0700 (PDT) In-Reply-To: References: From: Gerhard Petracek Date: Mon, 26 Jul 2010 22:29:33 +0200 Message-ID: Subject: Re: Use maven-shade-plugin to prevent duplicate code To: MyFaces Development Content-Type: multipart/alternative; boundary=0016e645b77e455f38048c503f47 X-Virus-Checked: Checked by ClamAV on apache.org --0016e645b77e455f38048c503f47 Content-Type: text/plain; charset=ISO-8859-1 for sure i vote: +1! (way more than just 10 :) ) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/26 Jakob Korherr > Hehe, yeah I maybe forgot 10 "many". > > I can provide a wiki page for the general idea and the approach used on > myfaces-test. Then everyone can adopt this idea and see how it works. > > "RIP _shared? :)" > --> yes! > > Regards, > Jakob > > 2010/7/26 Matthias Wessendorf > >> On Mon, Jul 26, 2010 at 8:56 PM, Jakob Korherr >> wrote: >> >> > Hi guys, >> > >> > Working on the tests for FlashImpl, I ran into a problem with the >> > AbstractAttributeMap (MYFACES-2840). After fixing it, I needed to copy >> my >> > changes over to myfaces-test to be able to use the new version in the >> test >> > case (MYFACESTEST-21). And this copying really sucks... >> >> +1 >> >> > >> > If you think about it there are many, many, many different places in the >> >> you forgot a many :-) >> >> > whole MyFaces project where we have duplicate code, for example >> > package-private, unspecified classes on myfaces-api which also exist in >> > myfaces-impl, classes of myfaces-impl which are used for the mock >> > implementations of myfaces-test, or the biggest one: the shared project. >> > >> > An introduction to the maven-shade-plugin: This plugin lets you use a >> > dependency to another project and then at build time it copies all >> needed >> > classes to the created jar file, removes the dependency from the pom.xml >> and >> > changes the imports in the class files. Thus you work with the real >> classes >> > at development time and then at build time the used classes are copied >> into >> > the artifact and the development dependency is gone. Furthermore you can >> > make all kinds of alterations to those classes (e.g. change package). >> > >> > We successfully use the maven-shade-plugin in MyFaces CODI to reuse >> > functionaltiy between the JSF 1.2 and 2.0 modules. In addition, I have >> > locally already used it to fix MYFACESTEST-21: I use it to get the >> > AbstractAttributeMap and all its related classes from myfaces-impl to >> > myfaces-test. And it really works like a calm. >> > >> > However I have to be honest, one thing currently has a bug: filters are >> only >> > applied to the binary and not also to the sources jar (see >> > http://jira.codehaus.org/browse/MSHADE-83), but I already provided a >> patch >> > and a test case for it, so I guess it will be fixed very soon. >> > >> > So if there are no objects, I would like to introduce the >> maven-shade-plugin >> > on myfaces-test at first, to show you guys how awesome it is. >> Afterwards, >> > and of course if you all like it, I would really like to use it on >> several >> > places in MyFaces. This would for example be the chance to get rid of >> the >> > shared project once and for all. >> > >> > Opinions, suggestions and tomatoes are welcome! >> >> +1 on this approach. I'd like to see the *adoption* (kinda) >> documented, so that other (sub) projects can *learn* from your efforts! >> >> RIP _shared? :) >> >> -Matthias >> >> >> > >> > Regards, >> > Jakob >> > >> > -- >> > Jakob Korherr >> > >> > blog: http://www.jakobk.com >> > twitter: http://twitter.com/jakobkorherr >> > work: http://www.irian.at >> > >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Jakob Korherr > > blog: http://www.jakobk.com > twitter: http://twitter.com/jakobkorherr > work: http://www.irian.at > --0016e645b77e455f38048c503f47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
for sure i vote: +1!

(way more than just 10 := ) )

regards,
gerhard

<= div>http://www.irian.at

Your JSF= powerhouse -
JSF Consulting, Development and
Courses in English and German

Pro= fessional Support for Apache MyFaces


2010/7/26 Jakob Korherr <jakob.korherr@gmail.com>
Hehe, yeah I maybe forgot 10 "many".

I can provide a wiki = page for the general idea and the approach used on myfaces-test. Then every= one can adopt this idea and see how it works.

"RIP _shared? :)&= quot;
--> yes!

Regards,
Jakob

On Mon, Jul 26, 2010 at 8:56 PM, Jakob Korherr <jakob.korherr@gmail.com> w= rote:

> Hi guys,
>
> Working on the tests for FlashImpl, I ran into a problem with the
> AbstractAttributeMap (MYFACES-2840). After fixing it, I needed to copy= my
> changes over to myfaces-test to be able to use the new version in the = test
> case (MYFACESTEST-21). And this copying really sucks...

+1

>
> If you think about it there are many, many, many different places in t= he

you forgot a many :-)

> whole MyFaces project where we have duplicate code, for example
> package-private, unspecified classes on myfaces-api which also exist i= n
> myfaces-impl, classes of myfaces-impl which are used for the mock
> implementations of myfaces-test, or the biggest one: the shared projec= t.
>
> An introduction to the maven-shade-plugin: This plugin lets you use a<= br> > dependency to another project and then at build time it copies all nee= ded
> classes to the created jar file, removes the dependency from the pom.x= ml and
> changes the imports in the class files. Thus you work with the real cl= asses
> at development time and then at build time the used classes are copied= into
> the artifact and the development dependency is gone. Furthermore you c= an
> make all kinds of alterations to those classes (e.g. change package).<= br> >
> We successfully use the maven-shade-plugin in MyFaces CODI to reuse > functionaltiy between the JSF 1.2 and 2.0 modules. In addition, I have=
> locally already used it to fix MYFACESTEST-21: I use it to get the
> AbstractAttributeMap and all its related classes from myfaces-impl to<= br> > myfaces-test. And it really works like a calm.
>
> However I have to be honest, one thing currently has a bug: filters ar= e only
> applied to the binary and not also to the sources jar (see
> http://jira.codehaus.org/browse/MSHADE-83), but I already provided a = patch
> and a test case for it, so I guess it will be fixed very soon.
>
> So if there are no objects, I would like to introduce the maven-shade-= plugin
> on myfaces-test at first, to show you guys how awesome it is. Afterwar= ds,
> and of course if you all like it, I would really like to use it on sev= eral
> places in MyFaces. This would for example be the chance to get rid of = the
> shared project once and for all.
>
> Opinions, suggestions and tomatoes are welcome!

+1 on this approach. I'd like to see the *adoption* (kinda)=
documented, so that other (sub) projects can *learn* from your efforts!

RIP _shared? :)

-Matthias


>
> Regards,
> Jakob
>
> --
> Jakob Korherr
>
> blog: http://www.j= akobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.iri= an.at
>



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http:= //twitter.com/mwessendorf



--

--0016e645b77e455f38048c503f47--