Junit should be an osgi bundle

cschneider commented 13 years ago

I sometimes use junit assertions even in production code to make sure no invalid data slips through. As some of my applications run under osgi it would be very handy if junit already was a valid osgi bundle.

As far as I can tell it would only be necessary to switch the to packaging in the pom to bundle and add the maven bundle pllugin. I can provide a patch if that helps.

Christian

dsaff commented 13 years ago

What do you have to do today?

cschneider commented 13 years ago

There is a junit bundle from servicemix. It think it would be better if this was not necessary though

hwellmann commented 12 years ago

All OSGi projects that depend on a JUnit OSGi bundle would benefit if this issue was fixed, making all inofficial osgified JUnit versions obsolete, e.g. the Apache Servicemix version mentioned by Christian, or the com.springsource.org.junit version from the SpringSource Enterprise Bundle Repository (which is what we use in the OPS4J Pax Exam project).

These inofficial versions always lag behind the official releases, and it would be much easier to solve the issue at the root.

I've modified the build.xml Ant script to build the JARs with the bnd tool which generates the required OSGi manifest headers.

Converting the build process from Ant to Maven and using the maven-bundle-plugin would be more elegant, and there would be no need to commit any external JARs - but that's another story and not a prerequisite for this issue.

I'll send a pull request for my fix.

Best regards, Harald

Tibor17 commented 12 years ago

+1

Christian, by using the OSGi you additionally mean a better modularity for the JUnit as well?

This means to split current JUnit in to a separate artifacts for open-and-closed modules. These can be then reused by the JUnit framework itself, and other frameworks as well with no harm to the JUnit as a whole.

hwellmann commented 12 years ago

Let's keep things simple... Modularization of JUnit itself is an interesting point, but a completely differerent story.

The only external dependency JUnit currently has is Hamcrest. My pull request takes care both of junit.jar and junit-dep.jar, adding OSGi headers to both. The second variant imports org.hamcrest.* packages, so you can use your own Hamcrest bundle (e.g. the one from SpringSource EBR) along with the junit-nodep bundle.

cschneider commented 12 years ago

@Tibor17 To have a simple bundle would be enough for me

rgrunber commented 12 years ago

I think this would really benefit OSGi bundle consumers. I noticed the Bundle-SymbolicName proposed is "junit". There are probably different standards used by consumers, but I see that Eclipse ships junit with a Bundle-SymbolicName of "org.junit". This can be seen here : http://download.eclipse.org/tools/orbit/downloads/drops/R20120119162704/ . Are there any objections to using "org.junit" as opposed to "junit" ?

cschneider commented 12 years ago

org.junit sounds good. The typical symbolic name is the package name of the top level package so that matches.

hwellmann commented 12 years ago

Any name is fine, I just took the official artifact name for my pull request.

Using the official reverse domain name should be reserved to the original developers, so think it's bad practice of Eclipse to use org.junit for their non-official osgified version of JUnit.

BTW, I wish someone from the JUnit dev team would comment on this issue. Even a "no thanks" is better than no reply at all.

We're currently planning to set up a platform for osgified third-party libraries at OPS4J (see http://team.ops4j.org/wiki/display/ops4j/Pax+Tipi), and JUnit and Hamcrest are likely to be the first libs to be repackaged and pushed to Maven Central using that channel.

dsaff commented 12 years ago

Hey, I'm a dev. I'm not an OSGi consumer, but a patch that had consensus from concerned parties in the community, and some test that maintainers could run in the future to make sure that the OSGi-specific packaging was not broken before releases, would be welcomed.

hstaudacher commented 12 years ago

Does the JUnit team consider to make JUnit an OSGi bundle? It seems that there is no progress on this issue since 3 month. I'm just curious because I have the same opinion as the commenters before. Making JUnit a bundle would really ease the consumption of it.

dsaff commented 12 years ago

@hstaudacher, there's been a lot of continued discussion over at issue #368. Thanks for reminding me to link it in here.

Tibor17 commented 12 years ago

@cschneider @hwellmann In #368 we agreed that we want to start mavenization in a separate request., So in #472 @dsaff asked me to update the template of pom by adding maven-bundle-plugin into it. May you have a look there, and confirm that this would meet your needs? We should discuss new steps with mavenization and osgi bundle as well.

cschneider commented 12 years ago

Where do I find the pom? It does not seem to be in master

Tibor17 commented 12 years ago

@cschneider this is template https://github.com/Tibor17/junit/commit/d8ace9ebd730126bc08a070a3d5495b7f675217c

Tibor17 commented 12 years ago

@cschneider @dsaff @hwellmann I pushed first build process ith maven and osgi bundle https://github.com/Tibor17/maven/commit/1251b2a197f6de45ba0b232335af92de665c4d28 to my public repo.

Just copy to KentBeck repo from https://github.com/Tibor17/maven/tree/master/junit.mavenize/

and type make config clean install test or make all all: If you have credentials to remote server (sonatype).

Would you comment on this?

You can now see OSGi meta info, deployed to a remote server. If you want to try out the deployment, you may rewrite the link https://oss.sonatype.org/service/local/staging/deploy/maven2 to your own, and use your credentials in settings.xml

Additionally, the build process asked you to type a new junit versiom, and GnuPG keypass.

marcphilipp commented 12 years ago

@Tibor17 I've only had time to skim through the POM which IMHO, as most POMs, looks rather lengthy and confusing. But that is not your fault, it's Maven's. That said, we should really double-think whether it makes sense to ditch the Ant build script which is also not nice but at least readable and much more flexible.

Another thing I noticed: Why is there a Makefile? Maven alone is bad enough, don't get me started on Makefiles...

How about moving to something like Gradle?

Tibor17 commented 12 years ago

@marcphilipp the other Mvn projects like in org.apache are also lengthy. On the other side, the positive mark is that there is a big Maven community. I am aware of the size, and i found a way to make pom.xml a bit shorter (Version.java). I know how to decrease the size by 40-50% more by ignoring junit:junit-dep. I really hate using junit-dep in Maven central repo and this is extra work for me to integrate it into my build process (b.p.). But removing junit-dep would help in POM and Makefile in Linux or batch scripts in Windows as well. I am not alone saying that junit-dep should be renamed to junit if in Maven central. Additionally, sourceforge users may enjoy Hamcrest embedded in junit library, instead.

We understood in #368, that this would be the way to use Maven.

Last few days i prepared simple intergation tests only for JUnit.

There regarding OSGi i understood that the JUnit is going to be a bit more complex with OSGi and we would need integration tests which makes the build longer but more bullet-proof.

This is what we need -long lasting technology that many people use, providing us with integration tests. This is it, that the owner of the framework has to declare that his 'library' can be used in real environment and how.

And there i can see the difference between build processes which libraries have simple behavior with simple deployment, and a pure test abilities; and other build processes which produce widely used libraries, with miscelaneous deployment, desirable tests.

The JUnit is a framework been used in many many products and i am confident that Maven is the right tool to use together with the OSGi. Additionally, the current user may not recognize that we changed the build process.

Pls try to filter out this vision, whether i like/dislike long script, because it is not important right now. The JUnit with OSGi will be more challanging than JUnit alone without OSGi, and therefore it will have its own complexity.

We are in very early stage of development of junit bundle and the build process as it exists now in my repo is only trying to verify whether we are able to provide a compatible outcome with ant-based b.p.. IMHO we are able to do that and again the users should not see the difference that we change the b.p.

@dsaff Pls bring some comments here. I tried to be honest about JUnit + OSGi + Maven. @marcphilipp, @cschneider are you able to run the POM? Do you have any problem with that? Can you use it in IDE and can you compare the .jar and .zip against ant?

Tibor17 commented 11 years ago

@cschneider The JUnit is dependent on Hamcrest, thus the Hamcrest should be OSGi bundle as well. @cschneider pls confirm. Do we need OSGi Activator and Services in JUnit? I am writing integration tests. Would you like to provide your specific ones?

cvanes commented 11 years ago

I don't see any harm in having an OSGi manifest provided in junit jar(s) but is it a good idea to use junit assertions in production code?

Tibor17 commented 11 years ago

@cvanes what exactly u mean?

leadVisionary commented 11 years ago

@Tibor17 : I believe @cvanes comment was in response to a rather bad practice by the original op.

I have to agree with @marcphilipp here. You've taken a valiant attempt, @Tibor17 , but this POM is not in great shape to integrate into JUnit right now. It is simply too big, too much going on.

OSGi-ifying the Mavenized JUnit project should be fairly trivial, given a Mavenized project. Mavenizing JUnit should be a separate task. I'm going to take a swing at it on my local branch.

