To date Spring Roo has used the SpringSource Enterprise Bundle Repository (EBR) for its own builds. This was motivated for two reasons. First, in Roo 1.0.x we ensured user projects also used EBR so they could adopt OSGi if they wished. Second, Roo 1.1.x switched to OSGi and we needed a source of OSGi-compliant JARs.
ROO-713 we modified Roo user projects to use standard Maven artifact names, downloaded from Maven Central where possible. Some JARs are acquired from other standard Maven repositories such as the Spring Framework Maven Repository (http://maven.springframework.org). The Roo annotations JAR (required by user projects) remained in EBR for the Roo 1.1.0.M1 release. ROO-973 requested that EBR usage by user projects come to an end given ROO-713 had been completed. Removing the EBR repositories from user projects would improve download performance given most of the artifacts are now downloaded from Maven Central and other non-EBR Maven repositories. Further ROO-977 added a wrapper feature so any third-party JAR could be easily made an OSGi JAR via the Roo build process. Thus most of the background steps needed to change both the Roo project build and Roo-based user projects to use Maven repositories has essentially been completed.
More recently work on Roo's imminent add-on discovery and distribution system identified we would require our own repository to host third party add-ons. As such http://spring-roo-repository.springsource.org has been established. After consideration of the requirements for third-party add-ons (such as dependencies on other third-party add-ons, Roo OSGi core bundles and other non-SpringSource OSGi bundles), together with a desire to simplify the Roo build and release process, it was decided to make all Roo artifacts available from this same repository. In particular this would include the Roo annotation JAR used by user projects.
This task is therefore the completion of the above. It will involve:
- Establish http://spring-roo-repository.springsource.org
- Identify existing Roo dependencies that are not OSGi-compliant JARs
- Place those identified non-OSGi compliant JARs under http://maven.springframework.org/external
- Create a
ROO-977wrapper for each identifier non-OSGi compliant JAR
At the completion of this task, the goal is:
- http://spring-roo-repository.springsource.org holds all Roo releases from 1.1.0.M2 and above
- http://spring-roo-repository.springsource.org holds all OSGi-ified bundles needed to build Roo
- http://spring-roo-repository.springsource.org holds third party add-ons in OSGi compliant form
- http://spring-roo-repository.springsource.org holds external dependencies in OSGi compliant form
- Roo-based user projects add http://spring-roo-repository.springsource.org as a repository so they can acquire the annotation JAR
- Roo-based add-on projects add http://spring-roo-repository.springsource.org as a repository so they can acquire references to Roo, other add-ons and any potential OSGi bundles they require
The identified JARs requiring OSGi wrapping were as follows:
- Inflector (latest release of Inflector remains 0.7.0)
- JANSI (note Windows color testing with 1.3.0 failed, so continued with 1.1.0 as per Roo 1.1.0.M1)
- JNA (note Windows color testing with 3.2.5 failed, so continued with 3.2.3 as per Roo 1.1.0.M1)
- JLine (used the 0.9.94.S2-A private build as per
- JavaParser (maintained use of 1.7.0 given 1.8.0 did not indicate any key new features)
- Velocity (its Commons Lang and Commons Collections dependencies were already OSGi compliant)
Some consideration was given to the path under which artifacts placed on http://spring-roo-repository.springsource.org should appear. For simplicity all artifacts of any type will appear under http://spring-roo-repository.springsource.org/release. No snapshots will be published to http://spring-roo-repository.springsource.org/release, though (no snapshot directory is presently planned either).