Why not override the compiler plugin in the module to use JDK 6? I think the whole point about the module is ease of development and this will suffer when putting it in a separate jar.
About the manual classpath scanning or other runtime stuff. This should not break because of JDK 6 stuff, since the bytecode should be backwards compatible. My 2 cents... /JK 2010/3/11 Leonardo Uribe <lu4...@gmail.com> > Hi > > I'm working with jdk 1.5 and when I tried to compile current20 branch I > have an error. This means to create myfaces jars it should be compiled with > jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific > code: > > [INFO] > ------------------------------------------------------------------------ > [ERROR] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Compilation failure > > D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6 > \MyFacesContainerInitializer.java:[47,-1] cannot access > javax.servlet.ServletCon > tainerInitializer > bad class file: C:\Documents and > Settings\lu4242\.m2\repository\javax\javaee-web > > -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class) > > class file has wrong version 50.0, should be 49.0 > > In theory, we can't do this, because if we do, myfaces-impl has one class > jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the practice > this class is not loaded by any part of myfaces, but maybe some program that > tries to scan the classpath and load this class into the classpath will see > the problem. > > My personal opinion is implee6 should have its own separate jar with some > OSGi specific stuff, so if someone wants to use it it should put three jars > on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a lot > of precedences for that kind of stuff (orchestra core and core15 for > example, tomahawk sandbox and sandbox15). > > I also think this code should be moved to myfaces commons, because keep it > as a module in core project means we have to use jdk 1.6 to compile all > artifacts and we have a plugin that checks for jdk 1.5 compatibility that > will fail (see checkJDK profile on myfaces impl pom). > > Suggestions are welcome. > > regards, > > Leonardo Uribe > > > 2010/3/8 Jakob Korherr <jakob.korh...@gmail.com> > >> Hi, >> >> So I committed everything. Please feel free to test it - I am curious >> about your opinions :) >> >> Regards, >> Jakob >> >> 2010/3/8 Jakob Korherr <jakob.korh...@gmail.com> >> >> Hi, >>> >>> Since there don't seem to be any big concerns about this, I will now >>> commit the new submodule "implee6". >>> >>> Regards, >>> Jakob >>> >>> 2010/3/8 Gerhard Petracek <gerhard.petra...@gmail.com> >>> >>> +1 >>>> >>>> regards, >>>> gerhard >>>> >>>> http://www.irian.at >>>> >>>> Your JSF powerhouse - >>>> JSF Consulting, Development and >>>> Courses in English and German >>>> >>>> Professional Support for Apache MyFaces >>>> >>>> >>>> 2010/3/8 Werner Punz <werner.p...@gmail.com> >>>> >>>> +1 for that idea, the less configuration the better. >>>>> >>>>> Werner >>>>> >>>>> >>>>> Am 07.03.10 15:44, schrieb Jakob Korherr: >>>>> >>>>>> I think we don't even need such a parameter, because the idea is that >>>>>> the listener just does nothing if there are already entries for the >>>>>> FacesServlet in web.xml! >>>>>> >>>>>> Regards, >>>>>> Jakob >>>>>> >>>>>> 2010/3/7 Jan-Kees van Andel <jankeesvanan...@gmail.com >>>>>> <mailto:jankeesvanan...@gmail.com>> >>>>>> >>>>>> >>>>>> Agreed, I was only thinking of one parameter: A parameter to turn >>>>>> the entire StartupListener off. >>>>>> >>>>>> I look at it as a binary thing. Either the developer chooses to go >>>>>> with the flow with no custimization, OR he chooses to customize >>>>>> everything. >>>>>> >>>>>> I.e. org.apache.myfaces.DISABLE_FACES_SERVLET_AUTODEPLOY = true >>>>>> (default false) >>>>>> >>>>>> I think this will cover all use cases, where some may require a bit >>>>>> more configuration, but still work... >>>>>> >>>>>> /JK >>>>>> >>>>>> >>>>>> 2010/3/7 Jakob Korherr <jakob.korh...@gmail.com >>>>>> <mailto:jakob.korh...@gmail.com>> >>>>>> >>>>>> >>>>>> Yep! >>>>>> >>>>>> We can discuss this stuff when the submodule is in place. Such >>>>>> things are very easy to change/configure in the >>>>>> StartupListener. >>>>>> >>>>>> However, I think we should come up with a very standard default >>>>>> configuration. If the user wants something different, he will >>>>>> have to configure the mapping himself in the web.xml just as it >>>>>> is now. I am not a fan of too many configuration parameters >>>>>> which interfere with other configuration methods. >>>>>> >>>>>> Regards, >>>>>> Jakob >>>>>> >>>>>> 2010/3/7 Jan-Kees van Andel <jankeesvanan...@gmail.com >>>>>> <mailto:jankeesvanan...@gmail.com>> >>>>>> >>>>>> >>>>>> In other words: Convention over configuration ;-) >>>>>> >>>>>> I just think it's important to pick sensible defaults and >>>>>> to >>>>>> be able to turn it off, for example using a context-param. >>>>>> >>>>>> For example, I think the mapping *.xhtml should also be >>>>>> default, but a developer must be able to turn *.xhtml off, >>>>>> since it's a widely used extension also outside of JSF... >>>>>> >>>>>> Regards, >>>>>> Jan-Kees >>>>>> >>>>>> >>>>>> 2010/3/7 Jakob Korherr <jakob.korh...@gmail.com >>>>>> <mailto:jakob.korh...@gmail.com>> >>>>>> >>>>>> >>>>>> Hi Bernd, >>>>>> >>>>>> For some users it may be so ;) :D >>>>>> >>>>>> Look Bernd, it's not that big thing. It's just a class >>>>>> and a text file. So it is by no means a problem to ship >>>>>> this with MyFaces Core 2. Also Mojarra does something >>>>>> similar too! >>>>>> >>>>>> To your question: Nope! I just add the FacesServlet and >>>>>> the standard mappings /faces/*, *.jsf and maybe also >>>>>> *.faces, if there are no entries for the FacesServlet >>>>>> in >>>>>> the web.xml. If a user wants something special, he do >>>>>> will have to configure it in his web.xml. In this >>>>>> scenario my StartupListener will just do nothing. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Jakob >>>>>> >>>>>> 2010/3/6 Bernd Bohmann <bernd.bohm...@googlemail.com >>>>>> <mailto:bernd.bohm...@googlemail.com>> >>>>>> >>>>>> >>>>>> Hello Jakob, >>>>>> >>>>>> do you really think adding an other dependency is a >>>>>> real problem? >>>>>> How do you configure prefix or suffix mapping? For >>>>>> each possible >>>>>> configuration option an own impl version? >>>>>> >>>>>> Regards >>>>>> >>>>>> Bernd >>>>>> >>>>>> >>>>>> On Sat, Mar 6, 2010 at 4:48 PM, Jakob Korherr >>>>>> <jakob.korh...@gmail.com >>>>>> <mailto:jakob.korh...@gmail.com>> wrote: >>>>>> > Hi Bernd, >>>>>> > >>>>>> > If this module wouldn't be a part of myfaces >>>>>> core, the users still would >>>>>> > have to configure something to run their >>>>>> MyFaces-2 apps in a EE6 container >>>>>> > (e.g. they'd have to include myfaces commons), >>>>>> which is not the target. The >>>>>> > target is to get rid of any unnecessary >>>>>> configuration to make the >>>>>> > development process easier! >>>>>> > >>>>>> > Regards, >>>>>> > Jakob >>>>>> > >>>>>> > 2010/3/6 Bernd Bohmann >>>>>> <bernd.bohm...@googlemail.com >>>>>> <mailto:bernd.bohm...@googlemail.com>> >>>>>> >>>>>> >> >>>>>> >> Hello Jakob, >>>>>> >> >>>>>> >> I'm not really sure that this feature should be >>>>>> part of myfaces-core. >>>>>> >> Maybe myfaces-commons would be a better place. >>>>>> But we can change this >>>>>> >> later. >>>>>> >> >>>>>> >> +1 on commiting the module. >>>>>> >> >>>>>> >> Regards >>>>>> >> >>>>>> >> Bernd >>>>>> >> >>>>>> >> On Sat, Mar 6, 2010 at 4:32 PM, Jakob Korherr >>>>>> <jakob.korh...@gmail.com >>>>>> <mailto:jakob.korh...@gmail.com>> >>>>>> >>>>>> >> wrote: >>>>>> >> > Hi Jan-Kees, >>>>>> >> > >>>>>> >> > Great :) >>>>>> >> > >>>>>> >> > I am currently testing on Tomcat, Jetty, >>>>>> GlassFish v3 and JBoss 6! >>>>>> >> > >>>>>> >> > Regards, >>>>>> >> > Jakob >>>>>> >> > >>>>>> >> > 2010/3/6 Jan-Kees van Andel >>>>>> <jankeesvanan...@gmail.com >>>>>> <mailto:jankeesvanan...@gmail.com>> >>>>>> >>>>>> >> >> >>>>>> >> >> Hey, >>>>>> >> >> >>>>>> >> >> If it works on Jetty and Tomcat, I'd say +1 >>>>>> on committing the module. >>>>>> >> >> >>>>>> >> >> I can't think of big issues with committing >>>>>> it as a separate module. >>>>>> >> >> And >>>>>> >> >> we can always revert if we have to. >>>>>> >> >> >>>>>> >> >> Cool, can't wait to check it out! On what >>>>>> appserver are you testing >>>>>> >> >> this >>>>>> >> >> stuff Jakob? >>>>>> >> >> >>>>>> >> >> Regards, >>>>>> >> >> Jan-Kees >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> 2010/3/6 Jakob Korherr >>>>>> <jakob.korh...@gmail.com >>>>>> <mailto:jakob.korh...@gmail.com>> >>>>>> >>>>>> >> >>> >>>>>> >> >>> Hi guys, >>>>>> >> >>> >>>>>> >> >>> I managed to introduce the core submodule >>>>>> "implee6" on my local >>>>>> >> >>> machine. >>>>>> >> >>> This new submodule includes Java EE 6 >>>>>> dependencies and thus you can >>>>>> >> >>> use >>>>>> >> >>> Servlet API 3.0 and other new things in it. >>>>>> >> >>> >>>>>> >> >>> When building MyFaces, this new submodule >>>>>> is >>>>>> built before the normal >>>>>> >> >>> impl >>>>>> >> >>> submodule. Then the .class and the .java >>>>>> files are "injected" into the >>>>>> >> >>> impl-build. This is very similar to how >>>>>> shared_impl is included in the >>>>>> >> >>> myfaces-impl build at the moment, but >>>>>> without recompilation. >>>>>> >> >>> >>>>>> >> >>> In this way we are able to use the new >>>>>> services approach of Java EE 6 >>>>>> >> >>> to >>>>>> >> >>> get rid of the Faces Servlet entries in >>>>>> web.xml, because in any Java >>>>>> >> >>> EE 6 >>>>>> >> >>> container we can configure this dynamically >>>>>> at startup (see >>>>>> >> >>> MYFACES-2579 for >>>>>> >> >>> details). This also works fantastically on >>>>>> my local machine - it's >>>>>> >> >>> really >>>>>> >> >>> cool! >>>>>> >> >>> >>>>>> >> >>> Also with this method we are still Java EE >>>>>> 5 >>>>>> complaint, because the EE >>>>>> >> >>> 6 >>>>>> >> >>> classes just won't get loaded in a non EE 6 >>>>>> environment, because there >>>>>> >> >>> are >>>>>> >> >>> no dependencies from impl or shared to >>>>>> them. >>>>>> They are only called (and >>>>>> >> >>> loaded) by a Java EE 6 container via the >>>>>> services definition. >>>>>> >> >>> >>>>>> >> >>> Furthermore I noticed that the Mojarra guys >>>>>> also include a similar >>>>>> >> >>> solution to this in their newest build! >>>>>> >> >>> >>>>>> >> >>> Now, before I commit something of this, I >>>>>> wanted to ask if there are >>>>>> >> >>> any >>>>>> >> >>> objections with this proposal. If so, >>>>>> please >>>>>> tell me your concerns! >>>>>> >> >>> >>>>>> >> >>> Regards, >>>>>> >> >>> Jakob >>>>>> >> >> >>>>>> >> > >>>>>> >> > >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >
