Ok. The only thing I think would be an improvement is if the
dependencies, instead of being passed using the mvn: URIs, would be
resolved by the maven plugin and passed as file: URIs instead. This
way, if I've got a project structure like
myproject/
bundle1/
pom.xml
bundle2/
pom.xml
integration-tests/
pom.xml
I can run the integration tests from the root project directory,
myproject, and have the bundles that pax runner is configured with be
the jars in myproject/bundle1/target/bundle1-1.0-SNAPSHOT.jar and
myproject/bundle2/target/bundle2-1.0-SNAPSHOT.jar. As it stands now,
because you pass the mvn: URI instead of the file: URI, pax runner
will try and find the bundle jars in the local repository or try and
download them from a remote repository rather than use the jars that
were created as part of the build. It's really handy to not have to
install the bundles into a local repository until the integration
tests pass. This can be particularly important in doing CI.
One other thing that is usually good to do is rather than have the
hardcoded, "everything with provided scope gets provisioned" is to
allow people the option of specifying the scope and type and use an
ArtifactFilter on the dependencies to find the ones you want.
Rich
On Tue, Mar 24, 2009 at 11:22 AM, Toni Menzel <[email protected]> wrote:
> Don't be confused that i mentioned Pax Runner all the time but as you might
> know,
> when choosing pax exam today you get the "pax runner container" by default.
> The plugin by default generates a file that will be read directly by
> paxrunner after being launched by pax exam (under the hood).
>
>
> On Tue, Mar 24, 2009 at 7:18 PM, Toni Menzel <[email protected]> wrote:
>>
>> Hi Richard,
>>
>> It works as follows:
>> 1. the maven plugin uses the reactor dependencies in scope "provided" (all
>> of them) plus configuration options (as in example) to create a file in
>> target/classes called paxexam.args.
>>
>> 2. This file has exactly the format which paxrunner understands.
>> For dependencies:
>> - all dependencies will result in line like that:
>> mvn:<groupId>/<artifactId>/<version>
>> - all other configs you specifiy in the plugin setting in your pom are
>> directly passed
>> as options:
>> so if you have something like this
>> <platform>felix</platform>
>> it will result to:
>> --platform=felix
>> (see pax runner docs. You can specify any commandline option in that file
>> including dependencies, osgi framework and much more)
>> Pax Runner will pick that up and just run pax runner (as always)
>>
>> If you have non bundle dependencies in you pom in scope "provided",you
>> should add
>> <autoWrap>true</autoWrap>
>> in your pom.xml
>>
>> This whole feature is very new and not used much (because its not released
>> yet), so
>> we would appreciate any comments & suggestions.
>>
>> cheers,
>> Toni
>>
>> On Tue, Mar 24, 2009 at 6:21 PM, Richard Wallace
>> <[email protected]> wrote:
>>>
>>> Hey all,
>>>
>>> So I just came across the new Pax Exam maven plugin. It's super cool
>>> and exactly the kind of thing I've been looking for. Now, one
>>> question I have is how does it pass the maven dependencies to Pax
>>> Exam? What I'm wondering is if it will pull dependencies out of the
>>> reactor or not. This is extremely important in a multi-module project
>>> where you want to have a separate project module just for integration
>>> tests. I'm hoping that the maven dependencies are resolved in the
>>> maven plugin and the file names are passed to Pax Exam, rather than
>>> passing the maven artifact id and letting the maven url handler do the
>>> resolution. Is that the case? If not, I'll create an issue and work
>>> on creating a patch.
>>>
>>> The 2 things that have always turned me off Pax Exam in the past has
>>> been the inability to pull dependencies from the maven reactor and
>>> that the tests are always bundled and loaded into the OSGi framework.
>>> If the maven paxexam plugin fixes the former and we can get PAXEXAM-30
>>> resolved, I'll be one happy dude when it comes to doing integration
>>> testing of OSGi bundles.
>>>
>>> Thanks,
>>> Rich
>>>
>>> _______________________________________________
>>> general mailing list
>>> [email protected]
>>> http://lists.ops4j.org/mailman/listinfo/general
>>
>>
>>
>> --
>> Toni Menzel
>> Software Developer
>> Professional Profile: http://www.osgify.com
>> [email protected]
>> http://www.ops4j.org - New Energy for OSS Communities - Open
>> Participation Software.
>
>
>
> --
> Toni Menzel
> Software Developer
> Professional Profile: http://www.osgify.com
> [email protected]
> http://www.ops4j.org - New Energy for OSS Communities - Open
> Participation Software.
>
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general
>
>
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
