Hi To close this problem quickly (I'm getting tired of this issue, and I want to do some performance stuff on shared), I created a branch with the proposal for 2.1.x:
http://svn.apache.org/repos/asf/myfaces/core/branches/refactor_shared_2_1_x/ http://svn.apache.org/repos/asf/myfaces/shared/branches/refactor_shared_4_1_x/ There you can see in practice what I'm saying. A profile was added on shared to sync code in a semi-automatic way. Just type mvn install -Dsynch-shared=true and then commit the changes. Now core has a new module and use shade plugin, but since all package names were renamed from shared to shared-impl, the confusion about packages is gone (and shared-impl too), and you can see the advantage of shade over unpack goal: the module is added as dependency on your pom. Only some selected classes were let on the same package to ensure backward compatibility. In all this refactoring, care must be taken to preserve svn history, doing the changes directly on svn repo instead copy and commit. If no objections, I'll do this refactor soon for 2.0.x / 2.1.x . The "spread" build idea for myfaces will be done after commit this code. regards, Leonardo Uribe 2011/7/13 Leonardo Uribe <lu4...@gmail.com>: > Hi > > I have checked the questions I had and here are the answers (You can > try it without any special setup, just mvn clean install and then mvn > site -Pgenerate-site): > > What happen with the site documentation? > > - javadoc report is not generated (????). > - x-ref report doesn't show shared code. > - JDepend and PMD reports doesn't take shared. > > All that is expected, because in practice we are "shading" shared. > > Isn't any problem with @JSFWebConfigParam? > > As I was expecting, the report doesn't take any init param on shared, > because those sources are not scanned anymore. > > How debugging looks with the proposed code? > > It works. You see org.apache.myfaces.shared instead > org.apache.myfaces.shared-impl, but the line breaks are ok. I seems > there was some fix on maven shade plugin related to this problem. > > What I see in this code is just use shade plugin instead unpack goal > for shared. But I have to say that the evidence is clear: unpack goal > fits better. > > But the main big problem is how to get rid of shared. First I have to > remember why we want so badly to get rid of it: > > 1. When there is an error there, you have to compile shared core, > shared-impl and myfaces core impl to reflect the change. If you are > debugging on a web app, you have to compile it too. In short this > means a lot of time waiting. > 2. When there is an error there, users get confused, because it is > another project. > > I think this alternative is possible > > 1. the base code on shared should live as a module on myfaces-core project. > 2. shared project should do a hard copy of the code inside myfaces > core project. This means just sync the code from time to time and > release it. In this way projects like tomahawk or any other can > "shade" or "unpack" that code an use it. > > The next step is have a "spread" build of myfaces. This means have > some modules like this: > > api > shared > impl-base > impl-ee6 > ..... > > impl (the sum of shared + impl-base + impl-ee6 + ...) > bundle > > If shared is a module just like api or impl in myfaces folder, you can > setup a project that use api + all separate modules. In this way, if > there is an error on shared, you can compile just that module and your > web application and that's it!. Sounds almost obvious, isn't it?. > > Do this means change all package names on impl from shared-impl to > shared. Each module will have its own myfaces-metadata.xml, so builder > plugin will work correctly. > > Suggestions are welcome. > > regards, > > Leonardo Uribe > > 2011/7/11 Jakob Korherr <jakob.korh...@gmail.com>: >> Hi, >> >> I agree with Gerhard. >> >> Unfortunately I did not try a whole release + site build with the new >> configuration since you always do that, Leo. So please check on that >> as soon as possible for you. >> >> Regards, >> Jakob >> >> 2011/7/11 Gerhard Petracek <gerhard.petra...@gmail.com>: >>> hi leo, >>> actually we should talk about the priority. >>> imo it has a very high priority! >>> 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 Gerhard >>>> >>>> Does somebody reviewed if the site documentation is generated >>>> correctly? Isn't any problem with @JSFWebConfigParam? has anybody >>>> debugged something with the proposed code?. That's the unresolved >>>> questions I want to solve before apply it (I already mention that >>>> without response, right?), but if somebody can answer those questions >>>> could speed it up. >>>> >>>> I'm not asking for a loooooot of time. But note there are other issues >>>> right now ( improve error logging and exception handling, >>>> MYFACES-3216, fix #{component} refs and isRendered(), improve site >>>> documentation ), that takes priority over this one. >>>> >>>> regards, >>>> >>>> Leonardo Uribe >>>> >>>> 2011/7/11 Gerhard Petracek <gerhard.petra...@gmail.com>: >>>> > 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 >>>> >> > >>>> > >>>> > >>> >>> >> >> >> >> -- >> Jakob Korherr >> >> blog: http://www.jakobk.com >> twitter: http://twitter.com/jakobkorherr >> work: http://www.irian.at >> >