A streamlined JUnit mavenized project should probably focus on making a multi-module project

Something like:

junit-core (featuring the basic Assert, TestSuite, and core functionality)
junit-extensions (featuring things like Theories which most users of JUnit don't use)
junit-legacy (using junit framework as to split apart backward compatability support for future extensibility).

With a Super POM that has the basic, good stuff (mailing list, developers, metadata, etc)

Distribution should probably be a separate project, with its own Maven stuff (refactoring wagon and the upload to SourceForge out there) that pulls in JUnit as a dependency.

For a similar example, check out the Apache ServiceMix POM

I submit that it's probably better to move to one unified build system, rather than trying to maintain support for Make, Ant, and now Maven. it confuses the project and adds clutter. If Maven is the build/dependency management system of choice(as seems to be rising in the Java community), then we should convert/eliminate current build processes into a Maven equivalent form and remove the makefiles/build.

Also, It is NOT JUnit's concern to produce a hamcrest bundle. That's violating dependency encapsulation from a project scope level. That should be within the hamcrest project's concern, and done by hamcrest developers/within that project. The reference to hamcrest within the POM should be a simple

<dependencyManagement> 
<dependency>
<groupId>org.hamcreat</groupId>
<artifactId>hamcrest-core</artifactId>
<version>${hamcrest.version}</version>
</dependency>
</dependencyManagement>

And live only in the POMs that use it.

Tibor17 commented 11 years ago

I opened JUnit mavenize in a separate pull request already, so we may discuss the mavenization there.

Regarding the assertions in production code, other test frameworks built on the top of the junit.

Yes of course, separating the project to modules would be nice idea but the current directory layout is simple and not ready for multi module project. There are also best practices for big projects with POM dedicated to distribution and dependency management, configuration, etc. The thing is whether we should separate packages to modules. Nowadays the users have one simple bundle with 165 classes in it.

marcphilipp commented 11 years ago

IMHO, before we continue, we should get the following questions answered:

How can JUnit be an OSGi bundle if Hamcrest is not? Do we simply import the package in the manifest and hope for the best? What about the Maven dependency?
How are you going to use the bundle? In particular, which Maven OSGi plugin shall be used? Apache Felix or Eclipse Tycho? Why?

@cschneider @hwellmann @rgrunber @hstaudacher Can you please provide some guidance on these questions?

Tibor17 commented 11 years ago

@marcphilipp From my point of view:

for junit the Hamcrest should be injected into junit jar. For junit-dep the Hamcrest is another bundle and different Export-Package attribute in manifest. Therefore due to simplifying the design, single library in junit project without embedded Hamcrest needs to be considered -like junit-dep.
i decided for Felix (maven based, popular in Java community, future Java modularity got the inspiration from Felix), not Tycho Eclipse because it is Eclipse plugin and i needed a complete support for integration tests so therefore Felix.

cvanes commented 11 years ago

@leadVisionary @Tibor17 yes, that's what I was getting at, I don't think testing tools should be used in production code. Instead an assertion API, DSL etc could be written for the data being validated.

Tibor17 commented 11 years ago

@cvanes what would make sense for osgi is the scenario junit 3.8.x in ClassLoader 1, junit 4.7 in ClassLoader 2, junit 4.8.x in ClassLoader 3 within a test application/framework, e.g. thousands of legacy tests altogether with new ones in runtime. Then also combining junit modules, as @leadVisionary mentioned, of miscelaneous versions been still compatible. Yes i agree, normally should not be in production code.

rgrunber commented 11 years ago

@marcphilipp

I agree with @Tibor17. It would be ideal if the build generated a junit that packages hamcrest, and another that strictly depends upon it in the OSGi sense, which I believe is what existed for the ant builds. At least this way consumers could choose. I think a bug should probably be opened against hamcrest to have them provide their own OSGi metadata, just as was done here.

In Fedora, the build will probably be done with Tycho, to be as close to how Eclipse projects intend to do their builds. Basically, there's an effort in the Eclipse Foundation to build the platform and have projects building in a more formalized way (see http://wiki.eclipse.org/CBI)

Tibor17 commented 11 years ago

@rgrunber well, junit with embedded hamcrest in maven central is un-maven style (and other reasons), and i think there is an activity to simply spoken 'rename' junit-dep to junit. Maybe the consumers should fabricate the library together with hamcrest, after that change...

In fact, the junit library not having embedded hamcrest classes would require osgi on hamcrest side -that's kind of limitation, so i am using only embedded hamcrest in my private development :(.

If i remeber well, the maven 3.1 would leave the classworld library and use osgi felix instead. Nevertheless the only extra maven dependency in my design is org.osi:org.osi.core:4.3.0 built by jdk 1.5 as an API independent of implementation, so i used felix only for testing purposes and making a bundle.

dsaff commented 11 years ago

Doh. Didn't mean to close, sorry!

dsaff commented 11 years ago

Has anyone asked if Hamcrest would consider OSGi?

marcphilipp commented 11 years ago

I tried to take a step back and think in terms of who wants to use JUnit and in which way. Here are my thoughts. Please feel free to correct me or ask questions if anything is not clear.

We have (at least) the following existing use cases:

Maven users with jar dependencies to JUnit.
- From 4.11 on there will only be junit:junit which does not include Hamcrest but declares a dependency to it.
- The old junit:junit-dep simply points to junit:junit.
Non-Maven users who simply want to download an all in one jar.
- That's what junit.jar is for.
Non-Maven Java users that want to use a different (newer) version of Hamcrest with JUnit.
- They can download junit-dep.jar and use their custom Hamcrest JAR.

Adding support for OSGi will not replace any of these use cases but rather add new ones:

Apache Felix Maven Users want a bundle artifact version of JUnit.
- Open Question: Can this be the same Maven artifact?
Non-Maven OSGi users want to use an all-in-one OSGi bundle version of JUnit.
- Here, we could package Hamcrest into the same JAR.
Non-Maven OSGi users want to do it right and use an OSGi-like bundle that declares a dependency to a Hamcrest package that comes from some other (unspecified) bundle.

We should definitely think about which ones of these we need to support.

Thinking about solutions:

2 and 3 could be solved by shipping OSGi manifests in junit.jar and junit-dep.jar. They do not require a Maven build, we could simply write the manifest ourselves or use the Ant bnd plugin to do it. Regular JUnit users would not be affected by the modified manifest.
For 1 it would make sense to have a Maven build process like the one @Tibor17 has sketched in #472. Here, we have to make sure that we will not affect regular Maven users.

Tibor17 commented 11 years ago

@marcphilipp Can you additionally uncover the plan for junit-dep as well, and the zip deployed to sourceforge? Shall all the users of all-in-one JAR point to the jar on sourceforge after 4.11?

For the open question in 1, the packaging: bundle belongs to the default maven life cycle wider than jar. So i have more possibilities to utilize these phases. Thx

leadVisionary commented 11 years ago

In theory, an OSGI-INF manifest could be created by hand and added to the project to bundle-ize it (the "easiest win" solution, with hamcrest as a private package and export packaging the org.junit namespace)

In practice, JUnit, as it currently stands, is a fairly simple project -- only one external dependency and a bunch of classes. It is desperately in need of cleanup/restructuring, but it seems perfectly fair to rely on a Maven plugin to do it.

As the Apache Felix plugin is based on BND and creates OSGi bundles that work well in Felix and Equinox (personal experience) and I suppose Knoplerfish (second hand), I'm not sure if it makes sense to worry about different OSGI bundle creation tools unless there's an explicit need for the way one tool does something that the others don't.

Nevertheless, JUnit is a long running project with uses in probably over 90% of the Java community. I'm not sure I would make the root POM's packaging an OSGi bundle. It seems like there should be different POMs/build profiles for the consumers of different variants of JUnit.

As Maven offers such functionality, it seems like it should be a separate issue to consolidate the build process as well. Maintaining some pseudo-hybrid Ant/Maven project with shell scripts for builds and profiling is complex and complicated. Converging to one unified, modern build system will simplify things, clean up, and provide a pathway for future extension and sophistication.

To me, it seems like the big question is whether JUnit wants to be a Mavenized project. If it does, it should leverage Maven for what it does best: automating build process, dependency management, and leveraging plugins to simplify tasks like making an OSGi bundle.

If not, then perhaps Ivy should be used for dependency management rather than embedding hamcrest directly. Gradle could be tried, as well.

If it does, then this is really a sub-task of the mavenization issue, as this can easily be handled by an osgi/ subproject/build profile in the distribution POM. In which case, I would advise more deliberation on how best to mavenize JUnit.

dsaff commented 11 years ago

JUnit wants to be mavenized, probably. The main hesitation is non-technical; until recently, I was the only maintainer and user of the build sytem, and while I believe that maven is a technical step beyond ant+bash, it wasn't an area of expertise for me, and I didn't feel it would benefit the community for the project to be in maven, but unbuildable, while I blundered about learning on the job.

I'm feeling like there's a community building in this thread of people who have a pretty good grasp on what would need to happen to get JUnit to relying on maven. Would some of you also be willing to go "on call" for a year or so, willing to step in and fix the build system if a well-meaning but dull maintainer like me approves a well-meaning but half-baked patch that breaks something?

Given that, I'd say let's definitely prioritize first getting into maven, and then figuring out OSGi (which seems to be at least one point of potential consensus?) How does that sound?

leadVisionary commented 11 years ago

@dsaff : I'd be happy to help out with migrating and support for mavenization and other technical issues. We probably want to make sure that our half-baked patches don't break working functionality by using Jenkins as well and running our JUnit regression tests. ;) I'd be happy to help with that too.

