ICEfaces
  1. ICEfaces
  2. ICE-3199

Using command-line switches with sample app. ant build scripts doesn't remove libraries when it should.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.7
    • Fix Version/s: 1.8DR#2
    • Component/s: Release
    • Labels:
      None
    • Environment:
      All
    • Affects:
      Sample App./Tutorial

      Description

      When using the sample app ant build scripts, specifying both a target (e.g. "tomcat6.0') and a command-line switch (e.g. '-Dmyfaces=""') will result in all the libraries specified by both the target and the switch being added to the resulting .war file. The problem is that for certain switches, such as '-Dmyfaces=""', the default JSF runtime libs defined by the build targets should not be included and the MyFaces runtime libs should be used instead.

      Related to ICE-3197.

        Activity

        Hide
        Jim Zhang added a comment -

        The target "build.myfaces.war" in build-common provides the function to build war file for myfaces version. It is available for use at any level in Samples. As I remember, there was a discussion about myfaces issue. We do not support jsf1.2 with myfaces yet. So the default server for the war file is Tomcat 5.x. The war file for myfaces version from the most current trunk works fine with Tomcat 5.5

        Show
        Jim Zhang added a comment - The target "build.myfaces.war" in build-common provides the function to build war file for myfaces version. It is available for use at any level in Samples. As I remember, there was a discussion about myfaces issue. We do not support jsf1.2 with myfaces yet. So the default server for the war file is Tomcat 5.x. The war file for myfaces version from the most current trunk works fine with Tomcat 5.5
        Hide
        Jim Zhang added a comment -

        The target "myfaces" was dedicated for war files built for myfaces applications.

        Show
        Jim Zhang added a comment - The target "myfaces" was dedicated for war files built for myfaces applications.
        Hide
        Ken Fyten added a comment -

        I guess we have two options then:

        1. Add new targets for MyFaces (1.1 and App. Server combinations
        2. Make the build smart enough to adapt properly when the -Dmyfaces="" switch is used in conjunction with the existing build targets (basically substitute the sun JSF RI jars with the MyFaces ones).

        Thoughts?

        Show
        Ken Fyten added a comment - I guess we have two options then: 1. Add new targets for MyFaces (1.1 and App. Server combinations 2. Make the build smart enough to adapt properly when the -Dmyfaces="" switch is used in conjunction with the existing build targets (basically substitute the sun JSF RI jars with the MyFaces ones). Thoughts?
        Hide
        Jim Zhang added a comment -

        Markup switches with targets maybe a better option. As we discussed a year ago, building targets to markup switches was one of goals to improve build functionality and feasibility.

        For myfaces, myfaces applications have no conjunction to JSF RI jars in compiling time and deploying time. A new target, "myface", may be good to use to build all myfaces war files.

        Show
        Jim Zhang added a comment - Markup switches with targets maybe a better option. As we discussed a year ago, building targets to markup switches was one of goals to improve build functionality and feasibility. For myfaces, myfaces applications have no conjunction to JSF RI jars in compiling time and deploying time. A new target, "myface", may be good to use to build all myfaces war files.
        Hide
        Jim Zhang added a comment -

        A new target was created with the name "myfaces" in build-common.

        For developers, the build script became a bit smarter to adapt switch -Dmyfaces="" so that "tomcat" server targets and switch -Dmyfaces="" could be combined together.

        Show
        Jim Zhang added a comment - A new target was created with the name "myfaces" in build-common. For developers, the build script became a bit smarter to adapt switch -Dmyfaces="" so that "tomcat" server targets and switch -Dmyfaces="" could be combined together.
        Hide
        Joanne Bai added a comment -

        We know that the resulting build should either have jsf-api.jar and jsf-impl.jar (1.2 version) in the case of JSF testing, or myfaces-api.jar and myfaces-impl.jar in the case of MyFaces testing.

        My question is if the JSF-1.2 libs are removed, should MyFaces still suppose to work on tomcat 6, or we expect MyFaces to only work on Tomcat 5?

        Show
        Joanne Bai added a comment - We know that the resulting build should either have jsf-api.jar and jsf-impl.jar (1.2 version) in the case of JSF testing, or myfaces-api.jar and myfaces-impl.jar in the case of MyFaces testing. My question is if the JSF-1.2 libs are removed, should MyFaces still suppose to work on tomcat 6, or we expect MyFaces to only work on Tomcat 5?

          People

          • Assignee:
            Jim Zhang
            Reporter:
            yip.ng
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: