Hi 2010/11/8 Gerhard <gerhard.petra...@gmail.com>
> hi, > > i didn't talk about copying the code to the impl. module. it would be a > normal module (similar to the shared module) which gets shadded into the > impl. module. > actually both approaches are very similar. so you have the same advantages > (compared to the shared module) and it's easier to handle during the > development process. > > Ok, but if that so, the advantage of the current configuration is we can release shared code without release myfaces core. If we put shared code as a submodule of myfaces core and we need to release tomahawk or orchestra or other project that uses shared code we'll need to release core first. 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 >> >> 2010/11/8 Gerhard <gerhard.petra...@gmail.com> >> >>> 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. >>> >>> >> The advantage of have shared in a separate module is we ensure all shared >> code only depends >> of jsf api. If we put that code inside myfaces impl, we have the risk of >> mix code and then >> well see ClassNotFoundException or things like that when libraries like >> tomahawk or >> in the future portlet bridge are used with mojarra. >> >> 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 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 >>>> >>> >>> >> >
