Home » Archived » Eclipse Bundle Recipes » Spring Framework/Spring Security EBR Release Process(How to release OSGi bundles of Spring Framework & Spring Security)
| Spring Framework/Spring Security EBR Release Process [message #1095900] |
Tue, 27 August 2013 13:36  |
Eclipse User |
|
|
|
CAVEAT: These notes are provided only for clues as to how SpringSource used to update Spring Framework and Spring Security bundles in the SpringSource Enterprise Bundle Repository. Do not expect the following process or scripts to work identically in the Eclipse Bundle Recipes project.
Spring Framework OSGi release process:
------------------------------------------------------------
1. After building a given label of the Spring Framework, you then need to run the OSGi staging script:
$ ./copy_springframework_into_artifacts.bash /path/to/spring <old_tag> <new_tag>
This script creates a new folder named <new_tag>, copies all the template/license files from <old_tag>, edits them to replace <old_tag> with <new_tag>, and then copies the built jars from /path/to/spring into <new_tag>. Thus, it is assumed that the current working directory where the script is run is where one can see all the version folders. Also, Spring Framework labels are prefixed with a "v", like "v3.2.4.RELEASE". There is no requirement to adopt this convention for the <old_tag> and <new_tag>.
2. The script will print out a set of instructions, directing you to run a diff report on Spring's build file. This is used to spot changes in 3rd party library versions so you know what edits to make to which template files.
3. Extra manual steps are required if <new_tag> is of a different release type than <old_tag>. For example, if <old_tag> was a release, but <new_tag> is a milestone, you probably need to edit all the template files so that the published bundles are uploaded to
the milestone bucket (assuming that's your intention).
4. With everything set up, you can now publish! Spring's EBR used a combination of ant clean publish-test && ant clean publish -propertyfile /path/to/s3.properties, but this should probably be replaced by the steps used to properly publish to the target destination of the Eclipse Bundle Repository.
Spring Security OSGi release process:
------------------------------------------------------------
1. After building a given label of Spring Security, you then need to run the OSGi staging script:
$ ./copy_springsecurity_into_artifacts.bash /path/to/springsecurity <old_tag> <new_tag>
This script creates a new folder named <new_tag>, copies all the template/license files from <old_tag>, edits them to replace <old_tag> with <new_tag>, and then copies the built jars from /path/to/springsecurity into <new_tag>. Thus, it is assumed that the current working directory where the script is run is where one can see all the version folders.
2. The script will print out a set of instructions, directing you to run a diff report on Spring Security's build file. This is used to spot changes in 3rd party library versions so you know what edits to make to which template files.
3. Extra manual steps are required if <new_tag> is of a different release type than <old_tag>. For example, if <old_tag> was a release, but <new_tag> is a milestone, you probably need to edit all the template files so that the published bundles are uploaded to the milestone bucket (assuming that's your intention).
4. With everything set up, you can now publish! Spring's EBR used a combination of ant clean publish-test && ant clean publish -propertyfile /path/to/s3.properties, but this should probably be replaced by the steps used to properly publish to the target destination of the Eclipse Bundle Repository.
|
|
| | | | |
| Re: Spring Framework/Spring Security EBR Release Process [message #1219035 is a reply to message #1095900] |
Fri, 29 November 2013 18:24  |
| Eclipse User |
|
|
|
I am admittedly slightly confused by the current situation. If I understand correctly, this is the current state, in a nutshell:
- Springsource EBR is frozen and only contains 3.2.x release up to 3.2.4 [1].
- The task of transforming thirdparty artifacts into OSGi artifacts will be taken over by Eclipse EBR.
- Artifacts currently hosted in the Springsource EBR will be published via maven central (assuming that Springsource EBR will also seize to exist as a repository in 2015).
- Since 3.2.5 GA, the SPR artifacts are no longer actively published as OSGi-ready variants. The current gradle build setup of the 3.2.x branch is free of OSGI metadata [2].
- The main reason for the separate publication of OSGi-artifacts using different group IDs [3] is dependency management, as the OSGi bundles partially depend on artifacts made available via the EBR, thus featuring at least different group ids [4].
- The old transformation process, templates, scripts etc. used to publish OSGi bundles require adaptation to the current release and build framework (see above).
Now, here is what I am wondering about. Why should there be two different sets of dependencies for OSGi / non-OSGi distributions? After all, if I am not mistaken, those dependencies are not shipped with SPR and the actual relationships are to specific classes in specific, versioned packages and not to the artifacts containing those. Why not just add the osgi plugin to the gradle build and generate OSGi metadata by default? IMO, it is the users responsibility to deploy / configure the right thirdparty bundles in the OSGi container or for test setups. It should not be SPR's responsibility to manage the OSGI compatibility of its transitive hull. This should be (and will be anyway, if I understand correctly) a separate, user-driven workstream.
What is it I am missing?
Regards,
Olaf
[1] http://ebr.springsource.com/repository/app/faq#q2
[2] http://www.infoq.com/news/2012/10/spring-osgi-gradle/
[3] http://docs.spring.io/spring/docs/3.2.5.RELEASE/spring-framework-reference/htmlsingle/#dependency-management
[4] https://jira.springsource.org/browse/SPR-8903?focusedCommentId=73569&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-73569
|
|
|
| Re: Spring Framework/Spring Security EBR Release Process [message #1219124 is a reply to message #1219035] |
Mon, 02 December 2013 03:02 |
| Eclipse User |
|
|
|
Olaf Otto wrote on Fri, 29 November 2013 23:24I am admittedly slightly confused by the current situation. If I understand correctly, this is the current state, in a nutshell:
- Springsource EBR is frozen and only contains 3.2.x release up to 3.2.4 [1].
Correct.
Quote:
- The task of transforming thirdparty artifacts into OSGi artifacts will be taken over by Eclipse EBR.
That is the proposal. However, this requires the Eclipse EBR project to gain sufficient momentum.
Quote:
- Artifacts currently hosted in the Springsource EBR will be published via maven central (assuming that Springsource EBR will also seize to exist as a repository in 2015).
Not sure what makes you think this will happen automatically. It would be necessary for Eclipse EBR to cover the artefacts currently hosted in SpringSource EBR and someone to publish these to maven central.
Quote:
- Since 3.2.5 GA, the SPR artifacts are no longer actively published as OSGi-ready variants. The current gradle build setup of the 3.2.x branch is free of OSGI metadata [2].
Correct.
Quote:
- The main reason for the separate publication of OSGi-artifacts using different group IDs [3] is dependency management, as the OSGi bundles partially depend on artifacts made available via the EBR, thus featuring at least different group ids [4].
- The old transformation process, templates, scripts etc. used to publish OSGi bundles require adaptation to the current release and build framework (see above).
Correct.
Quote:
Now, here is what I am wondering about. Why should there be two different sets of dependencies for OSGi / non-OSGi distributions? After all, if I am not mistaken, those dependencies are not shipped with SPR and the actual relationships are to specific classes in specific, versioned packages and not to the artifacts containing those. Why not just add the osgi plugin to the gradle build and generate OSGi metadata by default? IMO, it is the users responsibility to deploy / configure the right thirdparty bundles in the OSGi container or for test setups. It should not be SPR's responsibility to manage the OSGI compatibility of its transitive hull. This should be (and will be anyway, if I understand correctly) a separate, user-driven workstream.
I'm not going to put words in the Spring Framework team's mouth, but there was a lot of complexity involved in maintaining OSGi metadata which the team felt they didn't have the expertise to continue to do. The old metadata was getting out of date, so rather than ship manifests that would be incorrect and a source of bugs, they decided to drop OSGi metadata.
Quote:
What is it I am missing?
The community is free to propose a contribution or pull request to Spring Framework to re-instate OSGi metadata, but I expect there would be a lot of resistance unless the solution was clearly very easy to maintain.
The preferred solution is that the OSGi community maintain manifest templates for Spring Framework in the Eclipse EBR project and that someone publishes the generated bundles to maven central.
Quote:
Regards,
Olaf
[1] http://ebr.springsource.com/repository/app/faq#q2
[2] http://www.infoq.com/news/2012/10/spring-osgi-gradle/
[3] http://docs.spring.io/spring/docs/3.2.5.RELEASE/spring-framework-reference/htmlsingle/#dependency-management
[4] https://jira.springsource.org/browse/SPR-8903?focusedCommentId=73569&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-73569
|
|
| | | | |
Goto Forum:
Current Time: Wed May 07 04:45:13 EDT 2025
Powered by FUDForum. Page generated in 0.05994 seconds |
Home