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