search

s-n-ushakov / usn-eclipselink-slf4j

An EclipseLink SessionLog implementation for logging messages through SLF4J.
1 stars 0 forks source link

Use maven-bundle-plugin to build a JAR with OSGi headers #1

Open SourcePond opened 9 years ago

SourcePond commented 9 years ago

The current release jar does not contain proper OSGi headers which are necessary to use the logger in an OSGi environment. This can easily be fixed when using the maven-bundle-plugin instead of the ordinary jar-plugin:

<plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <version>2.5.3</version> <extensions>true</extensions> </plugin>

The packaging type is "bundle", i.e. following package type must be defined in the pom.xml: <packaging>bundle</packaging>

s-n-ushakov commented 9 years ago

Hi holyroli, and thank you for pointing this out. Hope to look deeper into it on the weekend...

To be frank, my acquaintance with OSGi is currently reduced to having heard of it :)

Is it correct that an OSGi bundle will be equally good as a normal jar for ordinary applications?

And just to be on the safe side: can one expect that two amendments to the .pom that you mention are sufficient to produce a full-fledged bundle?

SourcePond commented 9 years ago

Hi Sergey,

Yes, an OSGi-bundle can be used in normal non-OSGi applications. A bundle is actually nothing else than an ordinary JAR which contains additional headers in its MANIFEST.MF. This headers are only processed by an OSGi-container like Felix or Equinox.

To your second question: yes, adding the maven-bundle-plugin and changing the package-type is enough to build a valid bundle.

Have a great day :) Roland

s-n-ushakov commented 9 years ago

Hi Roland,

I have made some steps toward an OSGI bundle (separating it from an unfinished work on pushing the project into OSSRH / central repository), and stopped hesitating on the right dependency type for EclipseLink.

Initially is was just a thoughtless "comple" dependency on the all-in-one non-OSGi EclipseLink artifact. And this type of dependency may be not the best one, as it is likely to produce conflicts at final application build phase, when an application brings in an EclipseLink dependency it needs.

My next idea was to change the dependency to an OSGi one as "org.eclipse.persistence:org.eclipse.persistence.core:2.6.0" with the scope as "provided". And now I hesitate whether "provided" is the right scope for an OSGi bundle dependency...

And what is your idea? Should it be "provided" or "compile" or anything else?

SourcePond commented 9 years ago

Hi Sergey,

Your thought is correct, just replace org.eclipse.persistence:eclipselink:2.5.2 through org.eclipse.persistence:org.eclipse.persistence.core:2.6.0

The dependency scope should remain "compile" because you cannot assume that an application environment provides an appropriate eclipselink JAR. After you have replaced the dependency you should get a MANIFEST.MF like this after building with maven-bundle-plugin:

Manifest-Version: 1.0 Bnd-LastModified: 1427810231494 Build-Jdk: 1.7.0_72 Built-By: rolandhauser Bundle-Description: Implements logging for EclipseLink via SLF4J Bundle-License: http://www.eclipse.org/legal/epl-v10.html, http://www.ec lipse.org/org/documents/edl-v10.php Bundle-ManifestVersion: 2 Bundle-Name: SLF4J logger for EclipseLink Bundle-SymbolicName: com.github.s-n-ushakov.usn-eclipselink-slf4j Bundle-Version: 20150129.0.0 Created-By: Apache Maven Bundle Plugin Export-Package: usn.eclipse.persistence.logging;uses:="org.eclipse.persi stence.logging,org.eclipse.persistence.sessions,org.slf4j";version="201 50129.0.0" Import-Package: org.eclipse.persistence.internal.databaseaccess;version= "[2.6,3)",org.eclipse.persistence.internal.sessions;version="[2.6,3)",o rg.eclipse.persistence.logging;version="[2.6,3)",org.eclipse.persistenc e.sessions;version="[2.6,3)",org.slf4j;version="[1.7,2)",org.slf4j.spi; version="[1.7,2)" Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.5))" Tool: Bnd-2.3.0.201405100607

s-n-ushakov commented 9 years ago

Ok Roland, it was a great idea of yours to have you manifest posted here :) I see now how it works...

My next question now is the following: what would be right version of EclipseLink to be set as dependency? Wouldn't 2.6 be somewhat excessively exacting? Shouldn't we indicate a lower version?

I already have some experience of prerequisite downgrade requests for my projects, that's why I'm asking now... And that's why "source" and "target" are "1.5" here... :)

I can play with different dependency versions myself, but if you have a definite idea, you are most welcome :)

SourcePond commented 9 years ago

Your right, version 2.6 might be to tight ;) I just used the newest version. I would recommend to use the lowest version of the EclipseLink core bundle which compiles with your project.

s-n-ushakov commented 9 years ago

Hi Roland,

and I have to confess that I failed to build a bundle so far... My .pom still produces a plain jar.

I have looked into the bundle plugin manual, and all the examples there suggest having a <configuration> with some <instructions>. May it be the main trick?

May it be a good idea that you post a diff for your .pom here? Or maybe issue a pull request? ;) I have no experience with them yet, but it may be good to try sooner or later... :)

s-n-ushakov commented 9 years ago

Hi Roland again,

I have discovered that the right (somewhat :-P) MANIFEST.MF gets created under "target\classes\META-INF\", but it does not get into the final jar, and the latter obtains the plain old one.

Any ideas?