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