ICEfaces
  1. ICEfaces
  2. ICE-6118

Enhance build scripts to allow for compiling and building libraries and samples against MyFaces

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-2.0.0.GA, 2.0.2
    • Fix Version/s: 2.1-Beta2, 3.0
    • Component/s: Release
    • Labels:
      None
    • Environment:
      ICEfaces 2.1, MyFaces 2.1
    • Affects:
      Compatibility/Configuration

      Description


      Sample applications can be built with

      ant -Dmyfaces=""

        Issue Links

          Activity

          Hide
          Ted Goddard added a comment -

          This does not cover building icefaces.jar against MyFaces 2.0 (this is not necessary at this time since the JSF API is fully specified).

          Show
          Ted Goddard added a comment - This does not cover building icefaces.jar against MyFaces 2.0 (this is not necessary at this time since the JSF API is fully specified).
          Hide
          Ted Goddard added a comment -

          icefaces/lib/myfaces should contain:

          commons-beanutils-1.8.3.jar
          commons-codec-1.4.jar
          commons-digester-2.1.jar
          commons-discovery-0.4.jar
          commons-logging-1.1.1.jar
          myfaces-api-2.0.3-20101004.210838-10.jar (or newer)
          myfaces-impl-2.0.3-20101004.041228-7.jar (or newer)

          Show
          Ted Goddard added a comment - icefaces/lib/myfaces should contain: commons-beanutils-1.8.3.jar commons-codec-1.4.jar commons-digester-2.1.jar commons-discovery-0.4.jar commons-logging-1.1.1.jar myfaces-api-2.0.3-20101004.210838-10.jar (or newer) myfaces-impl-2.0.3-20101004.041228-7.jar (or newer)
          Hide
          Deryk Sinotte added a comment -

          Changes have been checked in to support compiling and building the various areas of ICEfaces (core, components, samples) against MyFaces 2.1.x.

          We're currently running against a snapshot build of MyFaces 2.1.2 because it contains two fixes we require to have any success running at all:

          https://issues.apache.org/jira/browse/MYFACES-3178
          https://issues.apache.org/jira/browse/MYFACES-3179

          There may also be outstanding work required on some of the metadata generation for tooling since it's relying on Mojarra-specific files and file locations.

          Show
          Deryk Sinotte added a comment - Changes have been checked in to support compiling and building the various areas of ICEfaces (core, components, samples) against MyFaces 2.1.x. We're currently running against a snapshot build of MyFaces 2.1.2 because it contains two fixes we require to have any success running at all: https://issues.apache.org/jira/browse/MYFACES-3178 https://issues.apache.org/jira/browse/MYFACES-3179 There may also be outstanding work required on some of the metadata generation for tooling since it's relying on Mojarra-specific files and file locations.
          Hide
          Deryk Sinotte added a comment -

          Re-opening and assigning to Ken for delegation to the ACE comps team.

          There was a change made to org.icefaces.ace.generator.artifacts.ComponentHandlerArtifact in r24852 to allow the generated components to properly import the MethodRule implementation for the JSF library being used (Mojarra vs MyFaces).

          Although this allows compilation to succeed, it poses an issue for distributing the library as it will only work against the JSF implemenation it was compiled against. The goal is to have a single library that works across both JSF distributions. The options are in order of preference are:

          1) To adjust the components and code generator so that it require us to output implementation specific imports and classes. This means removing our dependency on the following by strictly using only public JSF API classes and methods.

          import com.sun.faces.facelets.tag.MethodRule
          import org.apache.myfaces.view.facelets.tag.MethodRule

          2) Writing our own wrapper/factory style code that is smart enough to handle both implementations without having to compile and distribute separate libraries.

          Show
          Deryk Sinotte added a comment - Re-opening and assigning to Ken for delegation to the ACE comps team. There was a change made to org.icefaces.ace.generator.artifacts.ComponentHandlerArtifact in r24852 to allow the generated components to properly import the MethodRule implementation for the JSF library being used (Mojarra vs MyFaces). Although this allows compilation to succeed, it poses an issue for distributing the library as it will only work against the JSF implemenation it was compiled against. The goal is to have a single library that works across both JSF distributions. The options are in order of preference are: 1) To adjust the components and code generator so that it require us to output implementation specific imports and classes. This means removing our dependency on the following by strictly using only public JSF API classes and methods. import com.sun.faces.facelets.tag.MethodRule import org.apache.myfaces.view.facelets.tag.MethodRule 2) Writing our own wrapper/factory style code that is smart enough to handle both implementations without having to compile and distribute separate libraries.
          Hide
          Mark Collette added a comment -

          Switched from the build-time autodetect mechanism to using the ACE helper class, so that we're agnostic to whether we're running in Mojarra, MyFaces and anything else.

          Development branch
          Subversion 26214
          ace/generator/src/org/icefaces/ace/generator/artifacts/ComponentHandlerArtifact.java

          Show
          Mark Collette added a comment - Switched from the build-time autodetect mechanism to using the ACE helper class, so that we're agnostic to whether we're running in Mojarra, MyFaces and anything else. Development branch Subversion 26214 ace/generator/src/org/icefaces/ace/generator/artifacts/ComponentHandlerArtifact.java

            People

            • Assignee:
              Mark Collette
              Reporter:
              Ted Goddard
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: