Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Maven project file for JUnit as OSGi bundle #472

Closed
wants to merge 26 commits into
from

Conversation

Projects
None yet
Contributor

Tibor17 commented Aug 8, 2012

Upon discussion #368, I created maven project file.
Other e.g. maven runtime environment, and script running pom.xml may come if necessary.

Owner

dsaff commented Aug 9, 2012

Looks interesting. Can you get one of the reporters of the original OSGi bugs to confirm that this would meet their needs? Thanks.

The bundle plugin settings look good. One thing about hamcrest. Do you want to embed it in junit? It could also be a separate bundle. How do I build junit to see the effect of the pom? As the pom is not in the usual location I guess mvn clean install will not do?!

Owner

Tibor17 replied Aug 13, 2012

@cschneider
I am aware of this, however my local (not submited) pom.xml work as expected.
I propopsed an ordinal maven build process to @dsaff in #464. Pls see my longest comment in #464.
Currently this is only a template and we make changes a step by step. I wanted more step forward change.

Owner

marcphilipp commented Aug 21, 2012

What about the junit-dep POM? Shouldn't it also be updated?

Contributor

Tibor17 commented Aug 21, 2012

@marcphilipp
yes, it should be as well. Did you see the latest comment in #212?
Tomorrow i would like to update the build process again. Can you @marcphilipp @cschneider then check it out and bring new inputs? I think that there will be quite a lot in order to provide compatible outcome against the current build process.

Owner

marcphilipp commented Aug 22, 2012

@Tibor17 Sure, I can take a look in the next couple of days. Just ping
me when you have made your changes.

Contributor

Tibor17 commented Aug 23, 2012

I submitted new changes. I would like you doing comparison of content of *.jar and *.zip files produced by Ant and Maven.

Thus launch commands
ant zip
and
make all

The settings.xml in src/main/config must be configured in prior.

In order to simulate deployment (make all) to https://oss.sonatype.org and http://sourceforge.net
use ftp setup via FileZilla Server on
ftp://localhost/sonatype and ftp://localhost/sourceforge
for repository ids:
sonatype-nexus-staging
sourceforge-staging

The deployment to sourceforge creates junit/junit/ directories which I will fix next days.
Also I will continue on use of OSGi Felix in junit.

There are few things to discuss and we i expect different opinions..., but i had to make some decisions in pom.xml

@dsaff dsaff and 1 other commented on an outdated diff Sep 4, 2012

build/maven/junit-pom-template.xml
@@ -52,6 +53,24 @@
<target>${jdk.version}</target>
</configuration>
</plugin>
+ <plugin>
+ <groupId>org.apache.felix</groupId>
+ <artifactId>maven-bundle-plugin</artifactId>
+ <version>2.3.7</version>
+ <extensions>true</extensions>
+ <configuration>
+ <instructions>
+ <Bundle-SymbolicName>org.junit</Bundle-SymbolicName>
+ <Bundle-Name>${project.name}</Bundle-Name>
+ <Bundle-Version>${project.version}</Bundle-Version>
+ <Export-Package>org.hamcrest.*;version="${hamcrest.version}",junit.*;version="3.8.2",org.junit.*;version="${project.version}</Export-Package>
@dsaff

dsaff Sep 4, 2012

Owner

What is 3.8.2 doing here?

@Tibor17

Tibor17 Sep 9, 2012

Contributor

The packages have versions.
The junit.* packages have old version 3.8.2 that we are exporting.
Other bundle XYZ that imports this one junit bundle, and wants to import junit.* packages with version 3.8.2+ still can use. If the XYZ do not want to use these packages, then simply their import section Import-Package may omit junit.*.

@dsaff

dsaff Sep 10, 2012

Owner

Although 3.8.2 was the last release of the project without org.junit packages, I'd have thought that we're still providing a 4.9, 4.10, etc, version of the junit.framework packages. They're just not changing very fast.

@Tibor17

Tibor17 Sep 13, 2012

Contributor

@dsaff pls see my latest update.
How we would proceed next?

@Tibor17 Tibor17 Update build/maven/junit-pom-template.xml
junit.* packages keep the latest version
fdfe12b
Owner

dsaff commented Sep 17, 2012

This latest change is OK to my eyeballs. @marcphilipp, are you planning to take a look?

Contributor

Tibor17 commented Sep 21, 2012

@dsaff after #332 is fixed and closed, so that junit-dep is gone, are you open for a real maven build process?
I may meanwhile open a pull request for junit mavenize.

@marcphilipp marcphilipp and 1 other commented on an outdated diff Sep 22, 2012

build/maven/junit-pom-template.xml
@@ -5,6 +5,7 @@
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>@version@</version>
+ <packaging>bundle</packaging>
@marcphilipp

marcphilipp Sep 22, 2012

Owner

Will this change how people can consume the Maven artifact?

Usually the will have declared a dependency to junit:junit like this:

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.10</version>
</dependency>

They probably won't have an explicit <type>jar</type> in their dependency declaration. Thus, type will point to its default value jar.

I'm worried that changing the packaging type from jar to bundle will force a lot of people to change their dependency declarations to this:

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.10</version>
    <type>bundle</type>
</dependency>

@Tibor17 Can you make sure that this will not be necessary?

I took a quick look at the Apache Felix documentation. Appararently there's a way to add OSGi metadata without changing the packaging type. For details please see:
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html#ApacheFelixMavenBundlePlugin%28BND%29-AddingOSGimetadatatoexistingprojectswithoutchangingthepackagingtype

Maybe that would be the less intrusive way to do it?

@Tibor17

Tibor17 Sep 22, 2012

Contributor

@marcphilipp

  • nothing will change. they still will use junit:junit:4.11.
  • accorind to the felix documentation this is really alright using packaging: bundle.
  • the plugin will handle manifest with packaging: bundle.
  • i used this project in integration tests and any other project dependent on junit, and it really works as if packaging: jar. Otherwise i would calim as well as you -but i proved.
  • we need default plugin's goal: bundle because we need hamcrest in it and this is easy. Next time when #421 and #332 is ready with I will change to packaging: jar and goal: manifest. I can inject hamcrest with shading plugin, but this is safe solution as well, and solves our problem (other for junit-dep).

Today I will update my project and add new OSGi entries. I modified the entries and the itegration test work fine. I will maybe tomorrow extend the integration tests.

@marcphilipp

marcphilipp Sep 22, 2012

Owner

@Tibor17 Good to hear! I think it might make sense to check-in those integration tests you setup. What do you think?

@Tibor17

Tibor17 Sep 22, 2012

Contributor

@marcphilipp
I know the a cool idea, i am happy what you have done for #332, and i am glad to release Mavn staff. But let's do it step by step. The 4-11 can have new big changes that we improve the JUnit.

@Tibor17

Tibor17 Sep 23, 2012

Contributor

One more thing I want to ask you @marcphilipp. I created #511, and on Monday i plan to create a similar pull request extended by osgi copied from my public repo.
Would you agree with me if we deploy these versions into https://oss.sonatype.org/content/repositories/snapshots
4.11-SNAPSHOT for #332
4.11.1-SNAPSHOT for #511
4.11.2-SNAPSHOT for OSGi + Maven pull request I will create on Monday morning

This way we may ask the community to test the release one by one, and improve.
After that we may ask the clients JetBrains IDEA, Eclipse, etc, to be prepared in advance for a new official release 4.11 in Maven central as non-snapshot.

One more thing, the hamcrest-core:1.3 is not OSGi, and it should be. Today I want to create a github pull request in JavaHamcrest for that.

Owner

marcphilipp commented Sep 22, 2012

@dsaff @Tibor17 Please see my inline comment.

@Tibor17 Tibor17 Update build/maven/junit-pom-template.xml
Added new entries, and osgi framework dependency.
I will on Monday create a new pull request with Maven solution using OSGi integration tests as a copy of my public repo.
It seems we should use OSGi Activator to work properly in a real environment.
<Bundle-Activator>org.junit.osgi.JunitActivator</Bundle-Activator>
6a45234
Owner

marcphilipp commented Sep 23, 2012

I like your approach of testing things one by one. However, let's put aside the topic of when and how to deploy to Maven central for now. First, I would like to get back on topic and discuss this pull request.

To be more specific: Can we please see how you've tested/verified this change? Does changing the POM template really have the desired effect of JUnit becoming consumable for both non-OSGi- and OSGi-clients? Doesn't the build.xml also need a change? Since we do not build JUnit using Maven, when will the maven-bundle-plugin get called?

Contributor

Tibor17 commented Sep 23, 2012

This is a good question. I mentioned an approach in other pull request, but it seems it was not clear.
The template like this is not enough because the ANT does not know how to handle it.
There is a way how to do that. The lifecycle of such change in build.xml will be just short, and therefore it makes sense to continue with the Maven build i made, because there is a significant work been done till now which works and that's important. That's the reason why, for me, this pull request makes sense only like presenting the configuration, but the real and final will be in a new pull request without this template on Monday -currently i am preparing files to push maybe at night or so.

Owner

marcphilipp commented Sep 24, 2012

IMHO, a pull request should present a sensible increment of functionality for reviewing and then merging.

I don't see the point in merging something that would, at the least, introduce something that is not used or, even worse, probably break our current Maven deployment from the Ant build file.

@dsaff What's your opinion on this?

Owner

dsaff commented Sep 24, 2012

I'm not planning to come up to speed on OSGi and maven enough to provide technical guidance on these questions. I think my time is better spent in the core code, which I can provide expertise on. The amount of uncertainty among people I respect on this thread makes me concerned that accepting this patch (and some of the related patches) would simply mean more bug reports in the future that I don't understand.

Is there any way for those concerned to set up an interim solution? Some kind of junit-osgi bundle that would depend on junit, but be maintained separate from it, and provide the packaging required by OSGi?

Contributor

Tibor17 commented Sep 25, 2012

@dsaff
i am facing the interim solution as BND library used in build.xml -does not change pom.xml in deployment to Maven central nor the packaging.
Would it be a good step @marcphilipp ? The bnd would only add extra manifest attributes which does not harm the library. This should be simple enough for maintenance.

Owner

marcphilipp commented Sep 25, 2012

As @dsaff mentioned we should try to get one of the original reporters of issue #212 on board. Thus, I added a couple of questions we should get answered before we can continue there.

Summing up, I think we should first release 4.11 as it is now to get more feedback on the Maven relocation of junit-dep and the new junit artifact.

@Tibor17 Are you ok with that?

Contributor

Tibor17 commented Sep 25, 2012

@marcphilipp we need @cschneider as the reporter of # 212.
@cschneider do you still have time to track this pull?

Contributor

Tibor17 commented Sep 27, 2012

@marcphilipp I am fine with deploying 4.11 first.

Owner

dsaff commented Oct 5, 2012

OK, we'll tackle this again once 4.11 is out the door. Thanks, everyone.

Owner

dsaff commented Nov 8, 2012

Explicitly added for consideration in the 4.12 milestone

Contributor

Tibor17 commented Nov 21, 2012

@dsaff
@marcphilipp
Regarding the milestone.
This pull is already designed in maven. To me it seems more convenient to proceed with #511 first. There we are on a right way. The only thing I have not done there yet is to update my branch in #511 -I will do this weekend.
Simply we may release beta-1 for maven part, and then next beta-2 for this pull.
Can we proceed like this?

Owner

dsaff commented Nov 21, 2012

Agreed that tackling #511 first is the right next step.

Owner

dsaff commented Dec 18, 2012

For anyone following this, work continues in #511, FYI.

Contributor

Tibor17 commented Jan 8, 2013

I will insert the felix plugin to the new pom.xml as soon as the junit mavenization is available
and revert the edited file build/maven/junit-pom-template.xml .

Owner

dsaff commented Jan 28, 2013

Removed from 4.12 milestone; we can revisit in 4.13.

Contributor

Tibor17 commented Jan 28, 2013

@dsaff
Ok, just mark with 4.13.

Owner

dsaff commented Feb 27, 2013

Since we haven't pushed 4.12 out the door yet, should we now reconsider this?

Contributor

Tibor17 commented Mar 1, 2013

I can submit my changes during the weekend in one week. I have been busy with looking for a new job.
After mavenization we completed with Stephen, I would continue which means I would integrate my local code changes to this repo.

Owner

dsaff commented Mar 27, 2013

Best of luck job hunting! Closing for now to clean up the pull list, but please re-open when you're ready.

@dsaff dsaff closed this Mar 27, 2013

Contributor

Tibor17 commented Mar 28, 2013

No problem, I have these days more spare time to continue.

@dsaff dsaff reopened this Apr 2, 2013

Contributor

Tibor17 commented Apr 2, 2013

@dsaff
@cschneider
@hwellmann
May you have a look into the completed osgi headers in pom.xml and the integration test OSGiITCase? Thx.

Owner

dsaff commented Apr 3, 2013

I asked this question a while back. Is there an answer?

"Is there any way for those concerned to set up an interim solution? Some kind of junit-osgi bundle that would depend on junit, but be maintained separate from it, and provide the packaging required by OSGi?"

I'd still prefer that solution--having code in org.junit depending on OSGi is a big change, and not to be taken lightly.

Contributor

Tibor17 commented Apr 4, 2013

@dsaff
I thought that the interim solution would be the integration test which explores usability of the OSGi Headers like we did here. I think that having a look on the headers was not enough and so the IT said go ahead.
I can remove the org.junit.osgi.Activator from main code and the IT will pass again, which means that there should not be fear with breaking something in the main code. If the OSGi users will shout too much about missing serices and Activator, then I can whenever submit it back.
Let's see the another angle. The people in Hamcrest in GitHub requested OSGi even saying that technically it is not a problem to configure the build system to generate the Headers in MANIFEST.MF. They do not consider the IT yet, so it looks like they trust somehow on the configuration only. We need the test because it guarantees that we made all with real use and correctly. Yes the headers changed and removed the Hamcrest because the Hamcrest is not embedded in JAR after the latest mavenization, so this was a necessary change.

Contributor

Tibor17 commented Apr 4, 2013

@cschneider
Christian, may you join us again in Junit ?
Thx

Owner

dsaff commented Apr 4, 2013

@Tibor17,

Each additional dependency of the JUnit library is cost for every maintainer and user--this is worthwhile when a big majority of users and maintainers get the benefits. In this case, I personally get no benefit from the OSGi integration. My guess is that there are a fair number of maintainers and users in the same position.

By accepting this patch, I'm accepting the responsibility to make sure that we don't break OSGi in the future. This might be worthwhile if there's absolutely no other technical way to do it, and in that case, having an integration test is an excellent way to begin reducing the necessary costs. However, if we can just create a new maven module, outside of the junit code tree, that bundles junit as an OSGi jar, and tell people who care about OSGi to use that module, then we can split the complexity and the responsibility, so I really want to be sure that we've explored that option.

Contributor

Tibor17 commented Apr 4, 2013

@dsaff
I removed the dependency from the main code src/main/java.
Our internal integration test has a dependency to osgi framework.

Let's get the voters and users of this patch from GitHub and junit@yahoo.

Hi all,

@Tibor17 asked me to take a look at the current code. I cloned the junit repo git@github.com:junit-team/junit.git. I was able to compile it using maven but there was no OSGi manifest. I guess it is in some other repo.
About the OSGi dependency. I do not understand why we need a dependency to OSGi and an activator. Why not just define some import and export packages? This should create no additional dependencies and should be good enough for most cases.

Contributor

Tibor17 commented Apr 4, 2013

@cschneider

You are maybe referring to an old commit.
See this latest one
https://github.com/Tibor17/junit/blob/8dce52e618f007cc34a99eb74fd83fad0839e49e/pom.xml

So we do not have <Bundle-Activator/> and we do not have any extra dependency in the main code.

We only have OSGi Headers in maven-bundle-plugin plugin:

<Main-Class>org.junit.runner.JUnitCore</Main-Class> <Bundle-SymbolicName>org.${project.artifactId}</Bundle-SymbolicName> <Bundle-Name>${project.name}</Bundle-Name> <Bundle-Description>${project.description}</Bundle-Description> <Bundle-Vendor>${project.organization.name}</Bundle-Vendor> <Bundle-DocURL>${project.organization.url}</Bundle-DocURL> <Bundle-Version>${project.version}</Bundle-Version> <Export-Package>!org.junit.internal.*,!org.junit.experimental.theories.internal.*,junit.*;version="${project.version}",org.junit.*;version="${project.version}"</Export-Package> <Private-Package>org.junit.internal.*,org.junit.experimental.theories.internal.*</Private-Package> <Bundle-Description>${project.description}</Bundle-Description> <Bundle-License>Common Public License Version 1.0</Bundle-License> <Import-Package>!org.hamcrest.internal.*,org.hamcrest.*</Import-Package>

and these are our maven dependencies:

<dependencies> <dependency> <groupId>org.hamcrest</groupId> <artifactId>hamcrest-core</artifactId> <version>1.3</version> </dependency> <dependency> <groupId>org.apache.felix</groupId> <artifactId>org.apache.felix.framework</artifactId> <version>4.0.3</version> <scope>test</scope> </dependency> </dependencies>

Note: the org.apache.felix.framework is used in our internal IT tests and the Junit user does NOT inherit such library in classpath.
Notice that we now do not have Hamcrest embedded in Junit library, so we do not export it out of the bundle.
Additionally the Hamcrest is not OSGi bundle, so our IT test has extra system package with Hamcrest loaded from application ClassLoader.

Perhaps default headers might be avoided.

How does it look like in your eyes?
If you have any questions, do not hesitate and just ask.

Contributor

Tibor17 commented Apr 4, 2013

@cschneider
About the IT test.

We are independent of Framework vendor in the test because we are loading the FremeworkFactory via Java ServiceLoader (META-INF/services/...). We start two bundles: junit itself as a provider, and the test bundle as a consumer.

https://github.com/Tibor17/junit/blob/571b6ee375da26ce1f41ebcd58a200bd788040e2/src/test/java/org/junit/it/osgi/OSGiITCase.java

The consumer as a test bundle has activator and there are the test assertions, see the headers for consumer src/test/resources/META-INF/MANIFEST.MF. The test fails as soon as the bundle(s) fail to start due to an assert in TestActivator. In the activator we attempt to load the JUnitCore and run a dummy test, loading resources, testing symbolic names, asserting that the Junit classes are loaded by Framework ClassLoader.
https://github.com/Tibor17/junit/blob/424526cf8b83e8d80c3fe622fa3b61cf58e6231d/src/test/java/org/junit/it/osgi/TestActivator.java

Contributor

Tibor17 commented Apr 5, 2013

@rgrunber
@hstaudacher
Can you comment or vote for OSGi on the top of JUnit if you are still available to GitHub?
I found your comments in related issue in #212.
In last two comments in this pull, you can see that BND in pom.xml generates osgi headers in manifest, and integration test proves the generated manifest in junit-4.12-SNAPSHOT.jar.

Contributor

Tibor17 commented Apr 9, 2013

I have talked with @cschneider on email and improved one minor in previous commit.
The thing is that here we will use OSGi Container Karaf to prove the OSGi headers are set correctly.
We will expect only junit packages are exported with no JUnit internal packages and no Hamcrest.
Unexported packages are still contained in the JAR but some OSGi consumer like integration test will not see them.

Let's proceed with these test steps:

  • Build and install JUnit as Maven artifact into your local maven repo: mvn install
  • Install the artifact in Karaf container: karaf@root> osgi:install -s mvn:junit/junit/4.12-SNAPSHOT

Karaft printed bundle ID in console: Bundle ID: 54

  • Let's check what osgi packages are exported out of JUnit bundle: karaf@root> exports 54

Although physically all packages are inside of the library, the Karaf has printed these packages visible for other OSGi consumer to use (rest is internal use):

ID Packages
54 junit.runner; version=4.12.0.SNAPSHOT
54 junit.textui; version=4.12.0.SNAPSHOT
54 junit.extensions; version=4.12.0.SNAPSHOT
54 junit.framework; version=4.12.0.SNAPSHOT
54 org.junit.experimental.theories.suppliers; version=4.12.0.SNAPSHOT
54 org.junit.experimental.theories; version=4.12.0.SNAPSHOT
54 org.junit.experimental.categories; version=4.12.0.SNAPSHOT
54 org.junit.runner.manipulation; version=4.12.0.SNAPSHOT
54 org.junit.rules; version=4.12.0.SNAPSHOT
54 org.junit.runner; version=4.12.0.SNAPSHOT
54 org.junit.runners; version=4.12.0.SNAPSHOT
54 org.junit.matchers; version=4.12.0.SNAPSHOT
54 org.junit.runner.notification; version=4.12.0.SNAPSHOT
54 org.junit.experimental.results; version=4.12.0.SNAPSHOT
54 org.junit.experimental.max; version=4.12.0.SNAPSHOT
54 org.junit; version=4.12.0.SNAPSHOT
54 org.junit.experimental.runners; version=4.12.0.SNAPSHOT
54 org.junit.experimental; version=4.12.0.SNAPSHOT
54 org.junit.runners.model; version=4.12.0.SNAPSHOT

One can see that no internal JUnit packages (org.junit.internal, org.junit.experimental.theories.internal) and no Hamcrest packages org.hamcrest are listed.

This is expected result!

I have talked with OSGi group on LinkedIn that JUnit as an OSGi bundle would simplify the world in springsource. The same was mentioned for eclipse in #212.

I just checked out the junit.mavenize2 branch of @Tibor17 . I can reproduce the results he mentions. The problems I saw before were because I used the wrong branch junit.mavenize.

So this looks really good. From my side this is ready to go.

@dsaff dsaff and 1 other commented on an outdated diff Apr 11, 2013

@@ -93,6 +95,12 @@
<artifactId>hamcrest-core</artifactId>
<version>1.3</version>
</dependency>
+ <dependency>
@dsaff

dsaff Apr 11, 2013

Owner

Can we add a comment about why this dependency is needed?

@Tibor17

Tibor17 Apr 11, 2013

Contributor

Done.

@dsaff dsaff and 1 other commented on an outdated diff Apr 11, 2013

<showDeprecation>true</showDeprecation>
<showWarnings>true</showWarnings>
- <debug>true</debug>
@dsaff

dsaff Apr 11, 2013

Owner

Why these changes?

@Tibor17

Tibor17 Apr 12, 2013

Contributor

Done. I reverted.

Reason why I removed forked attribute: After target build was clean, the forked javac failed. Embedded javac did not. Since I deleted my osgi activator class from main sources, the problem has gone. The debug=true was applicable only in forked javac.

@dsaff dsaff and 1 other commented on an outdated diff Apr 11, 2013

</configuration>
</plugin>
<plugin>
+ <!-- OSGi bundle in JAR archive -->
+ <groupId>org.apache.felix</groupId>
+ <artifactId>maven-bundle-plugin</artifactId>
+ <version>2.3.7</version>
+ <extensions>true</extensions>
+ <configuration>
+ <instructions>
+ <Main-Class>org.junit.runner.JUnitCore</Main-Class>
+ <Bundle-SymbolicName>org.${project.artifactId}</Bundle-SymbolicName>
+ <Bundle-Name>${project.name}</Bundle-Name>
+ <Bundle-Description>${project.description}</Bundle-Description>
+ <Bundle-Vendor>${project.organization.name}</Bundle-Vendor>
+ <Bundle-DocURL>${project.organization.url}</Bundle-DocURL>
+ <Bundle-Version>${project.version}</Bundle-Version>
+ <Export-Package>!org.junit.internal.*,!org.junit.experimental.theories.internal.*,junit.*;version="${project.version}",org.junit.*;version="${project.version}"</Export-Package>
@dsaff

dsaff Apr 11, 2013

Owner

I'm surprised this exports junit., but not org.junit.. I would have expected both or neither.

@Tibor17

Tibor17 Apr 11, 2013

Contributor

, but there are both.
Please move the slider to the right.
I will cut the line by " ".

@Tibor17

Tibor17 Apr 12, 2013

Contributor

Done.

@dsaff dsaff and 1 other commented on an outdated diff Apr 11, 2013

<enableAssertions>false</enableAssertions>
</configuration>
</plugin>
<plugin>
+ <!-- integration tests for OSGi bundle -->
+ <artifactId>maven-failsafe-plugin</artifactId>
+ <version>2.14</version>
+ <executions>
+ <execution>
+ <id>integration-tests</id>
+ <phase>integration-test</phase>
+ <goals>
+ <goal>integration-test</goal>
+ <goal>verify</goal>
+ </goals>
+ <configuration>
+ <includes>
+ <include>**/OSGiITCase.java</include>
@dsaff

dsaff Apr 11, 2013

Owner

Let's spell out IntegrationTestCase

@Tibor17

Tibor17 Apr 11, 2013

Contributor

Waiting for the GitHub repo proposal.

@Tibor17

Tibor17 Apr 12, 2013

Contributor

Done.
org.junit.it.osgi.IntegrationTestCase

@dsaff dsaff and 1 other commented on an outdated diff Apr 11, 2013

src/test/java/org/junit/it/osgi/OSGiITCase.java
@@ -0,0 +1,71 @@
+package org.junit.it.osgi;
@dsaff

dsaff Apr 11, 2013

Owner

I should apologize--I think you wrote this because I asked for it, but on second reflection, I don't want to add another compile-time dependency. Can we check this test into a different github repository (let me know if you need me to create one), and reference it from a document here.

Sorry.

@Tibor17

Tibor17 Apr 11, 2013

Contributor

Yes i will need your help. How can we do that since the maven-failsafe-plugin is directly calling this class from our pom.xml?
It is a test.

@Tibor17

Tibor17 Apr 14, 2013

Contributor

@dsaff
I am facing also another solution which I did in my branch junit.osgi still in the same repo but it is separated.

I would create dir src/it/osgi with pom.xml which is referencing this JUnit version via pattern @version@ and has test-scope compile-time dependency of Felix framework and IT case.
In JUnit pom.xml I would have to add profile integration-tests with maven-invoker-plugin which starts the src/it/osgi/pom.xml.
The src/it/osgi/pom.xml uses the JUnit artifact installed in local Maven repo of Maven artifacts and starts IT.
This means that the profile can be controlled, and of course the Cloudbees should use this profile as mandatory. The IT case with the dependency to Felix is in another src/it/osgi/pom.xml. Junit is not dependent on src/it/osgi/pom.xml and its dependencies, but opposite actually.
What's your opinion?

If you want to, we can discuss with Stephen Connolly.

@dsaff

dsaff Apr 15, 2013

Owner

Tibor,

That proposal sounds like a reasonable next step to me.

David

On Sun, Apr 14, 2013 at 11:15 AM, Tibor Digana notifications@github.comwrote:

In src/test/java/org/junit/it/osgi/OSGiITCase.java:

@@ -0,0 +1,71 @@
+package org.junit.it.osgi;

@dsaff https://github.com/dsaff
I am facing also another solution which I did in my branch junit.osgistill in the same repo but it is separated.

I would create dir src/it/osgi with pom.xml which is referencing this
JUnit version via pattern @Version@ and has test-scope compile-time
dependency of Felix framework and IT case.
In JUnit pom.xml I would have to add profile integration-tests with
maven-invoker-plugin which starts the src/it/osgi/pom.xml.
The src/it/osgi/pom.xml uses the JUnit artifact installed in local Maven
repo of Maven artifacts and starts IT.
This means that the profile can be controlled, and of course the Cloudbees
should use this profile as mandatory.
What's your opinion?

If you want to, we can discuss with Stephen Connolly.


Reply to this email directly or view it on GitHubhttps://github.com/junit-team/junit/pull/472/files#r3786042
.

@Tibor17

Tibor17 Apr 15, 2013

Contributor

@dsaff
I love consensus.

Owner

dsaff commented Apr 18, 2013

@Tibor17,

Sorry, GitHub's discussion interface sometimes leaves something to be desired. Where are we?

Contributor

Tibor17 commented Apr 18, 2013

@dsaff
I have good progress with moving the IT to other POM.
Improving and refactoring.
I will commit on Saturday.

Contributor

Tibor17 commented Apr 21, 2013

@dsaff
I have completed this task. Is it necessary to use ANT build in production and add there osgi headers as well?

Owner

dsaff commented Apr 22, 2013

@Tibor17,

Thanks for continuing to move forward. Unfortunately, this week is full of excitement in my non-JUnit life, so I'm going to have to postpone thinking hard about this until next week. Sorry,

David

Contributor

Tibor17 commented May 5, 2013

@dsaff
As I spoke with @cschneider , many frameworks may get you lost in the last commit and non-maven people. So I may revert the last commit and keep the simple IT as before. Anyway it would be very nice to write a section in Wiki about junit on the top of PAX upon this commit. The people do not have to discover the world if they read the wiki.

Contributor

Tibor17 commented May 11, 2013

@dsaff
Do you have some spare time to have a look this week?
Thx.

The question is if we will proceed with c072829 commit (one before the last), or the last one e155ec6.
For me it does not matter. The c072829 is simple enough for all. Release note is nice to have upon these ITs.

Owner

dsaff commented May 13, 2013

@Tibor17, this week is very busy, but the next should be much calmer. So by the end of next week sounds doable.

@Tibor17 Tibor17 referenced this pull request May 14, 2013

Closed

OSGi Proposal #515

Contributor

Tibor17 commented Jun 4, 2013

@dsaff
Can we go on with this? I can explain any details much faster on Skype.

@dsaff dsaff closed this Jun 4, 2013

@dsaff dsaff reopened this Jun 4, 2013

Owner

dsaff commented Jun 4, 2013

Sorry, accidental button push.

I won't have any time to consider this until I return from vacation late next week.

Contributor

Tibor17 commented Jun 19, 2013

@dsaff
Hi David, are you ready now?

Owner

dsaff commented Jun 20, 2013

@Tibor17, I'm sorry, I don't think I have the bandwidth to understand a change of this size at this point. I'd like to prioritize some of the other pull requests, with source-level changes, before continuing down this path.

Contributor

Tibor17 commented Jun 21, 2013

@dsaff
What about to do it this way that I would submit a new pull without any integration test. We will commit and update the wiki.
Since the tests are difficult for you to understand, much later they would come in another pull if any.

Owner

dsaff commented Jun 21, 2013

@Tibor17, fine, if you still have the time to spend on it, let's see what that looks like.

@Tibor17 Tibor17 referenced this pull request Jul 2, 2013

Closed

Added BND plugin in pom.xml #701

Contributor

Tibor17 commented Jul 18, 2013

@cschneider
@hwellmann

Please pay attention in this JUnit pull request with OSGi headers in JUnit bundle.
The JUnit committer closed another very trivial pull #701 which was about exactly the same solution having no integration tests.

