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]
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
Hi
I have sended an email to jsr-314-open mail list just to confirm if it is
valid or not to do this kind of stuff. The problem is the class involved on
implee6 has dependencies with classes that needs JDK 6 to be compiled, so in
a JDK 1.5 environment it will crash if the classes are loaded. It
Hi,
I totally agree with Jan-Kees. Just override the compiler plugin in implee6
to use jdk 6!
Also I really don't see why you think it is such a big problem to have a
class in the jar file which has other dependencies and another version when
no other class has any relations to it. It's like a
Hi
2010/3/11 Jakob Korherr jakob.korh...@gmail.com
Hi,
I totally agree with Jan-Kees. Just override the compiler plugin in implee6
to use jdk 6!
Also I really don't see why you think it is such a big problem to have a
class in the jar file which has other dependencies and another version
I agree with Leonardo that changes which affect our base requirements
(jdk 6 instead of jdk 5) and which could compromise our certification
warrant discussion rather than a commit-and-hope-no-one-complains
attitude.
Otherwise, without discussion, how would we know that Mojarra allows it?
On Thu,
Hi
Try this one:
http://repo2.maven.org/maven2/org/mortbay/jetty/servlet-api/3.0.20100224/
It does not seem to have jdk 1.6 dependencies
regards,
Leonardo Uribe
2010/3/11 Jakob Korherr jakob.korh...@gmail.com
Maybe we can use a dependency to Servlet API 3.0 which is compiled against
JDK
Hi
It seems the problem is that servlet 3.0 api requires jdk 1.6 to compile,
and the classes we are using on implee6 has dependencies. That means, the
classes on implee6 has version 49 but the ones in servlet 3.0 has version
50. The ones here:
+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,
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
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
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
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
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
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.
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
Agreed, I was only thinking of one parameter: A parameter to
+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
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
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
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
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
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 wrote:
Hi Jan-Kees,
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
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 wrote:
Hi Bernd,
If
23 matches
Mail list logo
