Community
Participate
Working Groups
Build Identifier: 2.1.0.RELEASE Virgo seems to use the extension of the file to determine whether to deploy an artifact as a PAR or as a JAR. Given that many tools will output JARs, and have the ability to insert additional Manifest data in them, it would make sense if Virgo could handle a PAR being submitted as a JAR, but with an Application-SymbolicName etc. added in. If I have a Manifest which looks like: Application-SymbolicName: foo Application-Version: 1.0.0.SNAPSHOT Application-Name: foo Application-Description: foo and deploy it as a '.jar', then I get it installed as a Bundle with a version 0.0.0 (which is odd - it doesn't have a Bundle-SymbolicName ...) On the other hand, if I rename this '.par' then it gets treated as a PAR and installed successfully. (Note that the maven-par-plugin fails when you have dependencies of type 'bundle', because it writes out com.example.foo.bundle instead of com.example.foo.jar into the PAR archive. So I can't use that, if that's what you were about to suggest ...) Reproducible: Always
Thanks for this suggestion. Although there could be a small additional overhead in cracking open the JAR to look at its manifest to determine it is really a PAR, this should be small compared to the overhead of deploying a PAR. For consistency, we should also extend the repository code to recognize PARs with .jar extensions.
The Apache Aries samples use 'eba' extensions, along with the maven-eba-plugin http://repository.apache.org/snapshots/org/apache/aries/eba-maven-plugin/ It would probably make sense to include this, particularly as it also adopts the Application-SymbolicName as per the PAR.
I don't think we can support Aries EBAs in the core of Virgo, although someone might like to write a kernel deployer extension to support such things. Longer term, we are working in the OSGi Alliance to standardise "subsystems" which are inspired by PARs, plans, EBAs, and artifacts from other projects/vendors.
An EBA appears to be pretty similar to the concept of Virgo's PARs though, just with a different extension. They even use the same Application-SymbolicName. Granted the standardisation is a work-in-progress, but the reason for me pointing it out here is the fact that they're already practically identical and if a rename of an EBA to PAR works and can be deployed, I don't see why it doesn't let you at least try to upload something with an EBA (c.f. JAR)
I see what you mean. Once we can detect PARs by content rather than file extension, then this should just work, i.e. EBAs which happen to be valid PARs will deploy fine. (I do not know how common it is for an EBA to be a valid PAR, however.) In the worst case, we'd need to understand that an .eba file can be an archive if the code wasn't smart enough to work that out (I haven't checked yet).
FYI: http://incubator.apache.org/aries/applications.html http://publib.boulder.ibm.com/infocenter/wasinfo/beta/index.jsp?topic=/com.ibm.websphere.osgi.express.doc/topics/ca_about_eba.html One thing I mistook is they use META-INF/APPLICATION.MF rather than META-INF/MANIFEST.MF like PARs use.
So no EBAs are valid PARs! :-( Shame IBM didn't follow our lead a little more closely. ;-)
> So no EBAs are valid PARs! :-( Actually, it would be possible to write a hybrid PAR/EBA presumably with extension .jar for sanity's sake that had both MANIFEST.MF and APPLICATION.MF with equivalent contents. But that wouldn't be a typical off the shelf EBA or PAR.
