Hamcrest jars should support OSGi

[GoogleCodeExporter]

OSGi is becoming more and more popular, and it would be extremely nice to 
be able to drop in the hamcrest jars into an OSGi environment and have the 
packages exported etc.

I can create some manifests if someone can comment on what (if any) 
packages should be kept private - I'll export the rest

Original issue reported on code.google.com by rlkes...@gmail.com on 25 Nov 2008 at 9:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

After looking at the -all (2.1) jar, I'm thinking that every package should be 
exported except org.hamcrest.generator.qdox and below.

Original comment by stephen....@gmail.com on 26 Nov 2008 at 12:10

[GoogleCodeExporter]

How are OSGi packages structured?

I think this should be the responsibility of a downstream packaging project, 
like
those who package hamcrest into RPMs, debs, the Maven repository, etc.

If you want to volunteer to do this, we can allocate a part of the hamcrest
repository for you.

Original comment by nat.pr...@gmail.com on 26 Nov 2008 at 4:52

[GoogleCodeExporter]

The only change that is required is the MANIFEST.MF (attached).  It specifies 
the 
packages needed by the jar, as well as the packages that are allowed to be seen 
outside the jar.

Attached is what I think the MANIFEST should look like (for the -all jar).  The 
smaller jars would have fewer imports and exports.

Original comment by stephen....@gmail.com on 30 Nov 2008 at 10:23

Attachments:

• MANIFEST.MF

[GoogleCodeExporter]

You can find hamcrest OSGi bundles here: 
http://www.springsource.com/repository/app/search?
query=hamcrest

Original comment by ketanpad...@gmail.com on 3 Dec 2008 at 4:52

[GoogleCodeExporter]

Springsource is a bit naff - in order to make sure they don't conflict with 
your 
namespace, the manifest is com.sprinsource.org.hamcrest*.  Surely it's not too 
hard 
to overwrite the manifest with the one I've provided?

Original comment by stephen....@gmail.com on 24 Feb 2009 at 1:14

[GoogleCodeExporter]

This is an downstream packaging task.  I repeat: if you want to take 
responsibility
for this, we'll be glad to assist.  But it's not just a case of adding a static 
file
to the JAR.  That static file has to be kept up to date and the packaging has 
to be
tested.  That work is outside the scope of the development of the library 
itself.

Original comment by nat.pr...@gmail.com on 24 Feb 2009 at 2:07

[GoogleCodeExporter]

The Hamcrest OSGi bundles are available at 
http://www.eclipse.org/orbit/overview.php

Original comment by ketanpad...@gmail.com on 27 Feb 2009 at 3:57

[GoogleCodeExporter]

Thanks for fixing this.

Original comment by smgfree...@gmail.com on 28 Feb 2009 at 11:34

• Changed state: Fixed
• Added labels: Priority-High, Type-Task

[GoogleCodeExporter]

What Maven coordinates should consumers use for projects which rely on hamcrest 
but
must work with or without the OSGi runtime?

i.e. 
"org.hamcrest:hamcrest-core" is in central, is not an OSGi bundle, it must be
custom-deployed or embedded to be used in an OSGi runtime.  If multiple bundles 
embed
hamcrest, this causes unnecessary duplication in the assembly.
"org.hamcrest:com.springsource.org.hamcrest.core" is an custom-deployed OSGi 
bundle
that will work with or without the OSGi runtime.  This project isn't in central 
so no
projects deploying to central can depend on it.

Any dependency tree that mixes the two (official and custom-deployed) will 
require
careful, manual insertion of exclusion filters to avoid duplication in the 
assembly.
 The choice I make affects all downstream consumers of my project.  What do you
recommend?

Original comment by lukewpat...@gmail.com on 29 Mar 2009 at 3:11

[GoogleCodeExporter]

Take a peek at: http://www.aqute.biz/Code/Bnd

BND is a good way to integrate proper manifest generation into different build
processes.  I would highly consider integrating this into the build work flow.  
The
ability to test within OSGi environments is becoming more important these days.

As lukewpatterson notes above, having to "find" the OSGi bundle among the 
forest of
different "packaging" is kind of frustrating.  I do agree that this is not the 
java
code itself, but it to those of use who require OSGi, this information is as
important as JavaDoc, if not more so.  Don't get me wrong, it is good there are
options.  My hope is we can consolidate the options and reduce everyone's 
effort.

Original comment by nairb...@gmail.com on 8 Apr 2009 at 3:50

[GoogleCodeExporter]

Please reopen this issue. I am a Maven/Tycho user and I don't want to use orbit 
p2 repository but instead I prefer to use regular Maven repository (as it is 
shared with non OSGI projects). The only requirement is to add correct 
informations (Export/Import) in your MANIFEST during packaging. There is zero 
impact on non OSGI projects.
It is more and more popular, see for example: slf4, commons-*, guava, ...

Original comment by julien.h...@sonarsource.com on 14 Nov 2012 at 12:51

[GoogleCodeExporter]

I'm from the EasyMock project. Which is OSGi compliant. I would like to include 
Hamcrest more tightly but I will need Hamcrest to be OSGi compliant to do so.

Like yourself, I had no idea how to make my jar compliant the first time. I had 
help from the Eclipse project. You basically need to use the 
maven-bundle-plugin (it uses bnd underneath). It should create a nice manifest 
that works right away. You can then tune it  is you don't want to expose some 
private packages.

I'm testing my bundle using spring-osgi-test suite. But that's only really 
required if you have dependencies doing nasty class loading stuff.

For more details, go check the EasyMock code (integration project)

Here's an example for the maven plugin:

      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <executions>
          <execution>
            <id>bundle-manifest</id>
            <phase>prepare-package</phase>
            <goals>
              <goal>manifest</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

Original comment by henri.tr...@gmail.com on 27 Jan 2013 at 10:50

[GoogleCodeExporter]

Use Eclipse Orbit or SpringSource is not a good option because you can't have 
the latest version.

Follow #13, if Hamcrest uses maven to it build it is sooo easy to create and 
maintain osgi manifest.

Please reconsider and reopen this. 

Original comment by cvgav...@gmail.com on 31 Jan 2013 at 6:20