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 <[email protected]>: > +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 <[email protected]> >> >> 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 <[email protected]> wrote: >> >> > From: Leonardo Uribe <[email protected]> >> > Subject: Re: Use maven-shade-plugin to prevent duplicate code - >> > revisited >> > To: "MyFaces Development" <[email protected]> >> > 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 <[email protected]>: >> > > 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 <[email protected]> >> > >> >> > >> 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 <[email protected]> >> > wrote: >> > >> >> > >> > From: Jakob Korherr <[email protected]> >> > >> > Subject: Re: Use maven-shade-plugin to >> > prevent duplicate code - >> > >> > revisited >> > >> > To: "MyFaces Development" <[email protected]> >> > >> > 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 <[email protected]>: >> > >> > > 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 <[email protected]>: >> > >> > >> 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 <[email protected]> >> > >> > >>> >> > >> > >>> 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 <[email protected]>: >> > >> > >>> > 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<[email protected]>: >> > >> > >>> >>> >> > >> > >>> >>> 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 >> > >> > >> > > >> > > >> > > >