I agree with your proposal: I think once the mavenization is complete, the OSGi piece will be fairly trivial.

Tibor17 commented 11 years ago

@dsaff I am open for supporting the JUnit for years. I would be happy to cooperate with you, @leadVisionary , and all others of course. In my daily job i am helping out the teams using maven, so i would be glad to continue the development in junit project as well.

I agree with @leadVisionary approach that mavenization in the first step, osgi in second step.

dsaff commented 11 years ago

@leadVisionary, I'd love to see some continuous integration. Is there a hosted service (I've looked at CloudBees in the past) that would work well?

marcphilipp commented 11 years ago

@dsaff Regarding continuous integration: I have played with CloudBees a while ago and even setup a build for JUnit on my public instance for another open source project: https://projectusus.ci.cloudbees.com/job/JUnit/

marcphilipp commented 11 years ago

Can you additionally uncover the plan for junit-dep as well, and the zip deployed to sourceforge? Shall all the users of all-in-one JAR point to the jar on sourceforge after 4.11?

@Tibor17 AFAIK nothing will change for non-Maven users, the JARs and the ZIP will be downloadable from GitHub and SourceForge as usual. Was that your question?

dsaff commented 11 years ago

@marcphilipp, fantastic. Based on your experience, would CloudBees be a good fit? Can it upload SNAPSHOT artifacts, etc?

