Skip to content
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

Please publish the source jar with OSGI manifest headers, too #242

Closed
15knots opened this issue Apr 5, 2016 · 10 comments
Closed

Please publish the source jar with OSGI manifest headers, too #242

15knots opened this issue Apr 5, 2016 · 10 comments

Comments

@15knots
Copy link

15knots commented Apr 5, 2016

The implementation jar of sshj on maven central already has proper OSGI manifest headers, which makes it easy to put that jar into a p2 repository to use sshj as an Eclipse bundle.

But the source jar does not have the appropriate OSGI manifest headers. If one puts the source jar into a p2 repository for use in a target platform, the Eclipse IDE will not find and show the Java sources when debugging.

I am willing to help with this, but I do not know gradle (only maven).

@hierynomus
Copy link
Owner

@15knots Could you check whether a clean build now produces the correct OSGI manifest headers for the sources.jar?

@15knots
Copy link
Author

15knots commented Apr 12, 2016

Thanks for the quick response, first.

Sorry, neither my local build nor the 0.16.0 version on maven central has the proper manifest headers.
See this real-life example of those MANIFEST.MF headers :

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Razorcat Application Server client API Source
Bundle-SymbolicName: com.razorcat.appserver.client.api.source
Bundle-Version: 1.1.2
Eclipse-SourceBundle: com.razorcat.appserver.client.api;version="1.1.2 ";roots:="."

In the above,

  • Bundle-Name is the name of the corresponding binary bundle plus ' Source'. This name is shown in the Eclipse 'Edit Target Wizard'.
  • Bundle-SymbolicName is the same as in the binary bundle plus '.source' (by convention). This is displayed in the content tab of the 'Edit Target Wizard'.
  • Bundle-Version should match the one of the binary bundle.
  • Eclipse-SourceBundle marks the bundle as the source bundle. See Eclipse-SourceBundle for details.
  • For source bundles, no other export/import OSGI manifest headers are required.

For builds with maven, I simply use the archive manifestEntries elements to set the required headers when generating the source bundle jar:

<archive>
  <manifestEntries>
     <Bundle-ManifestVersion>2</Bundle-ManifestVersion>
     <Bundle-Name>${project.name} Source</Bundle-Name>
     <Bundle-SymbolicName>${project.groupId}.${project.artifactId}.source</Bundle-SymbolicName>
     <Bundle-Version>${parsedVersion.osgiVersion}</Bundle-Version>
     <Eclipse-SourceBundle>${project.groupId}.${project.artifactId};version="${parsedVersion.osgiVersion}";roots:="."</Eclipse-SourceBundle>
     <Bundle-Vendor>${project.organization.name}</Bundle-Vendor>
  </manifestEntries>
</archive>

@hierynomus
Copy link
Owner

Thanks. I'll fix this for the next release!

Op di 12 apr. 2016 22:07 schreef 15knots [email protected]:

Thanks for the quick response, first.

Sorry, neither my local build nor the 0.16.0 version on maven central has
the proper manifest headers.
See this real-life example of those MANIFEST.MF headers :

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Razorcat Application Server client API Source
Bundle-SymbolicName: com.razorcat.appserver.client.api.source
Bundle-Version: 1.1.2
Eclipse-SourceBundle: com.razorcat.appserver.client.api;version="1.1.2 ";roots:="."

In the above,

For builds with maven, I simply use the archive manifestEntries elements
to set the required headers when generating the source bundle jar:

2 ${project.name} Source ${project.groupId}.${project.artifactId}.source ${parsedVersion.osgiVersion} ${project.groupId}.${project.artifactId};version="${parsedVersion.osgiVersion}";roots:="." ${project.organization.name}


You are receiving this because you modified the open/close state.

Reply to this email directly or view it on GitHub
#242 (comment)

@15knots
Copy link
Author

15knots commented Apr 12, 2016

Please PM me an URL for beta-testing that prior to releasing it.
I will then test

  • how the jars get incorporated into a p2 repo and
  • how that p2 repo looks in a p2 repo browser (e.g. Eclipse target editor).
    I´m a little concerned here, the 0.16.0 release might have broken something for p2 users.

@hierynomus hierynomus reopened this Apr 13, 2016
@hierynomus
Copy link
Owner

Just committed 317bbfa on branch https://github.com/hierynomus/sshj/tree/issue-242

Can you build that branch and see whether the manifest looks better now?

@15knots
Copy link
Author

15knots commented Apr 13, 2016

Wow,

BUILD SUCCESSFUL
Total time: 49 mins 44.204 secs

It still has the Im-/Export headers.
I improved it (non-working, commented patch issue-242-1.patch.txt), but could not solve due to my lack of knowledge in gradle.

With the patch, it looks better,
target-definition
target-definition-content
but that does not solve this issue due to problems generating a proper version number.

@hierynomus
Copy link
Owner

Thanks, will have a look!

2016-04-13 22:43 GMT+02:00 15knots [email protected]:

Wow,

BUILD SUCCESSFUL
Total time: 49 mins 44.204 secs

It still has the Im-/Export headers.
I improved it (non-working, commented patch issue-242-1.patch.txt
https://github.com/hierynomus/sshj/files/217911/issue-242-1.patch.txt),
but could not solve due to my lack of knowledge in gradle.

With the patch, it looks better,
[image: target-definition]
https://cloud.githubusercontent.com/assets/11367029/14508536/2859a324-01c8-11e6-9612-d56a136c07d2.png
[image: target-definition-content]
https://cloud.githubusercontent.com/assets/11367029/14508535/2856f70a-01c8-11e6-9c4c-5305ebd950a9.png
but that does not solve this issue due to problems generating a proper
version number.


You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#242 (comment)

@15knots
Copy link
Author

15knots commented Apr 14, 2016

Got it!

task sourcesJar(type: Jar) {
    classifier = 'sources'
    from sourceSets.main.allSource
    manifest { // manifest is NOT of type OsgiManifest
        attributes(
           "Bundle-ManifestVersion": "2",
           // copy values from binary jar manifest to be consistent...
           "Eclipse-SourceBundle": project.jar.manifest.getSymbolicName()
            + ";version=\"" + project.jar.manifest.getVersion() + "\";roots:=\".\"",
           "Bundle-SymbolicName": project.jar.manifest.getSymbolicName() + ".source",
           "Bundle-Version": project.jar.manifest.getVersion()
           "Bundle-Name": project.jar.manifest.getName() + " Source",
        )
    }
}

Please carefully review, I'm a gradle newbie.

Gives

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Eclipse-SourceBundle: com.hierynomus.sshj;version="0.16.1.dev_1_uncomm
 itted_317bbfa";roots:="."
Bundle-Name: sshj Source
Bundle-SymbolicName: com.hierynomus.sshj.source
Bundle-Version: 0.16.1.dev_1_uncommitted_317bbfa

Eclipse target definition looks good, target content the same and the eclipse editor is showing the source.

@hierynomus
Copy link
Owner

Fixed it, thanks for looking at it. Do you need an 0.16.1 release with the fixed manifests?

@15knots
Copy link
Author

15knots commented Apr 15, 2016

Yes, please release 0.16.1

Plus you could mention in the README, that sshj now has proper manifest headers for OSGI and is ready for incorporation into a p2 repo. That way, it can be used to build Eclipse bundles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants