[Pax-Exam] How to add a Karaf distro being built in same reactor than pax exam project?

66 views
Skip to first unread message

Oliver Wilkie

unread,
May 13, 2014, 6:14:56 PM5/13/14
to op...@googlegroups.com
Pax-exam gives an ArtificatNotFoundException for my custom Karaf distro when I run mvn install from a parent pom. I think this is because it is a sibling module to the module that contains Pax Exam.

Is there a way to resolve the sibling Karaf distribution from the Maven Reactor as opposed to the local repo?


MavenArtifactUrlReference karafUrl = maven().groupId("uk.org.openeyes.oink.karaf").artifactId("distro").type("tar.gz").versionAsInProject();

throws error:

org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact uk.org.openeyes.oink.karaf:distro:tar.gz:0.2 in local (file:/Users/Oli/.m2/repository/

Achim Nierbeck

unread,
May 14, 2014, 9:52:13 AM5/14/14
to op...@googlegroups.com
create a test module, don't do it in your "parent", this way you're safe with using the right dependencies. 
at [1] or [2] there is an example of the best "module" layout for this. 

regards, Achim 



--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
blog <http://notizblog.nierbeck.de/>

Software Architect / Project Manager / Scrum Master

Christian Schneider

unread,
May 14, 2014, 10:03:22 AM5/14/14
to op...@googlegroups.com
As far as I know currently it is not possible to share the reactor build between karaf and pax exam.
So the only way to make this work is to make sure each artifact you need in the test is also specified as a maven dependency of the itest project. So maven makes sure these are built before the test.

Christian
--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Oliver Wilkie

unread,
May 14, 2014, 10:14:56 AM5/14/14
to op...@googlegroups.com
Thanks for both suggestions. Let me give you a bit more detail.

So the only way to make this work is to make sure each artifact you need in the test is also specified as a maven dependency of the itest project. So maven makes sure these are built before the test.

Here is my Reactor Build Order

[INFO] OINK Parent
[INFO] OINK Domain
[INFO] OINK Core
[INFO] OINK :: Adapters
[INFO] OINK :: Adapters :: Facade
[INFO] OINK :: Adapters :: Proxy
[INFO] Oink :: Platforms
[INFO] Oink :: Platforms :: Apache Karaf
[INFO] Oink :: Platforms :: Apache Karaf :: Features Repository
[INFO] Oink :: Platforms :: Apache Karaf :: Shell Commands
[INFO] Oink :: Platforms :: Apache Karaf :: KAR
[INFO] Oink :: Platforms :: Apache Karaf :: Custom Distribution <— The karaf distro I want to use in my Pax Exam tests
[INFO] Oink :: Integration Tests
[INFO] Oink :: Integration Tests :: Non OSGi
[INFO] Oink :: Integration Tests :: Karaf <- The Pax Exam tests

When I do mvn clean install from OINK Parent no exceptions occur.
When I do mvn clean verify from OINK Parent however then exceptions occur because my custom distribution WASNT installed to the local repo (since we are only going as far as verify)

Is there a straightforward way of making it so that..

When mvn clean verify is called on either parent pom or my pax exams pom then somehow the Custom Distribution is either installed or built somewhere where the pax exams can get to it?

Looking forward to your suggestions!

Best,
Oli




You received this message because you are subscribed to a topic in the Google Groups "OPS4J" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ops4j/EXtrOLSAWG8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ops4j+un...@googlegroups.com.

Achim Nierbeck

unread,
May 14, 2014, 10:17:45 AM5/14/14
to op...@googlegroups.com
You have to live with clean install. 
Cause all your dependencies for your test are based on maven coordinates (most likely ;)). 
If not make sure you do all references with file: 
in the configuration of your test. 

regards, Achim 


Oliver Wilkie

unread,
May 14, 2014, 10:22:20 AM5/14/14
to op...@googlegroups.com
Thats a shame because that means the maven-release-plugin’s default settings can’t be used to make my releases.

The maven-release-plugin by default takes my working code which has version 0.x-SNAPSHOT and temporarily changes the version to 0.x then performs a ‘clean verify’ to make sure all the tests still pass.

You CAN change the default behaviour of it calling ‘clean verify’ to ‘clean install’ so perhaps thats my best option now.

Thanks,
Oli

Christian Schneider

unread,
May 14, 2014, 10:24:50 AM5/14/14
to op...@googlegroups.com
Yes. I think that is the only option for now. Can you describe how to do such a release? I think this might be interesting for others who also create a custom distro in their build.

Christian


On 14.05.2014 16:22, Oliver Wilkie wrote:
Thats a shame because that means the maven-release-plugin’s default settings can’t be used to make my releases.

The maven-release-plugin by default takes my working code which has version 0.x-SNAPSHOT and temporarily changes the version to 0.x then performs a ‘clean verify’ to make sure all the tests still pass.

You CAN change the default behaviour of it calling ‘clean verify’ to ‘clean install’ so perhaps thats my best option now.

Thanks,
Oli



Achim Nierbeck

unread,
May 14, 2014, 10:25:28 AM5/14/14
to op...@googlegroups.com
I'm not sure I follow, 
cause the maven-release-plugin runs very nicely when releasing the Pax Web project. 
And I do have different modules used in my tests. The same is true for the release of Karaf itself. 
So I don't see why the maven-release-plugin shouldn't work with a "clean install"

regards, Achim 

Christian Schneider

unread,
May 14, 2014, 10:28:22 AM5/14/14
to op...@googlegroups.com
Hmm..

Especially the karaf argument is very valid. We also create a
distribution there that we then use inside our tests. So perhaps you can
look how the karaf tests are set up to see how to do your release.
As I never did a karaf release myself perhaps Jamie also tweaks the
release build command to do the install. Does anyone know?

Christian

On 14.05.2014 16:25, Achim Nierbeck wrote:
> I'm not sure I follow,
> cause the maven-release-plugin runs very nicely when releasing the Pax
> Web project.
> And I do have different modules used in my tests. The same is true for
> the release of Karaf itself.
> So I don't see why the maven-release-plugin shouldn't work with a
> "clean install"
>
> regards, Achim
>

Oliver Wilkie

unread,
May 14, 2014, 10:32:02 AM5/14/14
to op...@googlegroups.com
Im looking at the org.ops4j.pax.web tests which only use the bog-standard karaf distribution on central repo.

What other projects should I check? (Sorry ops4j newbie)

Achim Nierbeck

unread,
May 14, 2014, 10:35:22 AM5/14/14
to op...@googlegroups.com
Take a look at the Karaf build [1], 
it does Integration tests with Pax Exam while releasing. 

regards, Achim 



You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Oliver Wilkie

unread,
May 14, 2014, 10:39:45 AM5/14/14
to op...@googlegroups.com
Here’s your answer (in the Karaf root pom)

                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-release-plugin</artifactId>
                    <version>2.4.2</version>
                    <configuration>
                        <useReleaseProfile>false</useReleaseProfile>
                        <preparationGoals>clean install</preparationGoals>
                        <goals>deploy</goals>
                        <arguments>-Prelease,deploy,src,manual</arguments>
                        <autoVersionSubmodules>true</autoVersionSubmodules>
                    </configuration>
                </plugin>

As suspected they override the default <preparationGoals>clean verify</preparationGoals> with <preparationGoals>clean install</preparationGoals>

Thanks for the guidance,
Oli

Christian Schneider

unread,
May 14, 2014, 10:40:49 AM5/14/14
to op...@googlegroups.com
Thanks for the pointer. That explains it.

Christian


On 14.05.2014 16:39, Oliver Wilkie wrote:
Here’s your answer (in the Karaf root pom)

                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
   &n bsp;                <artifactId>maven-release-plugin</artifactId>
                    <version>2.4.2</version>
                    <configuration>
                        <useReleaseProfile>false</useReleaseProfile>
                        <preparationGoals>clean install</preparationGoals>
 & nbsp;                      <goals>deploy</goals>
                        <arguments>-Prelease,deploy,src,manual</arguments>
                       &nbsp ;<autoVersionSubmodules>true</autoVersionSubmodules>
                    </configuration>
                </plugin>

As suspected they override the default <preparationGoals>clean verify</preparationGoals> with <preparationGoals>clean install</preparationGoals>

Thanks for the guidance,
Oli

Reply all
Reply to author
Forward
0 new messages