I can clearly see that this pool can be closed with the same arguments as in #701.
So I am leaving this pull to be managed by @cschneider , @hwellmann and @dsaff .

I am +1 for this pull request. Though I favor the simpler aproach of #701 without integration tests.

@hwellmann hwellmann and 1 other commented on an outdated diff Jul 25, 2013

-->
<artifactId>maven-surefire-plugin</artifactId>
- <version>2.12.3</version>
+ <version>2.14.1</version>
@hwellmann

hwellmann Jul 25, 2013

2.15 is current. 2.14.1 munges names of failed tests AFAIK.

@Tibor17

Tibor17 Jul 25, 2013

Contributor

Done

@hwellmann hwellmann commented on the diff Jul 25, 2013

src/it/osgi/pom.xml
+ <junitVersion>${project.version}</junitVersion>
+ <jdkVersion>1.5</jdkVersion>
+ <project.build.sourceEncoding>ISO-8859-1</project.build.sourceEncoding>
+ <project.reporting.outputEncoding>ISO-8859-1</project.reporting.outputEncoding>
+ </properties>
+
+ <dependencies>
+ <dependency>
+ <groupId>junit</groupId>
+ <artifactId>junit</artifactId>
+ <version>${junitVersion}</version>
+ </dependency>
+ <dependency>
+ <groupId>org.osgi</groupId>
+ <artifactId>org.osgi.core</artifactId>
+ <version>5.0.0</version>
@hwellmann

hwellmann Jul 25, 2013

You should add scope = provided. You don't want the API JAR and an implementation like Equinox on the classpath at the same time.

@Tibor17

Tibor17 Jul 25, 2013

Contributor

Done

@hwellmann hwellmann and 1 other commented on an outdated diff Jul 25, 2013

src/it/osgi/pom.xml
+ <artifactId>org.apache.felix.framework</artifactId>
+ <version>4.2.1</version>
+ <scope>test</scope>
+ </dependency>
+ <dependency>
+ <groupId>org.eclipse.tycho</groupId>
+ <artifactId>org.eclipse.osgi</artifactId>
+ <version>3.9.0.v20130305-2200</version>
+ <scope>test</scope>
+ </dependency>
+ <dependency>
+ <groupId>org.knopflerfish</groupId>
+ <artifactId>framework</artifactId>
+ <version>5.3.3</version>
+ <scope>test</scope>
+ </dependency>
@hwellmann

hwellmann Jul 25, 2013

So there are 3 OSGi frameworks on the classpath. Most of the time, this causes conflicts, at least with Equinox signed JARs. Better use Maven profiles to include one framework at a time.

@Tibor17

Tibor17 Jul 25, 2013

Contributor

Right, and additionally I have to change version of Pax from 3.x to 2.x, because the version 3.0.3 is built with JDK 1.6 and JUnit is using 1.5 in the CloudBees buildprocess.

See about the profiles in the next comment.

@hwellmann hwellmann and 1 other commented on an outdated diff Jul 25, 2013

src/it/osgi/pom.xml
+ </execution>
+ <execution>
+ <id>it-felix</id>
+ <phase>integration-test</phase>
+ <goals>
+ <goal>test</goal>
+ </goals>
+ <configuration>
+ <forkCount>1</forkCount>
+ <includes>
+ <include>**/PaxIT.java</include>
+ </includes>
+ <classpathDependencyExcludes>
+ <classpathDependencyExclude>org.eclipse.tycho:org.eclipse.osgi</classpathDependencyExclude>
+ <classpathDependencyExclude>org.knopflerfish:framework</classpathDependencyExclude>
+ </classpathDependencyExcludes>
@hwellmann

hwellmann Jul 25, 2013

Ah ok, so this is how you deal with multiple OSGi frameworks. Seems to work in this case, but in general I think the profile approach is to be preferred, especially when other artifacts depend on yours and might get too many transitive dependencies.

@Tibor17

Tibor17 Jul 25, 2013

Contributor

Good remark.
This is not main POM. It's used for ITs only, so I think people won't to inherit it.
At the time I designed the ITs I used profiles, but the problem was that JUnit build process has to run at once and it has to run all profiles altogether like -P p1,p2,p3. The problem was that the dependencies, and surefire-plugin configurations were merged which was unuseful. So I tried to extend executions in maven-invoker-plugin of the main POM, but it was huge and even unacceptable by the community I know. Since the plugin's dependencies are valid for all executions of surefire-plugin, this solution was the only way.

@hwellmann hwellmann and 1 other commented on an outdated diff Jul 25, 2013

