Maven project file for JUnit as OSGi bundle #472
Conversation
|
Looks interesting. Can you get one of the reporters of the original OSGi bugs to confirm that this would meet their needs? Thanks. |
|
What about the junit-dep POM? Shouldn't it also be updated? |
|
@marcphilipp |
|
@Tibor17 Sure, I can take a look in the next couple of days. Just ping |
|
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 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 The deployment to sourceforge creates junit/junit/ directories which I will fix next days. There are few things to discuss and we i expect different opinions..., but i had to make some decisions in pom.xml |
| <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> |
There was a problem hiding this comment.
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.*.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@dsaff pls see my latest update.
How we would proceed next?
junit.* packages keep the latest version
|
This latest change is OK to my eyeballs. @marcphilipp, are you planning to take a look? |
| @@ -5,6 +5,7 @@ | |||
| <groupId>junit</groupId> | |||
| <artifactId>junit</artifactId> | |||
| <version>@version@</version> | |||
| <packaging>bundle</packaging> | |||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
- 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 Relocate Maven artifact "junit-dep" to "junit" #421 and 4.9 and 4.10 "junit" artifacts in Maven Central have hamcrest as dependency defined while in "junit" artifact the hamcrest classes are already included #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.
There was a problem hiding this comment.
@Tibor17 Good to hear! I think it might make sense to check-in those integration tests you setup. What do you think?
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
|
@dsaff @Tibor17 Please see my inline comment. |
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>
|
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 |
|
This is a good question. I mentioned an approach in other pull request, but it seems it was not clear. |
|
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? |
|
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? |
|
@dsaff |
|
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? |
|
@marcphilipp we need @cschneider as the reporter of # 212. |
|
@marcphilipp I am fine with deploying 4.11 first. |
|
OK, we'll tackle this again once 4.11 is out the door. Thanks, everyone. |
|
Explicitly added for consideration in the 4.12 milestone |
|
@dsaff |
|
Agreed that tackling #511 first is the right next step. |
|
For anyone following this, work continues in #511, FYI. |
|
I will insert the felix plugin to the new |
|
Please pay attention in this JUnit pull request with OSGi headers in JUnit bundle. I can clearly see that this pool can be closed with the same arguments as in #701. |
|
I am +1 for this pull request. Though I favor the simpler aproach of #701 without integration tests. |
| --> | ||
| <artifactId>maven-surefire-plugin</artifactId> | ||
| <version>2.12.3</version> | ||
| <version>2.14.1</version> |
There was a problem hiding this comment.
2.15 is current. 2.14.1 munges names of failed tests AFAIK.
|
@hwellmann |
|
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. |
|
@hwellmann |
|
+1 for Junit as OSGi bundle |
|
@hwellmann |
|
+1 for Junit as OSGi bundle |
|
+1 for Junit as OSGi bundle |
|
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. |
|
👍 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. |
|
@sarxos |
|
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? |
|
@ALL |
|
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: No p2 support and not hamcrest-all, but maybe that helps. |
|
@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.) |
Upon discussion #368, I created maven project file.
Other e.g. maven runtime environment, and script running pom.xml may come if necessary.