You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Paul Gier <pg...@redhat.com> on 2007/06/21 18:00:31 UTC
Allowing test scope dependencies in profiles.xml
In the process of migrating Hibernate to maven, Steve Ebersole ran into
some issues that are not easily handled in maven's current form.
The basic requirement is that hibernate needs to be tested against
various database configurations. Some of which are standard Red
Hat/JBoss supported configurations, and some are user supplied. It
would be useful for a user to check out the hibernate code, drop in
their own test configuration (without changing the pom.xml), and run the
tests against some random database. This could be done using
profiles.xml, but currently profiles.xml does not allow the addition of
dependencies (jbdc drivers).
So the question is whether it is a good idea to allow test scope
dependencies to be added to profiles.xml.
Here is the original email, please let me know what you think, and if
this is something that could be added to maven 2.1.
-------- Original Message --------
Subject: Re: testing
Date: Wed, 13 Jun 2007 12:03:44 -0500
From: Steve Ebersole <st...@hibernate.org>
Organization: Hibernate
To: jason@maven.org
References: <46...@hibernate.org>
Another situation closely related to the developer discussion #2 is
"local" test resources in general. Take something like log4j config. I
can't imagine the recommendation is to modify a
src/main/resources/log4j.properties file under source control for my
personal local preferences and needs.
Steve Ebersole wrote:
> Ok, so this is the issue: the hibernate testsuite. Out test suite is
> mostly functional/integration testing. So we actually "hit the
> database" for most of our tests. Obviously we would like the ability
> to be able to run against multiple databases *in an extensible way*.
>
> This has implications in 2 scenarios:
>
> 1) What I'll call continuous integration testing. There are two
> groups of users to consider here:
> a) RH QE (QA) who maintain our CruiseControl (soon to be Hudson)
> automated builds/runs. This set of database environments is finite,
> and more importantly known ahead of time. That means we could
> facilitate this group as-is with Maven using profiles in the pom for
> each database, since those profiles can define deps and
> resources/configs.
> b) JBoss/RH partners and other external interested parties.
> Generally, these are folks who have some crazy database against which
> they want to host continuous integration runs for Hibernate. However,
> these are databases we do not care to maintain ourselves, so they do
> the CI work. This is one aspect of the extensible bit. The full set
> of these environments is not known; users should be able to "drop in"
> a new environment, which again for Hibernate testing is the deps
> making up the JDBC driver and a custom hibernate.properties (perhaps
> some other configs).
>
> For the most part, from what I saw, this could be handled via an
> external profiles.xml *as long as it were to allow defining
> dependencies*. Unfortunately, that is not the case right now. As an
> example of what I mean, here is the snippet from the Hibernate
> testsuite module as checked into SVN:
>
> <profiles>
> <profile>
> <id>hsqldb</id>
> <activation>
> <activeByDefault>true</activeByDefault>
> </activation>
> <build>
> <testResources>
> <testResource>
> <filtering>false</filtering>
> <directory>src/test/profile/hsqldb</directory>
> </testResource>
> </testResources>
> </build>
> <dependencies>
> <dependency>
> <groupId>hsqldb</groupId>
> <artifactId>hsqldb</artifactId>
> <version>1.8.0.2</version>
> </dependency>
> </dependencies>
> </profile>
> </profiles>
>
> So ideally, if a user could check-out/export from SVN, drop in a
> custom profile.xml (either in home or wherever) and then run mvn using
> their custom environment profile I think we'd be done with that aspect
> of it. Perhaps you could rethink not allowing <dependencies/> in
> these external profile sources with the assumption that they only are
> allowed for test scope?
>
>
> 2) Developer checkouts. This is the one I have no clue how to solve.
> Ideally, IDEs would have a notion of activate-able profiles that would
> map to the same maven notion. But, well, that isn't the case :( So
> lets take intellij for example since you and I both know it better.
> How could I, as a developer, checkout the hibernate codebase and try
> to run the testsuite module against say oracle instead of the default
> hsqldb? And more importantly, how could I do that in a way that won't
> disappear the next time I "synchronize" the intellij project from the
> maven pom?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Allowing test scope dependencies in profiles.xml
Posted by Jason van Zyl <ja...@maven.org>.
On 21 Jun 07, at 9:00 AM 21 Jun 07, Paul Gier wrote:
>
> In the process of migrating Hibernate to maven, Steve Ebersole ran
> into some issues that are not easily handled in maven's current form.
> The basic requirement is that hibernate needs to be tested against
> various database configurations. Some of which are standard Red
> Hat/JBoss supported configurations, and some are user supplied. It
> would be useful for a user to check out the hibernate code, drop in
> their own test configuration (without changing the pom.xml), and
> run the tests against some random database. This could be done
> using profiles.xml, but currently profiles.xml does not allow the
> addition of dependencies (jbdc drivers).
>
> So the question is whether it is a good idea to allow test scope
> dependencies to be added to profiles.xml.
>
> Here is the original email, please let me know what you think, and
> if this is something that could be added to maven 2.1.
>
I talked briefly with Steve about this and I think that for creating
a TCK type package it could be a very nice way to make a TCK setup
and easily plug them in.
I know that John was generally worried about portability of the build
in allowing dependencies to be specified in the profiles.xml file,
but if they were only allow to be test scoped dependencies then at
first blush I think this could not pollute downstream development or
runtimes.
It would need more discussion but at first blush I like it, and it
prevents people from doing what Steve was going to attempt to do in
trying to make a completely different custom plugin to make this
possible instead of using a standard Maven resource like profiles.xml
and harnessing that as part of the solution.
> -------- Original Message --------
> Subject: Re: testing
> Date: Wed, 13 Jun 2007 12:03:44 -0500
> From: Steve Ebersole <st...@hibernate.org>
> Organization: Hibernate
> To: jason@maven.org
> References: <46...@hibernate.org>
>
> Another situation closely related to the developer discussion #2 is
> "local" test resources in general. Take something like log4j
> config. I can't imagine the recommendation is to modify a src/main/
> resources/log4j.properties file under source control for my
> personal local preferences and needs.
>
> Steve Ebersole wrote:
>> Ok, so this is the issue: the hibernate testsuite. Out test suite
>> is mostly functional/integration testing. So we actually "hit the
>> database" for most of our tests. Obviously we would like the
>> ability to be able to run against multiple databases *in an
>> extensible way*.
>>
>> This has implications in 2 scenarios:
>>
>> 1) What I'll call continuous integration testing. There are two
>> groups of users to consider here:
>> a) RH QE (QA) who maintain our CruiseControl (soon to be Hudson)
>> automated builds/runs. This set of database environments is
>> finite, and more importantly known ahead of time. That means we
>> could facilitate this group as-is with Maven using profiles in the
>> pom for each database, since those profiles can define deps and
>> resources/configs.
>> b) JBoss/RH partners and other external interested parties.
>> Generally, these are folks who have some crazy database against
>> which they want to host continuous integration runs for
>> Hibernate. However, these are databases we do not care to
>> maintain ourselves, so they do the CI work. This is one aspect of
>> the extensible bit. The full set of these environments is not
>> known; users should be able to "drop in" a new environment, which
>> again for Hibernate testing is the deps making up the JDBC driver
>> and a custom hibernate.properties (perhaps some other configs).
>>
>> For the most part, from what I saw, this could be handled via an
>> external profiles.xml *as long as it were to allow defining
>> dependencies*. Unfortunately, that is not the case right now. As
>> an example of what I mean, here is the snippet from the Hibernate
>> testsuite module as checked into SVN:
>>
>> <profiles>
>> <profile>
>> <id>hsqldb</id>
>> <activation>
>> <activeByDefault>true</activeByDefault>
>> </activation>
>> <build>
>> <testResources>
>> <testResource>
>> <filtering>false</filtering>
>> <directory>src/test/profile/hsqldb</directory>
>> </testResource>
>> </testResources>
>> </build>
>> <dependencies>
>> <dependency>
>> <groupId>hsqldb</groupId>
>> <artifactId>hsqldb</artifactId>
>> <version>1.8.0.2</version>
>> </dependency>
>> </dependencies>
>> </profile>
>> </profiles>
>>
>> So ideally, if a user could check-out/export from SVN, drop in a
>> custom profile.xml (either in home or wherever) and then run mvn
>> using their custom environment profile I think we'd be done with
>> that aspect of it. Perhaps you could rethink not allowing
>> <dependencies/> in these external profile sources with the
>> assumption that they only are allowed for test scope?
>>
>>
>> 2) Developer checkouts. This is the one I have no clue how to
>> solve. Ideally, IDEs would have a notion of activate-able
>> profiles that would map to the same maven notion. But, well, that
>> isn't the case :( So lets take intellij for example since you
>> and I both know it better. How could I, as a developer, checkout
>> the hibernate codebase and try to run the testsuite module against
>> say oracle instead of the default hsqldb? And more importantly,
>> how could I do that in a way that won't disappear the next time I
>> "synchronize" the intellij project from the maven pom?
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org