Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added BND plugin in pom.xml #701

Closed
wants to merge 1 commit into from
Closed

Conversation

Tibor17
Copy link
Contributor

@Tibor17 Tibor17 commented Jul 2, 2013

Added BND plugin in build file pom.xml which creates additional osgi headers in MANIFEST.MF.
Forged from #472 leaving the integration tests in #472.

@Tibor17
Copy link
Contributor Author

Tibor17 commented Jul 17, 2013

@dsaff
Can we concentrate on this pull?
We agreed in #472 that we will have only a change in pom.xml without integration tests.
This is about OSGi headers. Reminding that headers in manifest do not break the code, and the people in #472 voted as maintainers.

@dsaff
Copy link
Member

dsaff commented Jul 17, 2013

@Tibor17,

I'm not adding code to JUnit to support OSGi. I'm sorry I've spent so long coming to this decision--you've been motivated to spend a lot of time that I could have cut short with more decisiveness.

It took me a while to articulate why I'm uncomfortable with this. Moving from ant to maven decreased my own comfort with the build system and everything it's doing, but I felt pretty confident that the community at large was at least as comfortable with maven as with ant, and therefore, moving to maven was likely increasing the number of potential contributors who would be able to understand, improve, and protect against harmful changes to the build system. In general, having a large community who feel comfortable looking at any point of a codebase is of high value to an open-source project. This proposed change moves in the opposite direction.

OSGi is used in a small percentage of Java projects. As shown in #472 (comment), the efforts of the community who want JUnit bundled with OSGi are already more quickly and correctly served by that community maintaining its own bundling. As a reference point, we have to rebundle JUnit to our own internal packaging system at Google every time it's released.

Again, while I'm confident this is the right decision, I wish I had not taken so long, with so many pull requests, to state it firmly; your time is valuable, and I wasted it. I'm sorry.

@cschneider
Copy link

I am still +1 of adding this to junit. The change is quite simple and gives a lot of benefit to users with very little risk.

@njbartlett
Copy link

@dsaff You say that it took a while to articulate your reasoning. Unfortunately I don't think you have actually articulated it yet.

First, the request is not actually to add any code, it's about declarative headers in MANIFEST.MF. They are not code. If you read the JAR File Specification you will note that where an Application does not understand any header in the manifest it is required to ignore that header. Therefore adding OSGi headers to MANIFEST.MF has zero impact for non-OSGi users.

Second, while you're right that OSGi projects represent a small (though growing) percentage of Java projects, JUnit now lies in a small and shrinking set of projects that do not include their own OSGi metadata, and force users to repackage it. Google's need to repackage JUnit has no relevance to the discussion: Google's internal build system is proprietary whereas OSGi is an industry standard.

So you have a change which is literally zero risk; you have a contributor who has done all the work already; and you have a willing community of contributors who can maintain the change... and yet it's rejected. Baffling.

I'm only tangentially interested in this issue, as an OSGi user and advocate. I just think that @Tibor17 deserves a real explanation.

@dsaff
Copy link
Member

dsaff commented Jul 24, 2013

@njbartlett,

It is code. org.apache.felix is additional code that needs to work if I accept this pull request for the project to build.

My concern here is contributors, not users; if someone adds a new package, they will need to understand the syntax and semantics of the Export-Package and Private-Package tags in this, to know if they need to edit them to correctly bundle or exclude their new package.

@Tibor17
Copy link
Contributor Author

Tibor17 commented Jul 25, 2013

The Export part is generic. We are exporting everything except for package "internal". Worth mentioning package structure of JUnit into Wiki, maybe this is so obvious configuration that wiki page is not needed here.

If BND is used in proprietary build, the manifest file is deleted whatever content is in it. This patch should not harm proprietary builds.

Actually for someone it is a code, for someone else it's not. The BND configuration does not have any special features for our OSGi headers. We are very simple here.

The IT tests are a MUST for me, that's it.
I do not mind to submit them (and all the machinery around...).

If I compare Ant and Maven, the principles are similar, so that the ANT has JAR and compile tags, and the Maven has JAR package and Compiler plugins as well. It is Java code in both cases. The BND plugin is plugin as well, and his java classes do NOT present in junit.jar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants