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
