imo we should keep it simple.
#1 it should be as simple as possible to execute the tests
#2 tests for the jsf api should be executed with the first possible version
as well as "all" later versions (e.g. 2.0.2 -> 2.1.0+ -> 2.2.0+ ...).

a solution which meets both will get my +1

regards,
gerhard

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces


2011/7/29 Leonardo Uribe <[email protected]>

> Hi
>
> I think there are many ways to do it. For example, you can play with
> source paths and maven profiles. For example the following code is
> valid:
>
>  <profiles>
>    <profile>
>      <id>tests-jsf-21</id>
>      <activation>
>        <property>
>          <name>jsf</name>
>          <value>21</value>
>        </property>
>      </activation>
>      <build>
>        <plugins>
>          <plugin>
>            <artifactId>maven-war-plugin</artifactId>
>            <configuration>
>              <webResources>
>                <resource>
>                  <directory>src/main/webapp21</directory>
>                </resource>
>              </webResources>
>            </configuration>
>          </plugin>
>        </plugins>
>      </build>
>    </profile>
>
> You can include source, resource, or webappp directories based on a
> profile.
>
> We can do trick about run in for jsf 2.0, create an specific task for
> hudson and "playing" with the profiles. Note we don't need to generate
> any artifacts or even release them. The only thing we need is run them
> periodically.
>
> The problem about have the code in different locations is the same we
> had with shared module: to compile one we need compile the other one.
> That's other reason why I'm proposing move everything instead keep two
> copies.
>
> regards,
>
> Leonardo
>
> 2011/7/29 Gerhard Petracek <[email protected]>:
> > @jakob: +1
> > regards,
> > gerhard
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> >
> >
> > 2011/7/29 Jakob Korherr <[email protected]>
> >>
> >> Hi,
> >>
> >> I would like to do it exactly like we did it in MyFaces-Test, however
> >> not exactly like you're proposing. As you said, MyFaces-Test keeps the
> >> most code in the 1.2 module and the 2.0 module just takes what it
> >> needs. But what you're proposing is to move all integration-tests to
> >> 2.1 and also run it with 2.0 in some kind of way..
> >>
> >> I would like to have the 2.0 integration-tests really in the 2.0
> >> branch. If some of them (or as you pointed out: most of them) also
> >> apply to the 2.1 branch, the 2.1 branch should re-use them dynamically
> >> and not the other way round.
> >>
> >> Thus it would be like this: 2.0 branch provides all 2.0 applicable
> >> tests, 2.1 branch re-uses the tests which also apply for 2.1 and adds
> >> some 2.1 specific ones.
> >>
> >> Regards,
> >> Jakob
> >>
> >> 2011/7/28 Leonardo Uribe <[email protected]>:
> >> > Hi
> >> >
> >> > Some weeks ago a new module for integration test was added. See.
> >> >
> >> > https://issues.apache.org/jira/browse/MYFACES-3217
> >> >
> >> > The code proposed was committed on 2.0.x branch. In the following mail
> >> > we'll discuss if we should move this to current trunk (2.1.x) or
> >> > create and maintain two copies: one in 2.0.x and the other one in
> >> > 2.1.x (trunk).
> >> >
> >> > I agree that both branches are still used a lot and are being
> >> > maintained actively. But I think maintain two branches of the same
> >> > testing code seems to be an unnecessary burden. I think we can put
> >> > this in just one place an make it run with 2.0. / 2.1 with just some
> >> > maven configuration.
> >> >
> >> > Note 2.0.x and 2.1.x are very similar. In practice, every time we
> >> > found an issue in 2.1.x, the same patch is applied to 2.0.x too. So it
> >> > is not necessary to run the integration tests for 2.0.x branch because
> >> > in practice when we run it against 2.1.x, we are taking into account
> >> > 2.0.x, as long as the changes be commited on 2.0.x too.
> >> >
> >> > In few words, put this on trunk does not mean it will not run against
> >> > 2.0 !!!!. A "light" way to deal with this kind of problem is take a
> >> > look at myfaces tests project. It has two modules: 1.2 and 2.0, and
> >> > 2.0 just "take what it needs" from 1.2 module and that's it. This
> >> > reduce the burden to the minimum.
> >> >
> >> > regards,
> >> >
> >> > Leonardo Uribe
> >> >
> >>
> >>
> >>
> >> --
> >> Jakob Korherr
> >>
> >> blog: http://www.jakobk.com
> >> twitter: http://twitter.com/jakobkorherr
> >> work: http://www.irian.at
> >
> >
>

Reply via email to