[
https://issues.apache.org/jira/browse/ORCHESTRA-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786455#action_12786455
]
Bernhard Huemer commented on ORCHESTRA-45:
------------------------------------------
Unfortunately I'm not really experienced regarding JSF 2.0, but are those
decorators really the only thing that you have to change in order to make
Orchestra JSF 2.0 compatible? I'm just wondering, because that means that
there's only a set of like three or four classes that demands the introduction
of another branch? That looks like there's going to be a lot of redundant work
in the future then if both versions will be maintained, isn't it? Even though
this issue has already been marked as resolved, I'd hence like to propose a
different solution (btw. I couldn't manage to find the discussion thread on the
MyFaces mailing list? - otherwise I would have proposed it there).
Apparently the problem is that if we want to support both, JSF 1.x and JSF 2.0
at once, we'll have to provide two different sets of decorators, one set that
implements / extends the JSF 1.x API and one set that implements the JSF 2.0
API. The compiler can't differ between those different versions and thus the
whole project has to stick to a certain version. However, to be more specific,
a single compiler configuration can't differ between different versions,
multiple compiler configurations in fact can! Unfortunately Maven doesn't
really support the usage of multiple compiler configurations, but I've already
managed to implement something similar. Basically we would have to write a
custom CompilerMojo that lets you configure the compile classpath to use for a
certain source folder. At runtime Orchestra would have to determine the current
JSF version (which is really easy to do) and depending on this version number
it would choose the set of decorators to use. For example, the project layout
could as a result of that look like the following:
- src\main\java - Common code for all JSF versions (even though it's called
common, it compiles against the JSF 2.0 API)
- src\main\jsf1x - JSF 1.x specific code (i.e. JSF 1.x specific decorators)
- src\main\jsf20 - JSF 2.0 specific code (i.e. JSF 2.0 specific decorators)
Basically it's as if we introduced three different modules, orchestra-common,
orchestra-jsf1x and orchestra-jsf20, but it's still just a single Maven module.
Of course, this solutions has got some drawbacks as well, as it will definitely
confuse IDEs, i.e. you'll end up with several error messages that the IDE
complains about even though it actually compiles without any errors at all.
Just let me know, what you think about it. :-)
> Support for JSF 2.0
> -------------------
>
> Key: ORCHESTRA-45
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-45
> Project: MyFaces Orchestra
> Issue Type: Improvement
> Components: FrameworkAdapter
> Affects Versions: 1.3.1
> Reporter: Martin Marinschek
> Assignee: Leonardo Uribe
> Fix For: 1.4
>
> Attachments: jsf20upgrade.patch
>
>
> Orchestra should support JSF 2.0. The supplied patch changes the decorators
> in Orchestra to allow this, however, the patch is not backwards compatible
> with the 1.2/1.1 version (and contrary to supporting both 1.1 and 1.2 in one
> version, this is not possible with 2.0 anymore, as the interfaces have new
> methods which in turn have parameters/return types which are only available
> in JSF 2.0). The question will be how we will be able to continue. I see two
> options:
> a) a branch, and two independent releases
> b) adding a common JSF 1.2 compatibility library, which would allow to a
> certain extent to mimick basic JSF 2.0 infrastructure (it would not try to
> reimplement features from 2.0, however)
> I will also post this question to the MyFaces mailing-list, and we will see
> how to proceed from here.
> regards,
> Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
