-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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
Invalid OSGi manifest in 'activiti-engine-5.13.jar' #118
Comments
I pulled the head from Github today, and built with Maven ('mvn verify'). Notice the warnings reported by the Maven bundle plugin.
Simply changing the version of maven-bundle-plugin to a more recent version produces a slightly more insightful clue, as well as a fatal build error.
|
should be okay now |
I am seeing another issue with the activiti-explorer 5.14 war with Virgo, duplicate import packages it seems, although I haven't been able to determine which jar is causing the problem:
|
I have seen this previously in my Maven projects, and traced it to a duplicate declaration |
The culprit is in C:\activiti-5.14\wars\activiti-explorer\WEB-INF\lib\activiti-engine-5.14.jar\META-INF\MANIFEST.MF, which has a duplicate import for org.activiti.osgi: org.activiti.osgi;resolution:=optional,org.activiti.osgi;resolution:=optional Any chance this will be addressed? This prevents deploying activiti in Eclipse Virgo. Thanks! |
This is addressed in the current Github master. We also released Activiti 5.14 to Maven central a couple of weeks ago and this also includes the OSGi fix. So if you retrieve the activiti engine 5.14 JAR from Maven central it should be ok. |
The exact same problem still exists in the 5.14 distribution. I can confirm that simply removing the duplicate entry allows Activiti to deploy fine as a war in Virgo 3.6.1. |
Other OSGI issues with the 5.14 distribution:
Caused by: org.eclipse.virgo.util.osgi.manifest.parse.BundleManifestParseException: Error parsing bundle manifest header [] |
activiti-json-converter doesn't have any export directives either in its MANIFEST... I wonder how those MANIFESTs are being generated? I am having to repackage all the jars using basic default BND instructions and that seems to work just fine... this is what I am using: ########### pom.xml
======== osgi.bnd: Embed-Dependency: *;scope=compile|runtime;type=!pom;inline=true |
@franck102 are you sure that you looked at the Activiti 5.14 Engine JAR from Maven central? |
I had looked at activiti-engine-5.14.jar found in the Activiti download from the web site. You are right that the version on maven central doesn't have the duplicate entry. That being said both jars have hard dependencies on secondary packages of 3rd party bundles, i.e. it seems like only the first package is marked as optional:
This creates unwanted hard dependencies on drools, junit, org.junit, and possibly other bundles. Here are the bnd instructions I used to fix this when repackaging:
I have managed to deploy activiti-rest on Virgo, here are the bundles I had to repackage if anyone is trying to do the same: activiti-engine Deploying drools would require some additional repackaging... |
Optional dependencies to JUnit in a OSGI manifest are a little bit ugly. Actually the activiti-engine artifact provide classes which inherite from JUnit and help you to test the engine. This classes are also used to test the engine itself. A solution could be to extract the JUnit helper classes into a own artifact for example activiti-test similiar like in the Apache Camel Project and also move the integration testcases which are testing the engine into a seperate module to avoid cycle dependencies between the maven artifacts. If I look into this ticket there are a lot of peope out there which use Activiti in a OSGi container. I think it would be nice to implement an OSGi integration test in the future. BTW. I already opened a ticket for that ;) @franck102 feel free to contribute. |
A test would be fantastic... here are some thoughts and a first contribution. As far as I know there are no straightforward tools to statically validate a set of OSGI bundles.
There is probably a smarter way to start equinox command line to simply have exit with a status of 0 / non-zero depending on whether initial resolution triggered any errors... The proposed configuration is somewhat arbitrary, and involves quite a bit of repackaging as described earlier in this thread. config.ini:
|
There is already tooling out there to build OSGi integration tests for different OSGi frameworks like Felix, Equinox or Knopflerfish. I will start with a sample project which load all necessary dependencies and check how a test can be realised with pax-exam https://ops4j1.jira.com/wiki/display/PAXEXAM3/Pax+Exam |
Yes, we use pax-exam for our testing, it is however quite a bit more involved to setup and automate... but definitely more powerful. public abstract class BaseServiceTest |
At a higher level, I am struggling with the explorer & modeler on the OSGI front. Those two depend on zillions on non OSGI libraries, some of which would require more than simple repackaging to work nicely under OSGI (e.g. gwt) because they use unorthodox class loading patterns. The sensible thing to do seems to be to just use the non-OSGI explorer war (my Virgo container supports that), but the explorer then doesn't share any classes with the OSGI engine (different classloaders) so it is pretty useless to me. |
I'm satisfied if the engine is covered with a integration test in a first version and maybe the rest interface :) |
Apparently the MANIFEST.MF in the 5.13 release version of 'activiti-engine' is technically invalid; incorrect, and should not pass even the initial parsing stage. The present mechanism for build validation likely contains a less strict facility for manifest parsing -- as the manifest contains a wildcard-like entry, "org.activiti.osgi*" which should not be present.
Incidentally, I discovered this as Eclipse Virgo choked on activiti-engine-5.13.jar when I dropped it into 'repository/usr'.
The activiti-engine-5.13.jar file was just one of 42 total dependency files I was deploying; all others imported correctly.
Some snippets of the log are shown below, along with a shell command which identifies the offending line number within the manifest.
The jar file was pulled via Maven, from http://maven.alfresco.com/nexus/content/repositories/activiti
Also found a verify similar issue (which was since fixed) for Jersey; https://java.net/jira/browse/JERSEY-1426 .
Meanwhile, can anyone suggest a workaround? I know I could manually fix the manifest, but not sure just what to replace this entry with.
The text was updated successfully, but these errors were encountered: