+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 > > >> > > > > > > > > > >
