Re: [virgo-dev] Running integration tests with maven

[Glyn Normington <gnormington@xxxxxxxxxx>]

It's even worse than that: we also index into the ivy cache in Eclipse .classpath files and in some tests, for example org.eclipse.virgo.web.test.SpringWebFlowWarTests in Virgo web.

Option 4 seems the best way to handle the test.config.properties, but it won't help with .classpath files or the tests.

In general, it would be good to avoid introducing a parallel maintenance problem by duplicating information.

So something like option 1 with a Maven build step to store anything it has just downloaded in the ivy cache following all ivy conventions would be ideal, although probably not possible.

Wouldn't it be easier to get to use Ant/Ivy? It would probably not be too difficult to rework the builds to have the option of sharing an ivy cache across repos, which I believe was one of the original drivers behind using Maven.

Glyn
On 15 Jul 2010, at 05:36, Dmitry Sklyut wrote:

> Hi,
> 
> I have finally hit the issue that I knew would cause some pain and suffering for creating a maven build.
> 
> With virgo-build there are well known locations of the artifacts and this knowledge is reflected in test.config.properties.  
> 
> Example (from org.eclipse.virgo.medic.integrationtest):
> launcher.bundles=\
> file:../ivy-cache/repository/org.aspectj/com.springsource.org.aspectj.runtime/1.6.6.RELEASE/com.springsource.org.aspectj.runtime-1.6.6.RELEASE.jar@start,\
> file:../ivy-cache/repository/org.slf4j/com.springsource.slf4j.api/1.5.10/com.springsource.slf4j.api-1.5.10.jar@start,\
> file:../ivy-cache/repository/org.eclipse.virgo.util/org.eclipse.virgo.util.common/2.1.0.D-20100513115049/org.eclipse.virgo.util.common-2.1.0.D-20100513115049.jar,\
> file:../ivy-cache/repository/org.eclipse.virgo.util/org.eclipse.virgo.util.osgi/2.1.0.D-20100513115049/org.eclipse.virgo.util.osgi-2.1.0.D-20100513115049.jar,\
> file:../ivy-cache/repository/org.eclipse.virgo.util/org.eclipse.virgo.util.parser.manifest/2.1.0.D-20100513115049/org.eclipse.virgo.util.parser.manifest-2.1.0.D-20100513115049.jar,\
> file:../ivy-cache/repository/org.apache.felix/org.apache.felix.configadmin/1.2.4/org.apache.felix.configadmin-1.2.4.jar@start,\
> file:../org.eclipse.virgo.medic/target/artifacts/org.eclipse.virgo.medic.jar@start,\
> file:../org.eclipse.virgo.medic.core/target/artifacts/org.eclipse.virgo.medic.core.jar@start,\
> file:src/test/resources/config-fragment,\
> file:src/test/resources/appender-fragment
> 
> There are at least 4 issues of reusing this set-up with Maven.
> 1. location of repository (i.e. ivy-cache/repository vs. .m2/repository)
> 2. structure of repository (org.aspectj vs org/aspectj)
> 3. version of the artifact (and + ivy - Ripplor controlled, with Maven  -SNAPSHOT for example)
> 4. virgo-build generates artifacts in target/artifacts without a version, Maven does it (by default) in target with a version qualifier.
> 
> Given these issues (at least these issues) - I would like to solicit some feed back from interested parties on a way forward.
> 
> Some potential solutions:
> 1. Make maven copy jars in expected location
> - maven build will have to not only track dependencies in ivy but also changes to test config
> 2. Provide some placeholders and filter test.config.properties from both systems before test run
> - could be messy and introduces another set of filter files and such...
> 3. Modify ant virgo-build to copy dependencies to for example $module/target/dependencies directory vs. referencing from known locations
> - not sure how much work that will be on potentially creating extra ivy resolvers and such...
> 4. Have two separate but equal files
> - one for virgo-build one for virgo-maven-build
> - maven will have to take care to override default one with its own
> 
> So far I like option 4 as it introduces least amount of work for everyone and results in just one extra file added to the repo.
> 
> Any other though on this topic?  Ideas?
> 
> Regards,
> 
> Dmitry
> <ATT00001..txt>