Hi, IMHO shared code ist just as private as myfaces-impl code. Not more, not less.
Adding the all-in-one-jar is not a change, but an improvement. It is just an additional (non-OSGi-ready) distribution form of MyFaces code and thus does not affect the problems we're having with myfaces-shared and OSGi. Regards, Jakob 2010/11/8 Leonardo Uribe <lu4...@gmail.com>: > Hi > > 2010/11/8 Jakob Korherr <jakob.korh...@gmail.com> >> >> Hi, >> >> Last week I created a branch (see [1]) to test the shade module >> integration of shared and also implee6 for MyFaces core. >> Coincidentally, Leonardo committed a similar solution to MyFaces core >> trunk, however only for the implee6 integration. >> >> The branch at [1] uses the shade plugin to include shared and implee6. >> For shared it uses a dependency to myfaces-shared-core (NOT >> shared-impl), which will then be shaded to org.apache.myfaces.* >> (without the shared-package) - however this is only a prototype. To >> make this work I had to rename all imports in myfaces-impl from >> "shared_impl" to "shared". Everything works pretty well expect for the >> OSGi-issues mentioned by Leonardo. >> >> Using this branch you are able to work on MyFaces shared classes in >> the context of MyFaces core and not having to do a whole maven build >> when testing it, because your IDE uses shared directly as a >> dependency. Thus it really is an improvement to what we have now and >> we should try to fix the OSGi issues in some way to really make this >> work. I already did some work in this direction and I think that a >> ResourceTransformer implementation for shade that creates the Manifest >> file for OSGi is the way to go, but we certainly have to discuss this >> (maybe also with the bundle-plugin team). WDYT Leo? >> > > Well, before try to do something like that (a ResourceTransformer > implementation) > it is good to ask if it is really necessary to do that. On a previous mail I > said that > "shared" code should be private, so there should not be used for users > outside > myfaces impl. There are exceptions (DelegateServlet), so we have to identify > first > which code could not be relocated. The effect on maven bundle plugin is > shared packages are excluded from Export-Package header, but as long as > users > don't have code importing shared_impl package it is ok to ignore this side > effect. > >> >> However, please take a look at the branch at [1] and try to use it in >> your IDE - I think it's really great! (... and furthermore I think >> it's much easier to understand for every myfaces-developer). >> >> >> I also totally agree with Gerhard that we should provide this >> all-in-one jar, even if it may cause problems in OSGi, because our >> OSGi users will most certainly know that. It's really easy to do this >> using the shade plugin and it provides a very convenient way for >> developers to use MyFaces (especially when they're not using maven). >> As Gerhard mentioned, Mojarra will do the same and furthermore other >> projects like e.g. Weld also provide this all-in-one solution (--> >> weld-servlet). >> > > I disagree. Our first priority should be myfaces usage in different > environments, > and then enhance IDE support. Only if the two previous objections can be > solved, > the change can be made. > > regards, > > Leonardo Uribe > >> >> Regards, >> Jakob >> >> [1] >> http://svn.apache.org/repos/asf/myfaces/core/branches/2_0_3_snapshot_shade_test/ >> >> 2010/11/8 Leonardo Uribe <lu4...@gmail.com>: >> > Hi >> > >> > 2010/11/8 Gerhard <gerhard.petra...@gmail.com> >> >> >> >> hi, >> >> @ide-support: >> >> since you get an additional all-in-one sources jar file, it should >> >> work. >> >> i've created external codi examples which use the all-in-one jar of >> >> codi >> >> and the ide support works perfectly. >> > >> > Yes, that's true (I checked that code) but in shared you need to change >> > the >> > package name to org.apache.myfaces.shared_impl. >> > >> > Really that package renaming is questionable. Why? It exists since 1.1.x >> > but >> > I don't know why this is necessary. In theory, the code inside shared >> > should >> > be "private", but the truth is we have one class that could be consumed >> > by >> > users: >> > org.apache.myfaces.shared_impl.webapp.webxml.DelegatedFacesServlet. >> > That is the main reason why I moved the code proposed on >> > https://issues.apache.org/jira/browse/MYFACES-2944 to myfaces-impl >> > package. >> > >> >> >> >> @osgi: >> >> if there are restrictions, we should improve the shade plugin. >> >> (for now: osgi users just can't use this optional all-in-one jar file - >> >> if >> >> we document it, it shouldn't be a problem.) >> > >> > There is a discussion of this issue here: >> > >> > https://issues.apache.org/jira/browse/FELIX-1184 >> > >> > It was reported here too: >> > >> > http://jira.codehaus.org/browse/MSHADE-51 >> > >> > The issue in maven is here: >> > >> > http://jira.codehaus.org/browse/MNG-2258 >> > >> > Unfortunately, the only hack I can see to make this work correctly is >> > create >> > a plugin with a maven lifecycle extension, and do that is very nasty, >> > because we need to create a plugin just to do that. >> > >> >> >> >> @use-case: >> >> we should really get rid of the shared module. >> > >> > I agree. First we need a more explicit plan to do it. Suggestions are >> > welcome. >> > >> > regards, >> > >> > Leonardo Uribe >> > >> >> >> >> regards, >> >> gerhard >> >> http://www.irian.at >> >> >> >> Your JSF powerhouse - >> >> JSF Consulting, Development and >> >> Courses in English and German >> >> >> >> Professional Support for Apache MyFaces >> >> >> >> >> >> >> >> 2010/11/8 Leonardo Uribe <lu4...@gmail.com> >> >>> >> >>> Hi >> >>> >> >>> Unfortunately, maven-shade-plugin has some unwanted side effects. >> >>> >> >>> - The source jar file is not updated too, so if we "shade" shared, the >> >>> sources are not updated. In theory, the source jar is used by IDEs >> >>> like >> >>> Eclipse or Netbeans to show the source file of a .class. >> >>> - It does not play well with osgi bundle plugin (the one that create >> >>> manifest.mf). The problem is the manifest is generated before "shade", >> >>> and >> >>> we need the later. Really that one is a problem related to maven >> >>> itself. >> >>> >> >>> The only valid use case I found where maven-shade-plugin fits well is >> >>> with implee6 module, but anyway it was required to do some hacks to >> >>> make >> >>> bundle plugin works well. >> >>> >> >>> regards, >> >>> >> >>> Leonardo Uribe >> >> >> > >> > >> >> >> >> -- >> 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
