Hi, I agree with Gerhard.
Unfortunately I did not try a whole release + site build with the new configuration since you always do that, Leo. So please check on that as soon as possible for you. Regards, Jakob 2011/7/11 Gerhard Petracek <gerhard.petra...@gmail.com>: > hi leo, > actually we should talk about the priority. > imo it has a very high priority! > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2011/7/11 Leonardo Uribe <lu4...@gmail.com> >> >> Hi Gerhard >> >> Does somebody reviewed if the site documentation is generated >> correctly? Isn't any problem with @JSFWebConfigParam? has anybody >> debugged something with the proposed code?. That's the unresolved >> questions I want to solve before apply it (I already mention that >> without response, right?), but if somebody can answer those questions >> could speed it up. >> >> I'm not asking for a loooooot of time. But note there are other issues >> right now ( improve error logging and exception handling, >> MYFACES-3216, fix #{component} refs and isRendered(), improve site >> documentation ), that takes priority over this one. >> >> regards, >> >> Leonardo Uribe >> >> 2011/7/11 Gerhard Petracek <gerhard.petra...@gmail.com>: >> > hi leo, >> > right now i don't see a reason why it should take a lot of time. in the >> > end >> > you just have to look at the resulting artifacts. >> > the javadoc plugin is no blocker (if there is no official release, we >> > can do >> > an external release. as soon as there is an official release of it, we >> > can >> > switch back to it). >> > please provide a bit more information about the "other issues". >> > regards, >> > gerhard >> > http://www.irian.at >> > >> > Your JSF powerhouse - >> > JSF Consulting, Development and >> > Courses in English and German >> > >> > Professional Support for Apache MyFaces >> > >> > >> > >> > 2011/7/11 Leonardo Uribe <lu4...@gmail.com> >> >> >> >> Hi >> >> >> >> Please don't commit the changes until I do a final review. That will >> >> take some time, so please be patient, there are other issues on core >> >> right now that we need to solve too. Anyway we can't commit the code >> >> without a release of javadoc plugin. >> >> >> >> regards, >> >> >> >> Leonardo Uribe >> >> >> >> 2011/7/11 Jakob Korherr <jakob.korh...@gmail.com>: >> >> > Hi, >> >> > >> >> >> right - there are no entries in the manifest. they will be generated >> >> >> for the separated osgi bundle/s during the build (based on the build >> >> >> config). >> >> > >> >> > Jep! That was the idea in the first place (look at the branch and >> >> > you'll see no bundle plugin in myfaces-api or myfaces-impl, but in >> >> > myfaces-bundle). >> >> > >> >> > @Leo: From my point of view, the branch is complete. In addition, >> >> > Mark >> >> > committed my patch for MJAVADOC-320, thus the javadoc generation does >> >> > already work too (if you use the latest 2.8.1-SNAPSHOT of the >> >> > javadoc-plugin). >> >> > >> >> > Here is a short summary of the proposed changes: >> >> > >> >> > - remove felix bundle plugin executions from myfaces-api and >> >> > myfaces-impl (we have myfaces-bundle for OSGi). >> >> > - use maven-shade-plugin with package relocation (shared to >> >> > shared_impl) in myfaces-impl instead of >> >> > a) ant-task to rename source from shared to shared_impl >> >> > (myfaces-shared-impl project) >> >> > b) dependency plugin to unpack shared-impl-sources.jar in >> >> > myfaces-impl and build-helper-plugin to add these sources as a new >> >> > source folder >> >> > - use maven-javadoc-plugin with includeSourceDependencies=true for >> >> > shared (and impl-ee6) in order to include the javadocs of shared in >> >> > the myfaces-impl javadocs >> >> > >> >> > These changes have the following implications: >> >> > >> >> > - all imports of myfaces-shared code in myfaces-impl will go to >> >> > org.apache.myfaces.shared.* instead of >> >> > org.apache.myfaces.shared_impl.*, because relocation is done on >> >> > class-file-basis instead of source-file-basis. >> >> > - myfaces-shared-core will be a direct dependency of myfaces-impl at >> >> > development time, thus enabling hot-deployments,... when changing >> >> > stuff in shared at development time. >> >> > - myfaces-shared-impl project will be obsolete (b/c - as already >> >> > mentioned - myfaces-impl uses shared-core instead of shared-impl). >> >> > >> >> > >> >> > If there are no objections, I will merge in the changes from the >> >> > branch >> >> > soon! >> >> > >> >> > Regards, >> >> > Jakob >> >> > >> >> > 2011/7/8 Leonardo Uribe <lu4...@gmail.com>: >> >> >> Hi Gerhard >> >> >> >> >> >> Ok, now that part has sense. >> >> >> >> >> >> There are still some things to check before apply the change. Please >> >> >> let me know when all code is on the branch and I'll do a final >> >> >> in-deep >> >> >> check. >> >> >> >> >> >> regards, >> >> >> >> >> >> Leonardo Uribe >> >> >> >> >> >> 2011/7/8 Gerhard Petracek <gerhard.petra...@gmail.com>: >> >> >>> hi leo, >> >> >>> right - there are no entries in the manifest. they will be >> >> >>> generated >> >> >>> for the >> >> >>> separated osgi bundle/s during the build (based on the build >> >> >>> config). >> >> >>> regards, >> >> >>> gerhard >> >> >>> http://www.irian.at >> >> >>> >> >> >>> Your JSF powerhouse - >> >> >>> JSF Consulting, Development and >> >> >>> Courses in English and German >> >> >>> >> >> >>> Professional Support for Apache MyFaces >> >> >>> >> >> >>> >> >> >>> >> >> >>> 2011/7/8 Leonardo Uribe <lu4...@gmail.com> >> >> >>>> >> >> >>>> Hi >> >> >>>> >> >> >>>> Ok, I agree it is not a problem, but if that so, shouldn't we >> >> >>>> remove >> >> >>>> OSGi entries on the manifests in myfaces-api and impl jars? just >> >> >>>> to >> >> >>>> prevent possible confusions about that. >> >> >>>> >> >> >>>> regards, >> >> >>>> >> >> >>>> Leonardo Uribe >> >> >>>> >> >> >>>> 2011/7/8 Gerhard Petracek <gerhard.petra...@gmail.com>: >> >> >>>> > +1! >> >> >>>> > regards, >> >> >>>> > gerhard >> >> >>>> > >> >> >>>> > http://www.irian.at >> >> >>>> > >> >> >>>> > Your JSF powerhouse - >> >> >>>> > JSF Consulting, Development and >> >> >>>> > Courses in English and German >> >> >>>> > >> >> >>>> > Professional Support for Apache MyFaces >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > 2011/7/8 Mark Struberg <strub...@yahoo.de> >> >> >>>> >> >> >> >>>> >> Leo, SpringDM does much more work usually to tweak something >> >> >>>> >> for >> >> >>>> >> their >> >> >>>> >> needs! >> >> >>>> >> They can just use the myfaces-bundle.jar as each and every >> >> >>>> >> other >> >> >>>> >> OSGi >> >> >>>> >> user >> >> >>>> >> does too. >> >> >>>> >> >> >> >>>> >> What I meant was more: we shall _not_ do something ugly just to >> >> >>>> >> make >> >> >>>> >> OSGi >> >> >>>> >> happy ^^ >> >> >>>> >> >> >> >>>> >> So using the maven-shade-plugin is perfectly fine and will be a >> >> >>>> >> big >> >> >>>> >> benefit for cleaning up the shared project! >> >> >>>> >> >> >> >>>> >> LieGrue, >> >> >>>> >> strub >> >> >>>> >> >> >> >>>> >> --- On Fri, 7/8/11, Leonardo Uribe <lu4...@gmail.com> wrote: >> >> >>>> >> >> >> >>>> >> > From: Leonardo Uribe <lu4...@gmail.com> >> >> >>>> >> > Subject: Re: Use maven-shade-plugin to prevent duplicate code >> >> >>>> >> > - >> >> >>>> >> > revisited >> >> >>>> >> > To: "MyFaces Development" <dev@myfaces.apache.org> >> >> >>>> >> > Date: Friday, July 8, 2011, 3:20 PM >> >> >>>> >> > Hi >> >> >>>> >> > >> >> >>>> >> > I don't think the OSGi mention is off-topic. In theory it >> >> >>>> >> > is possible >> >> >>>> >> > to setup myfaces-api and myfaces-impl jars in a OSGi >> >> >>>> >> > container using >> >> >>>> >> > SpringDM. The changes proposed just prevents that possible >> >> >>>> >> > setup to >> >> >>>> >> > work, but that one was the first known successful >> >> >>>> >> > environment to use. >> >> >>>> >> > Note in this case the are no problems with FactoryFinder, >> >> >>>> >> > because >> >> >>>> >> > Spring DM provide a thread context classloader (TCCL) that >> >> >>>> >> > fix that. >> >> >>>> >> > >> >> >>>> >> > The changes proposed impose the restriction that anyone who >> >> >>>> >> > wants to >> >> >>>> >> > use OSGi should use myfaces-bundle jar instead. But from >> >> >>>> >> > other point >> >> >>>> >> > of view it is clear that in such environment users could >> >> >>>> >> > want to use >> >> >>>> >> > mojarra api and myfaces impl, even if that is not really >> >> >>>> >> > possible. >> >> >>>> >> > >> >> >>>> >> > Note the previous arguments are questionable of course, >> >> >>>> >> > because in >> >> >>>> >> > practice people will use myfaces-bundle jar, keeping things >> >> >>>> >> > simple >> >> >>>> >> > because you have to deal only with one bundle. So it does >> >> >>>> >> > not suppose >> >> >>>> >> > a problem, just a "side effect" to keep in mind. >> >> >>>> >> > >> >> >>>> >> > I think it is required to specify in more details which are >> >> >>>> >> > the "side >> >> >>>> >> > effects" of the changes proposed. Note on a previous mail i >> >> >>>> >> > said "... >> >> >>>> >> > I haven't look the code provided in deep ...", but I guess >> >> >>>> >> > the patch >> >> >>>> >> > proposed will prevent @JSFWebConfigParam annotations to be >> >> >>>> >> > scanned for >> >> >>>> >> > myfaces builder plugin and consequently break this >> >> >>>> >> > generated site >> >> >>>> >> > page: >> >> >>>> >> > >> >> >>>> >> > http://myfaces.apache.org/core20/myfaces-impl/webconfig.html >> >> >>>> >> > http://myfaces.apache.org/core21/myfaces-impl/webconfig.html >> >> >>>> >> > >> >> >>>> >> > I don't see very clear the "benefits" of the change. I >> >> >>>> >> > suppose it >> >> >>>> >> > enhance debugging in some way, but is that true? can I do a >> >> >>>> >> > change on >> >> >>>> >> > shared, and do not have to recompile to see the change? If >> >> >>>> >> > I set a >> >> >>>> >> > break point on shared-core, the debugger will stop there? I >> >> >>>> >> > would like >> >> >>>> >> > to see a strong (and maybe heavier and tedious but >> >> >>>> >> > necessary) >> >> >>>> >> > argumentation before do the change. >> >> >>>> >> > >> >> >>>> >> > regards, >> >> >>>> >> > >> >> >>>> >> > Leonardo Uribe >> >> >>>> >> > >> >> >>>> >> > 2011/7/8 Gerhard Petracek <gerhard.petra...@gmail.com>: >> >> >>>> >> > > hi mark, >> >> >>>> >> > > that's a bit off-topic ;) we already (have to) provide >> >> >>>> >> > osgi bundles. we just >> >> >>>> >> > > continue to do the same with the shade-plugin. >> >> >>>> >> > > regards, >> >> >>>> >> > > gerhard >> >> >>>> >> > > >> >> >>>> >> > > http://www.irian.at >> >> >>>> >> > > >> >> >>>> >> > > Your JSF powerhouse - >> >> >>>> >> > > JSF Consulting, Development and >> >> >>>> >> > > Courses in English and German >> >> >>>> >> > > >> >> >>>> >> > > Professional Support for Apache MyFaces >> >> >>>> >> > > >> >> >>>> >> > > >> >> >>>> >> > > >> >> >>>> >> > > 2011/7/8 Mark Struberg <strub...@yahoo.de> >> >> >>>> >> > >> >> >> >>>> >> > >> Hi folks! >> >> >>>> >> > >> >> >> >>>> >> > >> There are 2 problems with JSF under OSGi >> >> >>>> >> > >> >> >> >>>> >> > >> a) OSGi is in reality a _big_ mess and not really >> >> >>>> >> > worth the troubles ;) >> >> >>>> >> > >> It _should_ make it possible to elegantly switch >> >> >>>> >> > implementations, but in >> >> >>>> >> > >> practice you need to import/export all packages >> >> >>>> >> > explicitly, even those which >> >> >>>> >> > >> are only used indirectly. >> >> >>>> >> > >> >> >> >>>> >> > >> b) the design of the JSF-api could be more clear >> >> >>>> >> > with separation (hey, >> >> >>>> >> > >> it's 10 years old!). It is not possible to use a >> >> >>>> >> > MyFaces-impl with a >> >> >>>> >> > >> mojarra-api and vice versa, because methods like >> >> >>>> >> > >> FacesContext#getCurrentInstance() (and similar) >> >> >>>> >> > access impl classes from the >> >> >>>> >> > >> API package. This makes it pretty hard to work >> >> >>>> >> > OSGi. >> >> >>>> >> > >> >> >> >>>> >> > >> LieGrue, >> >> >>>> >> > >> strub >> >> >>>> >> > >> >> >> >>>> >> > >> --- On Fri, 7/8/11, Jakob Korherr >> >> >>>> >> > >> <jakob.korh...@gmail.com> >> >> >>>> >> > wrote: >> >> >>>> >> > >> >> >> >>>> >> > >> > From: Jakob Korherr <jakob.korh...@gmail.com> >> >> >>>> >> > >> > Subject: Re: Use maven-shade-plugin to >> >> >>>> >> > prevent duplicate code - >> >> >>>> >> > >> > revisited >> >> >>>> >> > >> > To: "MyFaces Development" <dev@myfaces.apache.org> >> >> >>>> >> > >> > Date: Friday, July 8, 2011, 1:09 PM >> >> >>>> >> > >> > Hi Leo, >> >> >>>> >> > >> > >> >> >>>> >> > >> > Yes, I remember that you did some work >> >> >>>> >> > related to this >> >> >>>> >> > >> > stuff. Some >> >> >>>> >> > >> > comments about your problems: >> >> >>>> >> > >> > >> >> >>>> >> > >> > 1) If you use myfaces-impl, the packages >> >> >>>> >> > really are >> >> >>>> >> > >> > *.shared_impl.* >> >> >>>> >> > >> > (shade does the relocation on the classes). >> >> >>>> >> > But a part of >> >> >>>> >> > >> > this >> >> >>>> >> > >> > statement is still true - we need to check >> >> >>>> >> > config files >> >> >>>> >> > >> > with >> >> >>>> >> > >> > references to shared and shared_impl. >> >> >>>> >> > >> > >> >> >>>> >> > >> > 2) That's not true. We solved this problem in >> >> >>>> >> > CODI, as >> >> >>>> >> > >> > described. >> >> >>>> >> > >> > Please take a look at the code ;) >> >> >>>> >> > >> > >> >> >>>> >> > >> > 3) We don't need to execute felix bundle >> >> >>>> >> > plugin directly >> >> >>>> >> > >> > in >> >> >>>> >> > >> > myfaces-impl, b/c it won't work in an OSGi >> >> >>>> >> > environment >> >> >>>> >> > >> > anyway (see >> >> >>>> >> > >> > e.g. FactoryFinder problems). We have >> >> >>>> >> > myfaces-bundle for >> >> >>>> >> > >> > this matter! >> >> >>>> >> > >> > >> >> >>>> >> > >> > Regards, >> >> >>>> >> > >> > Jakob >> >> >>>> >> > >> > >> >> >>>> >> > >> > 2011/7/7 Leonardo Uribe <lu4...@gmail.com>: >> >> >>>> >> > >> > > Hi >> >> >>>> >> > >> > > >> >> >>>> >> > >> > > I haven't look the code provided in >> >> >>>> >> > deep, but long >> >> >>>> >> > >> > time ago I tried >> >> >>>> >> > >> > > it. In that time I saw the following >> >> >>>> >> > problems: >> >> >>>> >> > >> > > >> >> >>>> >> > >> > > 1. There are some classes on shared that >> >> >>>> >> > are used >> >> >>>> >> > >> > outside it. For >> >> >>>> >> > >> > > example, see >> >> >>>> >> > >> > >> >> >>>> >> > >> >> >>>> >> > org.apache.myfaces.shared.webapp.webxml.DelegatedFacesServlet. >> >> >>>> >> > >> > > We need to detect all similar cases and >> >> >>>> >> > move those >> >> >>>> >> > >> > classes to >> >> >>>> >> > >> > > myfaces-impl, but renaming shared with >> >> >>>> >> > shared-impl, or >> >> >>>> >> > >> > just create >> >> >>>> >> > >> > > classes that extends from the ones in >> >> >>>> >> > shared, to >> >> >>>> >> > >> > preserve backward >> >> >>>> >> > >> > > behavior. In theory, the affected >> >> >>>> >> > packages are: >> >> >>>> >> > >> > > >> >> >>>> >> > >> > > >> >> >>>> >> > org.apache.myfaces.shared_impl.webapp.webxml >> >> >>>> >> > >> > > >> >> >>>> >> > org.apache.myfaces.shared_impl.taglib >> >> >>>> >> > >> > > >> >> >>>> >> > org.apache.myfaces.shared_impl.taglib.core >> >> >>>> >> > >> > > >> >> >>>> >> > >> > > 2. Generated artifacts (-sources.jar, >> >> >>>> >> > -javadoc.jar) >> >> >>>> >> > >> > has problems. It >> >> >>>> >> > >> > > is clear javadoc and source jars will >> >> >>>> >> > not have >> >> >>>> >> > >> > shared-impl. >> >> >>>> >> > >> > > 3. shade plugin and felix maven bundle >> >> >>>> >> > plugin does not >> >> >>>> >> > >> > play well. By >> >> >>>> >> > >> > > default bundle plugin is executed before >> >> >>>> >> > shade plugin, >> >> >>>> >> > >> > but what you >> >> >>>> >> > >> > > want is the opposite, so the information >> >> >>>> >> > on >> >> >>>> >> > >> > MANIFEST.MF could be >> >> >>>> >> > >> > > generated taking into account all >> >> >>>> >> > classes. Note if we >> >> >>>> >> > >> > solve 1, this >> >> >>>> >> > >> > > should not be a problem, because classes >> >> >>>> >> > inside shared >> >> >>>> >> > >> > are myfaces >> >> >>>> >> > >> > > internals (remember why spi interfaces >> >> >>>> >> > are on impl >> >> >>>> >> > >> > package and not in >> >> >>>> >> > >> > > shared). >> >> >>>> >> > >> > > >> >> >>>> >> > >> > > I'll keep an eye on the resulting work. >> >> >>>> >> > >> > > >> >> >>>> >> > >> > > regards, >> >> >>>> >> > >> > > >> >> >>>> >> > >> > > Leonardo Uribe >> >> >>>> >> > >> > > >> >> >>>> >> > >> > > 2011/7/7 Gerhard Petracek >> >> >>>> >> > >> > > <gerhard.petra...@gmail.com>: >> >> >>>> >> > >> > >> hi jakob, >> >> >>>> >> > >> > >> great - thx! >> >> >>>> >> > >> > >> regards, >> >> >>>> >> > >> > >> gerhard >> >> >>>> >> > >> > >> >> >> >>>> >> > >> > >> http://www.irian.at >> >> >>>> >> > >> > >> >> >> >>>> >> > >> > >> Your JSF powerhouse - >> >> >>>> >> > >> > >> JSF Consulting, Development and >> >> >>>> >> > >> > >> Courses in English and German >> >> >>>> >> > >> > >> >> >> >>>> >> > >> > >> Professional Support for Apache >> >> >>>> >> > MyFaces >> >> >>>> >> > >> > >> >> >> >>>> >> > >> > >> >> >> >>>> >> > >> > >> >> >> >>>> >> > >> > >> 2011/7/7 Jakob Korherr <jakob.korh...@gmail.com> >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> Hi guys, >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> I committed a working draft to >> >> >>>> >> > the branch at >> >> >>>> >> > >> > [1]. However, there are >> >> >>>> >> > >> > >>> some issues with the >> >> >>>> >> > javadoc-plugin (see [2]) >> >> >>>> >> > >> > that must be fixed first >> >> >>>> >> > >> > >>> in order to get the expected >> >> >>>> >> > javadoc. The >> >> >>>> >> > >> > other stuff (shading of >> >> >>>> >> > >> > >>> shared and impl-ee6) already >> >> >>>> >> > works as >> >> >>>> >> > >> > expected! >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> Feel free to try it out >> >> >>>> >> > yourself. Comments and >> >> >>>> >> > >> > suggestions are welcome! >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> Regards, >> >> >>>> >> > >> > >>> Jakob >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> [1] >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.8_shade_prototype/ >> >> >>>> >> > >> > >>> [2] https://jira.codehaus.org/browse/MJAVADOC-320 >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> 2011/7/7 Werner Punz <werner.p...@gmail.com>: >> >> >>>> >> > >> > >>> > Excellent news ++1, the >> >> >>>> >> > shared as we have >> >> >>>> >> > >> > it is a bad design decision I >> >> >>>> >> > >> > >>> > hope >> >> >>>> >> > >> > >>> > shade will get rid of our >> >> >>>> >> > debugging >> >> >>>> >> > >> > issues we have with our current >> >> >>>> >> > >> > >>> > shared. >> >> >>>> >> > >> > >>> > >> >> >>>> >> > >> > >>> > >> >> >>>> >> > >> > >>> > Werner >> >> >>>> >> > >> > >>> > >> >> >>>> >> > >> > >>> > >> >> >>>> >> > >> > >>> > Am 07.07.11 11:04, schrieb >> >> >>>> >> > Jakob >> >> >>>> >> > >> > Korherr: >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> Hi Gerhard, >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> Thx for (re-)opening >> >> >>>> >> > this thread. I >> >> >>>> >> > >> > already created a jira issue [1] >> >> >>>> >> > >> > >>> >> and a core-branch [2] >> >> >>>> >> > for >> >> >>>> >> > >> > prototyping. >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> Currently I am >> >> >>>> >> > struggling a little >> >> >>>> >> > >> > bit with the javadoc-plugin, but >> >> >>>> >> > >> > >>> >> this stuff should be >> >> >>>> >> > fixed soon >> >> >>>> >> > >> > (maybe even today). >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> I'll let you guys know >> >> >>>> >> > when I am done >> >> >>>> >> > >> > with the configuration, so that >> >> >>>> >> > >> > >>> >> you can try it out >> >> >>>> >> > yourselves! >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> Regards, >> >> >>>> >> > >> > >>> >> Jakob >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> [1] >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> https://issues.apache.org/jira/browse/MYFACES-3205 >> >> >>>> >> > >> > >>> >> [2] >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.8_shade_prototype/ >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> 2011/7/7 Gerhard >> >> >>>> >> > Petracek<gerhard.petra...@gmail.com>: >> >> >>>> >> > >> > >>> >>> >> >> >>>> >> > >> > >>> >>> hi @ all, >> >> >>>> >> > >> > >>> >>> the goal (as we >> >> >>>> >> > discussed before) >> >> >>>> >> > >> > is to get rid of the shared-impl >> >> >>>> >> > >> > >>> >>> module >> >> >>>> >> > >> > >>> >>> and move to the >> >> >>>> >> > shade-plugin for >> >> >>>> >> > >> > maven. >> >> >>>> >> > >> > >>> >>> issues with javadoc >> >> >>>> >> > and osgi >> >> >>>> >> > >> > bundles prevented us from doing this >> >> >>>> >> > >> > >>> >>> step. >> >> >>>> >> > >> > >>> >>> however, with codi >> >> >>>> >> > v1 we have a >> >> >>>> >> > >> > project(-configuration) which fixes >> >> >>>> >> > >> > >>> >>> all >> >> >>>> >> > >> > >>> >>> the >> >> >>>> >> > >> > >>> >>> issues we had with >> >> >>>> >> > the >> >> >>>> >> > >> > shade-plugin. >> >> >>>> >> > >> > >>> >>> -> imo we can >> >> >>>> >> > (and should) >> >> >>>> >> > >> > use it also for myfaces-core. >> >> >>>> >> > >> > >>> >>> regards, >> >> >>>> >> > >> > >>> >>> gerhard >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> >> >> >> >>>> >> > >> > >>> > >> >> >>>> >> > >> > >>> > >> >> >>>> >> > >> > >>> > >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> >> >> >>>> >> > >> > >>> -- >> >> >>>> >> > >> > >>> 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
