Hi Ok, it is done. Now core has a new module called shared and shared-impl is gone. For checkout 2.0.x or 2.1.x (trunk), compile shared 4.0.x or 4.1.x is no longer necessary, since all code is now on 2.0.x/2.1.x places. I'll do the additional adjustments on myfaces site soon. The idea is redesign the site for be more user friendly.
regards, Leonardo Uribe 2011/7/25 Leonardo Uribe <[email protected]>: > Hi > > If no objections I'll do the changes on 2.0.x and 2.1.x next Wednesday. > > regards, > > Leonardo Uribe > > 2011/7/24 Gerhard Petracek <[email protected]>: >> hi leo, >> i made a short test and the usage looks fine. >> furthermore, i had a quick look at the build files and besides the obvious >> differences (which are required for your suggestion) i saw some details >> which are different compared to the branch created by jakob. >> if those differences are fine for everyone (esp. jakob and mark), we can use >> this suggestion (at least for now) since it improves the current situation. >> 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/23 Leonardo Uribe <[email protected]> >>> >>> 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 <[email protected]>: >>> > 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 <[email protected]>: >>> >> 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 <[email protected]>: >>> >>> 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 <[email protected]> >>> >>>> >>> >>>> 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 <[email protected]>: >>> >>>> > 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 <[email protected]> >>> >>>> >> >>> >>>> >> 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 <[email protected]>: >>> >>>> >> > 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 <[email protected]>: >>> >>>> >> >> 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 <[email protected]>: >>> >>>> >> >>> 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 <[email protected]> >>> >>>> >> >>>> >>> >>>> >> >>>> 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 <[email protected]>: >>> >>>> >> >>>> > +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 <[email protected]> >>> >>>> >> >>>> >> >>> >>>> >> >>>> >> 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 <[email protected]> >>> >>>> >> >>>> >> wrote: >>> >>>> >> >>>> >> >>> >>>> >> >>>> >> > From: Leonardo Uribe <[email protected]> >>> >>>> >> >>>> >> > Subject: Re: Use maven-shade-plugin to prevent duplicate >>> >>>> >> >>>> >> > code >>> >>>> >> >>>> >> > - >>> >>>> >> >>>> >> > revisited >>> >>>> >> >>>> >> > To: "MyFaces Development" <[email protected]> >>> >>>> >> >>>> >> > 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 <[email protected]>: >>> >>>> >> >>>> >> > > 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 <[email protected]> >>> >>>> >> >>>> >> > >> >>> >>>> >> >>>> >> > >> 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 >>> >>>> >> >>>> >> > >> <[email protected]> >>> >>>> >> >>>> >> > wrote: >>> >>>> >> >>>> >> > >> >>> >>>> >> >>>> >> > >> > From: Jakob Korherr <[email protected]> >>> >>>> >> >>>> >> > >> > Subject: Re: Use maven-shade-plugin to >>> >>>> >> >>>> >> > prevent duplicate code - >>> >>>> >> >>>> >> > >> > revisited >>> >>>> >> >>>> >> > >> > To: "MyFaces Development" <[email protected]> >>> >>>> >> >>>> >> > >> > 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 <[email protected]>: >>> >>>> >> >>>> >> > >> > > 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 >>> >>>> >> >>>> >> > >> > > <[email protected]>: >>> >>>> >> >>>> >> > >> > >> 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 <[email protected]> >>> >>>> >> >>>> >> > >> > >>> >>> >>>> >> >>>> >> > >> > >>> 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 <[email protected]>: >>> >>>> >> >>>> >> > >> > >>> > 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<[email protected]>: >>> >>>> >> >>>> >> > >> > >>> >>> >>> >>>> >> >>>> >> > >> > >>> >>> 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 >>> >> >>> > >> >> >
