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