OSGi Bundle for issue #11 #32
Conversation
|
Only EasyMock 2.5 or higher is OSGi bundle as a dependency in main code |
| <macrodef name="jar-osgi-bundle"> | ||
| <attribute name="modulename" description="Name of the OSGi bundle to jar"/> | ||
| <sequential> | ||
| <property name="bundlename" value="@{modulename}"/> |
There was a problem hiding this comment.
Given you can only set the value of a property once in ant, I'm not convinced this is correct.
|
|
|
I cloned and built the jar and I think it over-imports packages that are optional: Import-Package: com.thoughtworks.qdox,com.thoughtworks.qdox.model,java What about making these particular packages optional? They aren't needed for the runtime use of Hamcrest, and if someone wants to use them, they can bring them in: com.thoughtworks.qdox.* |
|
@mattbishop |
|
I'm a little concerned that interleaving the extra work for generating the osgi bundles within the current ant tasks is unclear, and will add time to our normal build path. I'm just exploring ideas, but would it be possible to add an extra ant target for generating osgi, which consumed the source jars, unzipped them, then ran the bnd? Something that we could tack on the end of the existing build would be preferable in my mind. |
|
+1 with Tom. |
|
@scarytom |
|
Done. |
|
It or, would you mind measuring the time difference so we know if we have a problem with build times? My concern with a separate task for the manifest fiddling is human error. I have seen several projects keep it as a separate step, forget, push to sonatype / maven central, then get bugs, spin up a new release, etc. it's a big enough problem that most people include the OSGi step. Interestingly, Apache Commons requires the OSGi headers be built inline. Their parent Pom provides the necessary plugin to do so. It is important that the manifests are correct on the artifacts in maven central. We don't want to have to require someone to build hamcrest themselves to get the OSGi manifests. OSGi deployment mechanisms like OBR rely on maven servers like Nexus to provide bundles. These are not systems that usually build their dependencies, nor include them in a /libs style source repository. If the timings reveal no appreciable difference, would anyone have an objection to keeping the manifest generation in the main build flow? |
|
@mattbishop |
|
cool, what is it if you take out the osgi step? |
|
what you mean by step? If you mean commented out the inside of macro def, then it is like the official build. |
|
I think we want to know this:
We know that #2 takes 37 seconds on your machine. How long does #1 take on On Tue, Apr 9, 2013 at 9:18 AM, Tibor Digana notifications@github.comwrote:
|
|
@mattbishop |
|
For #1 it takes 35 seconds on my laptop. |
|
I can measure, but for this discussion we can say that the osgi manifest On Tue, Apr 9, 2013 at 9:39 AM, Tibor Digana notifications@github.comwrote:
|
|
I used Karaf OSGi container to see what exported packages will be seen by a real OSGi consumer.
Print exported osgi packages from the container:
Later I printed generator and integration packages: |
|
@mattbishop |
|
@mattbishop |
|
@mattbishop |
|
I can have a look next week. On Sat, May 25, 2013 at 2:18 PM, Tibor Digana notifications@github.comwrote:
|
|
@mattbishop |
|
I picked up your changes but I don't know what I need to do to run the test. Has someone filed a bug to move Hamcrest to maven or gradle? |
|
@mattbishop I totally agree with you that this project could be designed in Maven with the benefit. Normally I am developing only Maven project because project-files based system is problematic like now it has happened, but that would need opening a new pull. |
|
So I've spent about 20 minutes trying to get intellij to pick up the On Wed, Jun 12, 2013 at 12:53 PM, Tibor Digana notifications@github.comwrote:
|
|
@mattbishop |
|
@scarytom |
|
I'm sorry Tibor, you're wasting my time with this IDE-based testing. Can On Wed, Jun 19, 2013 at 3:33 PM, Tibor Digana notifications@github.comwrote:
|
|
@mattbishop |
|
@scarytom |
|
I rebased on your latest changes Tibor and ran your ant command (not sure what version is for). The tests appear to pass. |
|
@mattbishop |
|
@mattbishop |
|
@scarytom |
|
@scarytom |
|
hey, where are the committers of this project ?? is this project dead ? |
|
Not sure what's happened to @scarytom |
|
@sf105, I could find at least 3 different existent projects packaging Hamcrest in an OSGi compatible way, but each has chosen different paths to resolve the split package issue. The problem is that they are not portable. |
|
I'm also from the "minority" who wants to have Hamcrest as an OSGi bundle! (Is there a better way to "vote" for an issue than adding a comment?) |
|
Damn, this is confusing. If we collapsed the jars down to one, would that help? Could you create a project that includes both JUnit and Hamcrest in a single jar? Would that be easier to work with? Or does it need signing by the "official" project? S On 29 May 2014, at 20:54, Cristiano Gavião notifications@github.com wrote:
|
|
Yes the Hamcrest is dead, which i mentioned in JUnit team. @sf105 has already said the arguments. |
Include maven-bundle-plugin to generate the default OSGi manifests for the core and library artifacts.
|
Hoping that this is fixed with #98 |
An update of the build script in order to provide OSGi Headers in JavaHamcrest.