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

[Dmitry Sklyut <dmitry@xxxxxxxxxxx>]

Oh boy :)

My main driver for using maven was to have an ability to do a full local build of virgo without hitting any of the remote repos and ability to use an ide other than Eclipse/STS.  There is nothing wrong with STS, but I am just much more comfortable with IntelliJ.  I am also a bit apprehensive about Ripplor and a need to have some fairly deep understanding on how artifact versions are generated for local/daily/milestone/etc builds.   maven does a decent job of dependency management and I really like maven "-SNAPSHOT" semantics where one just knows that it will point to the latest build.  With virgo-build + Ripplor it is a manual thing plus it makes merges more difficult with .classpath files checked in.  

It is fairly unusual to have two build systems for a project.  Specifically based on different and competing dependency management systems.  

Thank you for pointers.  I guess I will try to muddle through with maven anyway.  At least Nikolai mentioned his interest a while back on the community call.  It makes for a good learning exercise at least.  

Regards,

Dmitry

On Thu, Jul 15, 2010 at 9:56 AM, Glyn Normington <gnormington@xxxxxxxxxx> wrote:

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>

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev