You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shale.apache.org by Gary VanMatre <gv...@comcast.net> on 2006/09/14 18:44:41 UTC
Re: svn commit: r443256 - in /shale/framework/trunk: ./ shale-apps/ shale-clay/ shale-clay/src/test/java/org/apache/shale/clay/config/ shale-core/ shale-remoting/ shale-spring/ shale-test/ shale-tiger/ shale-tiles/
>From: craigmcc@apache.org
>
> Author: craigmcc
> Date: Wed Sep 13 23:16:55 2006
> New Revision: 443256
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=443256
> Log:
> 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
> 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?
>
This test is building the component tree and rendering the output.
The output is parsed and checked for an embed comment.
Since the myfaces-impl is not a dependency, the renderers are
not being loaded and no markup generated.
I could create some mock renderers for this test. That would be
much easier than starting a wrestling match with maven.
Gary
Re: svn commit: r443256 - in /shale/framework/trunk: ./ shale-apps/ shale-clay/ shale-clay/src/test/java/org/apache/shale/clay/config/ shale-core/ shale-remoting/ shale-spring/ shale-test/ shale-tiger/ shale-tiles/
Posted by Craig McClanahan <cr...@apache.org>.
On 9/14/06, Gary VanMatre <gv...@comcast.net> wrote:
>
> >From: craigmcc@apache.org
> >
> > Author: craigmcc
> > Date: Wed Sep 13 23:16:55 2006
> > New Revision: 443256
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=443256
> > Log:
> > 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
> > 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?
> >
>
> This test is building the component tree and rendering the output.
> The output is parsed and checked for an embed comment.
> Since the myfaces-impl is not a dependency, the renderers are
> not being loaded and no markup generated.
Ah ... that makes sense.
I could create some mock renderers for this test. That would be
> much easier than starting a wrestling match with maven.
That definitely sounds like a good plan.
Gary
>
Craig
Re: svn commit: r443256 - in /shale/framework/trunk: ./ shale-apps/ shale-clay/ shale-clay/src/test/java/org/apache/shale/clay/config/ shale-core/ shale-remoting/ shale-spring/ shale-test/ shale-tiger/ shale-tiles/
Posted by Mike Kienenberger <mk...@gmail.com>.
I'd use 1.1.4 since Wendy has it all-but-out-the-door at this point :-)
On 9/14/06, Paul Spencer <pa...@apache.org> wrote:
> Which version of MyFaces should be used for testing, 1.1.1 or 1.1.3?
>
> A note needs to be added in the "release procedure" to update the
> MyFaces version number when appropriate.
>
> Paul Spencer
>
>
> Wendy Smoak wrote:
> > On 9/14/06, Gary VanMatre <gv...@comcast.net> wrote:
> >
> >> This test is building the component tree and rendering the output.
> >> The output is parsed and checked for an embed comment.
> >> Since the myfaces-impl is not a dependency, the renderers are
> >> not being loaded and no markup generated.
> >>
> >> I could create some mock renderers for this test. That would be
> >> much easier than starting a wrestling match with maven.
> >
> > Gary, if it's easier, you can add myfaces-impl as a dependency in test
> > scope. That won't affect projects using Clay, it will only be on the
> > classpath during the test phases.
> >
> > <dependency>
> > <groupId>myfaces</groupId>
> > <artifactId>myfaces-impl</artifactId>
> > <version>1.1.1</version>
> > <scope>test</scope>
> > </dependency>
> >
>
>
Re: svn commit: r443256 - in /shale/framework/trunk: ./ shale-apps/ shale-clay/ shale-clay/src/test/java/org/apache/shale/clay/config/ shale-core/ shale-remoting/ shale-spring/ shale-test/ shale-tiger/ shale-tiles/
Posted by Craig McClanahan <cr...@apache.org>.
On 9/14/06, Paul Spencer <pa...@apache.org> wrote:
>
> Which version of MyFaces should be used for testing, 1.1.1 or 1.1.3?
My understanding was that 1.1.3 had some fatal bugs, so I've been sticking
with 1.1.1 until 1.1.4 finally gets out the door.
A note needs to be added in the "release procedure" to update the
> MyFaces version number when appropriate.
Yah ... it won't be just tweaking the version numbers, either. It seems
prudent to go in and examine the transitive dependencies hierarchy again
when you change the version on something with this many dependencies of its
own, to make sure that the exclude lists are correct. That was a *real*
pain with the refactoring I did last night.
Paul Spencer
Craig
Wendy Smoak wrote:
> > On 9/14/06, Gary VanMatre <gv...@comcast.net> wrote:
> >
> >> This test is building the component tree and rendering the output.
> >> The output is parsed and checked for an embed comment.
> >> Since the myfaces-impl is not a dependency, the renderers are
> >> not being loaded and no markup generated.
> >>
> >> I could create some mock renderers for this test. That would be
> >> much easier than starting a wrestling match with maven.
> >
> > Gary, if it's easier, you can add myfaces-impl as a dependency in test
> > scope. That won't affect projects using Clay, it will only be on the
> > classpath during the test phases.
> >
> > <dependency>
> > <groupId>myfaces</groupId>
> > <artifactId>myfaces-impl</artifactId>
> > <version>1.1.1</version>
> > <scope>test</scope>
> > </dependency>
> >
>
>
Re: svn commit: r443256 - in /shale/framework/trunk: ./ shale-apps/
shale-clay/ shale-clay/src/test/java/org/apache/shale/clay/config/ shale-core/
shale-remoting/ shale-spring/ shale-test/ shale-tiger/ shale-tiles/
Posted by Paul Spencer <pa...@apache.org>.
Which version of MyFaces should be used for testing, 1.1.1 or 1.1.3?
A note needs to be added in the "release procedure" to update the
MyFaces version number when appropriate.
Paul Spencer
Wendy Smoak wrote:
> On 9/14/06, Gary VanMatre <gv...@comcast.net> wrote:
>
>> This test is building the component tree and rendering the output.
>> The output is parsed and checked for an embed comment.
>> Since the myfaces-impl is not a dependency, the renderers are
>> not being loaded and no markup generated.
>>
>> I could create some mock renderers for this test. That would be
>> much easier than starting a wrestling match with maven.
>
> Gary, if it's easier, you can add myfaces-impl as a dependency in test
> scope. That won't affect projects using Clay, it will only be on the
> classpath during the test phases.
>
> <dependency>
> <groupId>myfaces</groupId>
> <artifactId>myfaces-impl</artifactId>
> <version>1.1.1</version>
> <scope>test</scope>
> </dependency>
>
Re: svn commit: r443256 - in /shale/framework/trunk: ./ shale-apps/ shale-clay/ shale-clay/src/test/java/org/apache/shale/clay/config/ shale-core/ shale-remoting/ shale-spring/ shale-test/ shale-tiger/ shale-tiles/
Posted by Wendy Smoak <ws...@gmail.com>.
On 9/14/06, Gary VanMatre <gv...@comcast.net> wrote:
> This test is building the component tree and rendering the output.
> The output is parsed and checked for an embed comment.
> Since the myfaces-impl is not a dependency, the renderers are
> not being loaded and no markup generated.
>
> I could create some mock renderers for this test. That would be
> much easier than starting a wrestling match with maven.
Gary, if it's easier, you can add myfaces-impl as a dependency in test
scope. That won't affect projects using Clay, it will only be on the
classpath during the test phases.
<dependency>
<groupId>myfaces</groupId>
<artifactId>myfaces-impl</artifactId>
<version>1.1.1</version>
<scope>test</scope>
</dependency>
--
Wendy