Please OSGi-ify the objenesis jar.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. looking at the jar manifest

What is the expected output? What do you see instead?
I expect to see OSGi manifest entries.

Please provide any additional information below.

Please OSGi-ify the objenesis jar.  This would eliminate the need for
3rd-party objenesis bundles.

An example of the objenesis jar with OSGi manifest entries can be seen here:
http://www.springsource.com/repository/app/bundle/version/detail?name=com.spring
source.org.objenesis&version=1.0.0

Also, I see that objenesis relies on JUnit for testing.  Please consider
voting/commenting:
http://sourceforge.net/tracker/?func=detail&aid=2720888&group_id=15278&atid=3652
78

Original issue reported on code.google.com by lukewpat...@gmail.com on 29 Mar 2009 at 2:31

[GoogleCodeExporter]

This would be greatly appreciated. The maven-bundle-plugin [1] is a great way to
integrate generation of an OSGi manifest into the build process.

[1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html

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

[GoogleCodeExporter]

Should be done soon. I'll see how the plugin goes. Can you give me the expected
result? I'm not using OSGi right now and don't know how to test my result. I'm
assuming it should be something like this thought.

Export-Package: org.objenesis;version="1.1.0";uses:="org.objenesis.ins
 tantiator,org.objenesis.strategy",org.objenesis.instantiator;version=
 "1.1.0",org.objenesis.instantiator.basic;version="1.1.0",org.objenesi
 s.instantiator.gcj;version="1.1.0",org.objenesis.instantiator.jrockit
 ;version="1.1.0",org.objenesis.instantiator.sun;version="1.0.0",org.o
 bjenesis.strategy;version="1.1.0";uses:="org.objenesis.instantiator"
Bundle-Vendor: Objenesis
Bundle-Classpath: .
Bundle-Version: 1.1.0
Bundle-Name: Objenesis
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.objenesis

Original comment by henri.tr...@gmail.com on 8 Apr 2009 at 11:20

• Changed state: Accepted

[GoogleCodeExporter]

That is close.  It will work, but like everything that works, there is a "best
practice". 
http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-1419.pdf is
good.  I would look at the Module Layer and the General sections of that set of
slides.  That set of slides comes form here [1].

The biggest thing that I would do is make sure you are re-importing your 
exported
packages.  Sounds funny, I know.  Feel free to drop results here and we can work
through tweaking the output if you want.

[1]
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-1419&yr=20
07&track=3

Original comment by nairb...@gmail.com on 9 Apr 2009 at 1:37

[GoogleCodeExporter]

I read the best practice to know a little more what I was doing. Then I tried
maven-bundle-plugin. Version 2.0.0. Using the manifest goal which seems to be 
what I
want.

The results is below and now my comments/questions:

* Will only exported package be accessible to others? What happens when 
compiling
with a jar/bundle that then do not expose the package used? 
NoClassDefFoundError?
* I'm asking this because I'm wondering if I should hide Objenesis inner
implementation. Most users won't need it but some power users might.
* I need to import my own packages to be able to "use" them in the export part?
* If there's some dynamic use between packages, should I trace them and add 
them?
* all the "Bundle-***" seems fine
* In the import section, aonic and jrockit packages are JVM implementations. I 
guess
I need to remove them?
* I don't understand why the import section is referencing version 1.1 of 
objenesis
(1.1.1-SNAPSHOT is the currently bundled version)

--------------------------------------------------------------------------
Export-Package: org.objenesis;uses:="org.objenesis.instantiator,org.ob
 jenesis.strategy";version="1.1.1.SNAPSHOT",org.objenesis.instantiator
 ;version="1.1.1.SNAPSHOT",org.objenesis.instantiator.basic;uses:="org
 .objenesis,org.objenesis.instantiator";version="1.1.1.SNAPSHOT",org.o
 bjenesis.instantiator.gcj;uses:="org.objenesis,org.objenesis.instanti
 ator";version="1.1.1.SNAPSHOT",org.objenesis.instantiator.jrockit;use
 s:="COM.jrockit.reflect,org.objenesis,org.objenesis.instantiator,jroc
 kit.vm";version="1.1.1.SNAPSHOT",org.objenesis.instantiator.perc;uses
 :="org.objenesis,org.objenesis.instantiator,COM.newmonics.PercClassLo
 ader";version="1.1.1.SNAPSHOT",org.objenesis.instantiator.sun;uses:="
 org.objenesis,org.objenesis.instantiator,sun.reflect";version="1.1.1.
 SNAPSHOT",org.objenesis.strategy;uses:="org.objenesis.instantiator,or
 g.objenesis.instantiator.perc,org.objenesis,org.objenesis.instantiato
 r.basic,org.objenesis.instantiator.gcj,org.objenesis.instantiator.sun
 ,org.objenesis.instantiator.jrockit";version="1.1.1.SNAPSHOT"
Bundle-Version: 1.1.1.SNAPSHOT
Tool: Bnd-0.0.311
Bundle-Name: Objenesis
Bnd-LastModified: 1239409710046
Bundle-ManifestVersion: 2
Bundle-License: http://www.opensource.org/licenses/mit-license.php
Bundle-Description: A library for instantiating Java objects
Bundle-SymbolicName: org.objenesis
Import-Package: COM.jrockit.reflect,COM.newmonics.PercClassLoader,jroc
 kit.vm,org.objenesis;version="1.1",org.objenesis.instantiator;version
 ="1.1",org.objenesis.instantiator.basic;version="1.1",org.objenesis.i
 nstantiator.gcj;version="1.1",org.objenesis.instantiator.jrockit;vers
 ion="1.1",org.objenesis.instantiator.perc;version="1.1",org.objenesis
 .instantiator.sun;version="1.1",org.objenesis.strategy;version="1.1",
 sun.reflect

Original comment by henri.tr...@gmail.com on 12 Apr 2009 at 4:02

[GoogleCodeExporter]

* Will only exported package be accessible to others? What happens when 
compiling
* with a jar/bundle that then do not expose the package used? 
NoClassDefFoundError?

Yes, at runtime attempts to resolve the non-exported class would result in
NoClassDefFoundErrors.

* I'm asking this because I'm wondering if I should hide Objenesis inner
* implementation. Most users won't need it but some power users might.

IMHO, any packages you permit people to use now should also be exported in 
OSGi.  If
you recognize the power users' use cases and are willing to support them, then 
those
users should be able to use the same stuff in an OSGi container.

* I need to import my own packages to be able to "use" them in the export part?

You don't need to import your own exported packages, it's just best practice.

* If there's some dynamic use between packages, should I trace them and add 
them?

I'll take a look if you can give me a link to some code that does that.  I'll 
try to
figure out what the best thing to do is.

* In the import section, aonic and jrockit packages are JVM implementations. I 
guess
* I need to remove them?

I wonder how those are sneaking in there.  Are you coding to those packages?

* I don't understand why the import section is referencing version 1.1 of 
objenesis
* (1.1.1-SNAPSHOT is the currently bundled version)

I can't really give a justification besides saying that this is a conscious 
decision
by Bnd.

from http://aqute.biz/Code/Bnd
  "
  If no version or version range is specified 
  on the import instruction, the exported 
  version will then be used though the micro 
  part and the qualifier are dropped. That is, 
  when the exporter is 1.2.3.build123, 
  then the import version will be 1.2. 
  "

Original comment by lukewpat...@gmail.com on 11 Jun 2009 at 3:37

[GoogleCodeExporter]

Thanks a lot for your answers. I've been able to OSGified EasyMock and to test 
it
with the Spring bundle test framework.

I'll do the same thing for Objenesis. One thing I'm not sure about is the JVM 
inner
implementation packages. To answer your question, yes, Objenesis is using a lot 
of
JVM inner packages like com.sun, COM.jrockit and COM.newmonics. That's why it
appears. But I don't think it should be an issue with OSGi since there are low 
enough
in the class loading.

I'll tell you how it goes.

Original comment by henri.tr...@gmail.com on 13 Jun 2009 at 3:00

[GoogleCodeExporter]

Original comment by henri.tr...@gmail.com on 23 Aug 2009 at 11:20

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by henri.tr...@gmail.com on 23 Aug 2009 at 11:26

• Added labels: Milestone-1.2, Priority-Medium, Type-Enhancement

[GoogleCodeExporter]

Original comment by henri.tr...@gmail.com on 14 Aug 2013 at 11:46