So - without the dependencies problem - +100 for getting rid of shared. The sooner this goes, the better.
But, of course: make sure the shade thing runs smoothly with the IDE integration (I want to be able to check-out the sample app and start working, highly favored best case: without having to do a full maven build after each change). And, of course, make sure there is no issues with the deployment or circular dependencies... I am sure you guys will be able to sort this out ;) best regards, Martin On Mon, Jul 26, 2010 at 11:33 PM, Jan-Kees Van Andel <jankeesvanan...@gmail.com> wrote: > I think you're right. The only real solution is a nice and clean Shared > project. Otherwise the dependencies will become very tangled. > /JK > > > Sent from my iPad > Op 26 jul. 2010 om 23:10 heeft Leonardo Uribe <lu4...@gmail.com> het > volgende geschreven: > > Hi > > 2010/7/26 Jakob Korherr <jakob.korh...@gmail.com> >> >> "This code is just some wrappers and it is not expected this will change >> in the future. So the question is why bother us in this case? In this case >> use maven-shade-plugin is not worth." >> >> Actually and quite frankly it really is worth it. It is very easy and if >> you understand it, it is even easier than just copy & past, because you >> don't have to change packages manually. Furthermore, if you look at those >> classes, they have been refactored a couple of times from the very beginning >> (myfaces 1.1). >> >> In addition, there will surely be myfaces-test versions for JSF 2.1 (and >> 2.2, 3.0,...) and then you will always have to copy those classes and hope >> nothing will change. If you use the shade-plugin, you can throw your worries >> away! >> > > Myfaces-test uses myfaces-builder-plugin unpack goal to share code between > versions, so the wrappers will be only on myfaces-test12. > > I'm worried about a possible circular dependency between myfaces core and > myfaces test. The wrappers are on myfaces-core, but myfaces-test requires > core wrappers to be build, but we require myfaces-test on core to run some > tests, so which one should be compiled first? which one should be released > first?. When you execute maven release plugin, it is necessary to change > versions to the release ones, so do that will cause a lot of problems on > release. > > regards, > > Leonardo > >> >> Regards, >> Jakob >> >> 2010/7/26 Mark Struberg <strub...@yahoo.de> >>> >>> I think you are both right. I can understand that copying code is really >>> ugly, >>> but otoh Leos argument is also pretty strong. >>> >>> There is a solution for this. Cut off the shared parts and move it into >>> an own >>> module. >>> >>> This sounds easy but isn't always doable. But it might be worth a try. >>> >>> LieGrue, >>> strub >>> >>> >>> > >>> >From: Jakob Korherr <jakob.korh...@gmail.com> >>> >To: MyFaces Development <dev@myfaces.apache.org> >>> >Sent: Mon, July 26, 2010 10:32:31 PM >>> >Subject: Re: Use maven-shade-plugin to prevent duplicate code >>> > >>> >Why would you like to have any duplicate code? This should not be >>> > anyone's >>> >target in my opinion... >>> > >>> > >>> > >>> >2010/7/26 Leonardo Uribe <lu4...@gmail.com> >>> > >>> >Hi >>> >> >>> >>Yes, it is true, that myfaces-test is used for testing myfaces core, >>> >> but in >>> >>theory, myfaces-test should be used to test jsf stuff without rely on a >>> >> specific >>> >> >>> >>jsf implementation. >>> >> >>> >>In this case I think (and it is my personal opinion) it is better to >>> >> have some >>> >>> >>duplicate code and keep things simple. Use maven-shade-plugin to deal >>> >> with >>> >>shared code is another different history. >>> >> >>> >>regards, >>> >> >>> >>Leonardo Uribe >>> >> >>> >> >>> >>2010/7/26 Jakob Korherr <jakob.korh...@gmail.com> >>> >> >>> >> >>> >>Actually this already is the case: MyFaces-test is used for testing >>> >> MyFaces >>> >>core. >>> >>> >>> >>> >>> >>>Regards, >>> >>>Jakob >>> >>> >>> >>> >>> >>>2010/7/26 Rudy De Busscher <rdebussc...@gmail.com> >>> >>> >>> >>>Hi Jakob, >>> >>>> >>> >>>>So it was never the idea that MyFaces Test (and maybe the GSOC >>> >>>> testing effort) >>> >> >>> >>>>will be used to supply the test infrastructure for MyFaces Core? >>> >>>> >>> >>>>In that case : MyFaces Core can supply code. >>> >>>> >>> >>>>Regards >>> >>>>Rudy. >>> >>>> >>> >>>> >>> >>>> >>> >>>>On 26 July 2010 22:01, Jakob Korherr <jakob.korh...@gmail.com> wrote: >>> >>>> >>> >>>>Hi Rudy, >>> >>>>> >>> >>>>>Yes we totally have to be careful with circular dependencies, but it >>> >>>>> should not >>> >>>> >>> >>>>>be that big problem. >>> >>>>> >>> >>>>>Actually I think that the opposite is true. MyFaces core is the JSF >>> >>>>>implementation and MyFaces test provides the Mock classes for JSF, >>> >>>>> and for >>> >>>>>implementing these Mock classes it can reuse some functionality >>> >>>>> already present >>> >>>> >>> >>>>>in MyFaces core (e.g. the real classes which should be mocked). IMO >>> >>>>> this is the >>> >>>> >>> >>>>>way it should be. >>> >>>>> >>> >>>>>Regards, >>> >>>>>Jakob >>> >>>>> >>> >>>>> >>> >>>>>2010/7/26 Rudy De Busscher <rdebussc...@gmail.com> >>> >>>>> >>> >>>>> >>> >>>>>Hi all, >>> >>>>>> >>> >>>>>>I agree, duplicated code has to be avoided and when the >>> >>>>>> maven-shade-plugin can >>> >>>> >>> >>>>>>help, the better. >>> >>>>>> >>> >>>>>>but I think we have to define which project supplies code for which >>> >>>>>> other >>> >>>>>>project (so that we don't get a spaghetti (using the tomatoes ;) or >>> >>>>>> get circular >>> >>>>>> >>> >>>>>>dependencies.). I know that MyFaces core exists much longer then >>> >>>>>> MyFaces Test >>> >>>> >>> >>>>>>but I find it more >>> >>>>>> >>> >>>>>> >>> >>>>>>logic that the MyFaces Test supplies code for the MyFaces Core >>> >>>>>> project. >>> >>>>>> >>> >>>>>>my 2c. >>> >>>>>> >>> >>>>>>Regards >>> >>>>>>Rudy >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>>On 26 July 2010 21:40, Matthias Wessendorf <mat...@apache.org> >>> >>>>>> wrote: >>> >>>>>> >>> >>>>>>On Mon, Jul 26, 2010 at 9:30 PM, Jakob Korherr >>> >>>>>> <jakob.korh...@gmail.com> >>> >>>>wrote: >>> >>>>>>>> Hehe, yeah I maybe forgot 10 "many". >>> >>>>>>>> >>> >>>>>>>> I can provide a wiki page for the general idea and the approach >>> >>>>>>>> used on >>> >>>>>>>> myfaces-test. >>> >>>>>>> >>> >>>>>>>+1 >>> >>>>>>> >>> >>>>>>> >>> >>>>>>>> Then everyone can adopt this idea and see how it works. >>> >>>>>>> >>> >>>>>>>great. I have that on my agenda as well, for Trinidad but a >>> >>>>>>>new release is more important, today... >>> >>>>>>> >>> >>>>>>>> >>> >>>>>>>> "RIP _shared? :)" >>> >>>>>>>> --> yes! >>> >>>>>>> >>> >>>>>>>I thought so. Yes! :) >>> >>>>>>> >>> >>>>>>> >>> >>>>>>>> >>> >>>>>>>> Regards, >>> >>>>>>>> Jakob >>> >>>>>>>> >>> >>>>>>>> 2010/7/26 Matthias Wessendorf <mat...@apache.org> >>> >>>>>>>>> >>> >>>>>>>>> On Mon, Jul 26, 2010 at 8:56 PM, Jakob Korherr >>> ><jakob.korh...@gmail.com> >>> >>>>>>>>> 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 >>> >>>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>>-- >>> >>>>>>> >>> >>>>>>>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 >>> >>>>> >>> >>>> >>> >>> >>> >>> >>> >>>-- >>> >>> >>> >>>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 > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
