again - i agree with jakob! such an >additional< all-in-one dist won't change the situation for osgi users. (for now) they just have to stick with the current jar files.
@shared: the classes of the shared module would be in the impl. module, if we don’t (have to) share them with other myfaces sub-projects. 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 Jakob Korherr <jakob.korh...@gmail.com> > 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 >