Tibor17 commented 11 years ago

@marcphilipp thx for answer

marcphilipp commented 11 years ago

@dsaff I haven't used CloudBees for anything more than continuous integration yet. But from the documentation it looks like deploying & signing artifacts is supported.

I have opened a new issue where we can collect ideas regarding a build server: #516.

Tibor17 commented 11 years ago

Continuing in #472.

mohitkgupta commented 11 years ago

+1

kcooney commented 10 years ago

FWIW: here's the bug for making Hamcrest an OSGi bundle:

https://github.com/hamcrest/JavaHamcrest/issues/11

I personally don't think we should consider working on making JUnit an OSGi bundle until there is a released version on Hamcrest that supports OSGi.

Tibor17 commented 10 years ago

@kcooney The JavaHamcrest is already dead. There the committer does not communicate with the community :(

kcooney commented 10 years ago

@Tibor17 That's unfortunate, but it doesn't make sense to have JUnit use OSGi if Hamcrest doesn't.

hwellmann commented 10 years ago

That's not a valid point. There's an OSGified version of Hamcrest (and JUnit) in Maven Central (see org.ops4j.pax.tipi:org.ops4j.pax.tipi.hamcrest.core:1.3.0.1) which users can configure as a drop-in replacement for the official Hamcrest artifact at their own discretion.

Including OSGi headers in the official JUnit artifact would reduce the number of non-official workaround artifacts by one.

BTW, what about "Release early, release often"? The last JUnit release was on 14-Nov-2012.

kcooney commented 10 years ago

Apparently github ate my comment

@hwellmann to use org.ops4j.pax.tipi:org.ops4j.pax.tipi.hamcrest.core would we need to change our pom.xml, or would our users override the dependency (I'm guessing with an exclusion)? If it's the latter, wouldn't it cause problems for the junit jar to have a manifest that specifies dependencies on a jar that is different than the one specified via our pom.xml?

As for when JUnit 4.12 will be released, you can follow along at #868

junit-team / junit4

Junit should be an osgi bundle #212