...it/osgi/src/test/java/org/junit/it/ServiceLoader.java
@@ -0,0 +1,69 @@
+package org.junit.it;
+
+import java.io.BufferedReader;
+import java.io.IOException;
+import java.io.InputStreamReader;
+import java.net.URL;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Enumeration;
+import java.util.Iterator;
+
+/**
+ * Substitutes Java 1.6 ServiceLoader. Used in integration test {@link FrameworkIT}.
+ * Loads OSGi framework as a service implemented by some OSGi vendor - currently Felix.
@hwellmann

hwellmann Jul 25, 2013

Why "currently Felix"? Is it not the main point of the ServiceLoader to discover any appropriate service on the classpath?

@Tibor17

Tibor17 Jul 25, 2013

Contributor

Done
The message - currently Felix appeared when Pax was not in the project. Yes the ServiceLoader takes all services.
Note: We are operating on JDK 1.5 which does not have ServiceLoader in Java API. So this substitutes Java SL.

Contributor

Tibor17 commented Jul 27, 2013

@hwellmann
I submited profiles which looks nice, but I have a problem to find Pax 2.x version works in JDK 1.5.
The problem is that I am getting UnsupportedClassVersion Bad version number in .cla... in Pax 2.6.0 - 2.4.0. I think it is because of Guava 10 built with JDK 1.6. The latest Pax which uses Guava (r09) built by JDK 5 version is Pax 2.3.1 but it has issue PAXEXAM-291.
So what is the latest working Pax version which would work for us with JDK 1.5?

Pax Exam uses java.util.ServiceLoader ever since 2.0.0, and this requires a Java 6 Runtime. Earlier 2.x releases may have had Java 1.5 source or target compatibility defined in the POM, but that was misleading anyway.

In short, even if JUnit is compiled with 1.5 source and target level, you need a 1.6 or 1.7 runtime to test it with Pax Exam 2.x or 3.x in an OSGi environment.

Contributor

Tibor17 commented Jul 27, 2013

@hwellmann
Ok, I will try to find my code backup with Pax 1.x and use it.

+1 for Junit as OSGi bundle

Contributor

Tibor17 commented Aug 3, 2013

@hwellmann
Sorry for the delay. I used the same test code with Pax 1.2.4 at Java 5. The problem is that Pax 1 uses JUnit classes within com.springsource.org.junit which is in conflict with our JUnit library. The root cause of failed IT is that org.hamcrest.core.IsCollectionContaining cannot be loaded.
Is it possible to use some syntax to exclude Bundle-SymbolicName: com.springsource.org.junit from the container?
If not, then I have to keep only the pure OSGi-Framework tests.
Anyway I was glad that Pax 3.x was working nicely with Java 6.

Contributor

pholser commented Aug 5, 2013

+1 for Junit as OSGi bundle

+1 for Junit as OSGi bundle

Owner

dsaff commented Sep 17, 2013

I'm closing this for now. I know that it's close to some of your hearts. Let's continue the discussion, if there's new points to be raised, on the mailing list, but leaving this as an open pull request isn't going to move things forward. Thanks.

@dsaff dsaff closed this Sep 17, 2013

sarxos commented Nov 13, 2013

👍

It's very annoying when one have to generate OSGi bundle from JAR and put again in Maven repo - it's much better to have it already bundled in The Central Repository. We had to did this with many artifacts for our previous project, it was a pain.

Contributor

Tibor17 commented Nov 18, 2013

@sarxos
I agree with you. Several people here vote for this feature. The people on LinkedIn agreed with this request as well.
I am open for maintaining this feature in the future. Unfortunately I do not have commiter's rights to push this pull request in GitHub.

Owner

dsaff commented Nov 20, 2013

OK, I can make a deal. We need to get JUnit 4.12 out the door, but I don't have the day-to-day time to see it through, the masterful way that @marcphilipp did for JUnit 4.11.

If someone would volunteer to be release master for JUnit 4.12, producing betas, updating documentation, uploading jars, etc., who also wants to see the OSGi metadata changes, then I'd be willing to agree to the future maintenance of the OSGi metadata in exchange for the release help now.

Anyone want to step up?

Contributor

Tibor17 commented Dec 2, 2013

@ALL
I was quite for some time. Happy of moving the new release ahead.

In #805 I added the Equinox-specific header Eclipse-BuddyPolicy: dependent.
Could this be added here as well?

@kcooney kcooney referenced this pull request Apr 19, 2014

Closed

No version in manifest #878

lonniev commented Jan 5, 2015

One year later, Happy New Year, and is there available an OSGi bundle at a public p2 site that has both junit 4 and hamcrest all included? This doesn't have to be bleeding edge recent, anything within ~2 years would probably be fine.

(I can bundle up my own bundle but seek the convenience of leaving this outside the scope of what my project has to actively manage.)

There are OSGi bundles for JUnit on Maven Central:

<dependency>
    <groupId>org.ops4j.pax.tipi</groupId>
    <artifactId>org.ops4j.pax.tipi.junit</artifactId>
    <version>4.12.0.1</version>
</dependency>

<dependency>
    <groupId>org.ops4j.pax.tipi</groupId>
    <artifactId>org.ops4j.pax.tipi.hamcrest.core</artifactId>
    <version>1.3.0.1</version>
</dependency>

No p2 support and not hamcrest-all, but maybe that helps.

lonniev commented Jan 6, 2015

@hwellmann thanks--but, no, the key need is for the existence of the hamcrest-all packages as an OSGi bundle if only within a public p2 site. For any situation outside that scope, it is trivial to construct a local solution. The point is to avoid having to construct that local solution so that I and my team can remain focused--or, rather, return to a focus--on developing business logic versus maintaining packages for third-party capabilities.

(For the meantime, I took the pragmatic approach of simply adding yet another maven sub-module Tycho eclipse-plugin project to our project to bundle up the necessary hamcrest-all packages and of pushing that to our internal maven and p2 sites. Sigh.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment