Issue Details (XML | Word | Printable)

Key: SHALE-258
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Craig McClanahan
Reporter: Paul Spencer
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Shale

Shale core and test framework 1.0.3 includes MyFaces 1.1.1

Created: 21/Aug/06 01:21 PM   Updated: 23/Jan/07 04:40 PM
Return to search
Component/s: Core, Test
Affects Version/s: 1.0.3, 1.0.3-SNAPSHOT
Fix Version/s: 1.0.4

Flags: Important


 Description  « Hide
Shale's core and test framwork includes MyFaces 1.1.1 in the classpath when testing via Maven. The testing framework should not impose the JSF implementation on
what is being tested.

A related issue was reported, and fixed, in MyFaces. See http://issues.apache.org/jira/browse/TOMAHAWK-612



 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Craig McClanahan added a comment - 21/Aug/06 05:33 PM
I presume we mean that the testing framework should *not* impose the JSF implementation on what is being tested, right? :-)

Paul Spencer added a comment - 21/Aug/06 06:40 PM
Correct "type-o" in description. The second sentence should have read "The testing framework should not impose the JSF implementation on
what is being tested." The word "not" was left out.

Thanks to Craig McClanahan for pointing out the error.

Paul Spencer made changes - 21/Aug/06 06:40 PM
Field Original Value New Value
Description Shale's test framwork includes MyFaces 1.1.1 in the classpath when testing via Maven. The testing framework should impose the JSF implementation on
what is being tested.

A related issue was reported, and fixed, in MyFaces. See http://issues.apache.org/jira/browse/TOMAHAWK-612

Shale's test framwork includes MyFaces 1.1.1 in the classpath when testing via Maven. The testing framework should not impose the JSF implementation on
what is being tested.

A related issue was reported, and fixed, in MyFaces. See http://issues.apache.org/jira/browse/TOMAHAWK-612

Paul Spencer added a comment - 23/Aug/06 06:11 PM
This affects maven users. Based on that I would suggest status be raised to blocker or critical

Paul Spencer made changes - 23/Aug/06 06:11 PM
Summary Shale test framework 1.0.3 includes MyFaces 1.1.1 Shale core and test framework 1.0.3 includes MyFaces 1.1.1
Description Shale's test framwork includes MyFaces 1.1.1 in the classpath when testing via Maven. The testing framework should not impose the JSF implementation on
what is being tested.

A related issue was reported, and fixed, in MyFaces. See http://issues.apache.org/jira/browse/TOMAHAWK-612

Shale's core and test framwork includes MyFaces 1.1.1 in the classpath when testing via Maven. The testing framework should not impose the JSF implementation on
what is being tested.

A related issue was reported, and fixed, in MyFaces. See http://issues.apache.org/jira/browse/TOMAHAWK-612

Component/s Core [ 21250 ]
Wendy Smoak added a comment - 24/Aug/06 11:54 PM

To avoid enforcing the choice of JSF implementation on users, all of the JSF api and impl dependencies should be marked 'provided'.

Since these definitions are in the shale-parent pom, this issue affects all of the Shale jars.

This will be addressed as part of a larger effort that will also fix the dependencies for the webapps and work around some issues with Maven's dependency resolution.

Users can work around this issue in Shale 1.0.3 by using <exclusions> in their own project poms.

Wendy Smoak made changes - 12/Sep/06 04:21 PM
Affects Version/s 1.0.3 [ 21750 ]
Fix Version/s 1.0.4-SNAPSHOT [ 21740 ]
Repository Revision Date User Message
ASF #443256 Thu Sep 14 06:16:55 UTC 2006 craigmcc Implement a fairly massive refactoring of our Maven2 build dependencies,
and (along the way) address the issues raised by SHALE-258 (although
they are probably not completely covered yet). Highlights of the
changes:

* Dependencies to compile the Shale Framework libraries have been
  adjusted to always use the MyFaces API jar (it should not matter
  which implementation is used to compile against, because the signature
  tests in the TCK will ensure method signature compatibility).

* Migrate as many dependency version numbers as possible into the
  <dependencyManagement> section of the shale-parent POM, along with
  exclusions that avoid adding optional dependencies to the classpath.

* Move the profile stuff about choosing MyFaces or the JSF RI into the
  shale-apps-parent POM, instead of shale-parent, since this now only
  affects webapps.

* There is a wierd test failure on the shale-clay unit tests that I
  could not figure out, so I commented out those test cases for now.
  Gary, could you take a look at CommentTestCase?

* There is some really wierd Maven2 behavior related to exclusions
  in the dependency management section of shale-parent that I don't
  understand yet ... Maven mavens please review1! For example, I
  would like to exclude commons-digester from the myfaces:myfaces-api
  dependency, so that a framework library that happens to need
  the JSF APIs won't also be able to use Digester APIs without
  explicitly declaring a dependency on commons-digester. For some
  reason, doing this prevents the explicit dependency from being
  recognized. Strange ...

* At this point, all the unit and system integration tests run
  (and they will in the sandbox once I do a parallel commit there
  to account for the changes), but I haven't done any thorough
  testing to gauge impacts of these changes. But, the advertised
  dependencies seem to be much closer to the minimal required set.
Files Changed
MODIFY /shale/framework/trunk/shale-tiles/pom.xml
MODIFY /shale/framework/trunk/shale-spring/pom.xml
MODIFY /shale/framework/trunk/shale-clay/src/test/java/org/apache/shale/clay/config/CommentTestCase.java
MODIFY /shale/framework/trunk/pom.xml
MODIFY /shale/framework/trunk/shale-core/pom.xml
MODIFY /shale/framework/trunk/shale-clay/pom.xml
MODIFY /shale/framework/trunk/shale-apps/pom.xml
MODIFY /shale/framework/trunk/shale-test/pom.xml
MODIFY /shale/framework/trunk/shale-remoting/pom.xml
MODIFY /shale/framework/trunk/shale-tiger/pom.xml

Craig McClanahan added a comment - 14/Sep/06 06:17 AM
As of the 20060914 nightly build (and corresponding updated 1.0.4-SNAPSHOT), I have completed a first pass at refactoring our build process to address these dependency issues. Now, building the Shale Framework libraries depends on the MyFaces API jar, but when you build an application you still get the choice of which implementation to use. As a side effect, the framework library POMs (including shale-core and shale-test) should no longer force you to use the JSF implementation that they were built against.

Leaving the issue open for the moment, because it is very likely I've missed some details along the way.

Craig McClanahan made changes - 14/Sep/06 06:18 AM
Assignee Craig McClanahan [ craigmcc ]
Craig McClanahan added a comment - 15/Sep/06 11:13 PM
The shale-core and shale-test modules (and others) now declare a "provided" dependency on the MyFaces API jar (because they need JSF APIs in order to compile), but this will not translate into a runtime dependency on this particular version.

Craig McClanahan made changes - 15/Sep/06 11:13 PM
Status Open [ 1 ] Resolved [ 5 ]
Resolution Fixed [ 1 ]
Rahul Akolkar made changes - 23/Jan/07 04:40 PM
Fix Version/s 1.0.4-SNAPSHOT [ 21740 ]
Fix Version/s 1.0.4 [ 21790 ]
Jeff Turner made changes - 09/Aug/07 07:17 AM
Workflow Struts [ 38652 ] Struts - editable closed status [ 42416 ]
Antonio Petrelli made changes - 08/Jan/09 08:57 AM
Workflow Struts - editable closed status [ 42416 ] Struts - editable closed status (temporary) [ 46310 ]
Antonio Petrelli made changes - 08/Jan/09 09:08 AM
Workflow Struts - editable closed status (temporary) [ 46310 ] Struts - editable closed status [ 52943 ]