Migrating to Sebring

The Sebring release will allow breaking changes from the silverstone and monoco releases, and therefore also a new revision range. The silverstone and monoco applications used modules with the revision range [1.0.0.0,2.0.0.0[ ( revisions 1.0.0.0 and greater up to but not including 2.0.0.0). The Sebring release is revision 2.x, so the range of modules supported is [2.0.0.0,3.0.0.0[. This new revision ranges is going to have an effect on resolving existing 1.x applications.

Prior to Sebring, the dynamic revisions for Silverstone and Monoco were in the range [1,2[. The migration from monoco (stable 1.0.x) to silverstone ( stable 1.1.x) was transparent since the existing the application could be resolved without requiring any changes to the application's ivy file. The reason was that both monoco and silverstone had modules in the 1 to 2 range.

However, the repository for Sebring will contain 2.x modules. The default module group in Sebring is also named experimental and by default the url to the repository is https://www.projectzero.org/zero/sebring/latest/. The convention of Project Zero is the latest repository will always be named experimental, and released repositories are always named stable. Each CLI will be configured with the URLs for the module groups in the bootstrap.properties file, and will vary from release to release. Note that other module groups can be added using zero modulegroup create. The suggested convention is a module group should contain only one URL to a zero repository.

This topic is to discuss some of the migration issues and what actions need to be taken with the CLI, there is also a migration guide for the Eclipse plugin.

Can I use the CLI from Sebring to resolve an application from Silverstone or Monoco?

An application that was built with the 1.x revision of the zero.application.template module will have 1.x dependencies. The experimental module group configured in the Sebring CLI will resolve 2.x modules so the resolve will fail with an error that the modules can't be found. The following snippet shows what the error will look like when trying to resolve with a CLI configured with the 2.x repository.

C:\cli\test\app1>..\..\sebring\1110\zero\zero resolve
CWPZT0901I: The following module(s) are not currently in the local repository:
        zero:zero.core:[1.0.0.0, 2.0.0.0[
CWPZT0902I: Trying to locate the module(s) using one of the configured remote repositories
CWPZT0917E: The revision(s) [2.0.0.0.26186] for module zero:zero.core are rejected because they do not satisfy the pattern [1.0.0.0, 2.0.0.0[.
CWPZT0910E: The module zero:zero.core with revision [1.0.0.0, 2.0.0.0[ could not be found on host http://repo1.maven.org/maven2/
CWPZT0915E: The module zero:zero.core can not be located in any of the configured repositories
CWPZT0808E: The resolve report has errors, the resolved properties will not be created.
CWPZT0537W: Resolve could not find the following dependencies
      zero:zero.core:[1.0.0.0, 2.0.0.0[
CWPZT0601E: Error: Command resolve failed

The error indicates the revisions of the zero.core module were found, but also that the revision is not included in the dynamic revision specified.

There are several solutions to the issue.

The existing application is resolved against the experimental module group in this case. In the 2.x version of the CLI, the experimental module group now includes 2.x modules. So the first solution is to continue to use the 1.x version of the CLI for the 1.x modules.

The second option is to take advantage of module groups and add the sMash 1.1.x ( Silverstone ) or sMash 1.0.x ( Monoco) module group to the Sebring CLI. Once the silverstone module group is available, switch the 1.x applicaitons to the silverstone modulegroup.

C:\cli\test\app1>..\..\sebring\1110\zero\zero modulegroup create silverstone https://www.projectzero.org/zero/silverstone/latest/repo/
CWPZT0600I: Command modulegroup create was successful

C:\cli\test\app1>..\..\sebring\1110\zero\zero switch silverstone
CWPZT0901I: The following module(s) are not currently in the local repository:
        zero:zero.core:[1.0.0.0, 2.0.0.0[
CWPZT0902I: Trying to locate the module(s) using one of the configured remote repositories
CWPZT0545I: Retrieving zero.core-1.1.0.0.26230.zip from host https://www.projectzero.org/zero/silverstone/latest/repo/
CWPZT0545I: Retrieving zero.kernel-1.1.0.0.26162.zip from host https://www.projectzero.org/zero/silverstone/latest/repo/
CWPZT0545I: Retrieving zero.network-1.1.0.0.25292.zip from host https://www.projectzero.org/zero/silverstone/latest/repo/
CWPZT0545I: Retrieving zero.management.native.process-1.1.0.0.25292.zip from host https://www.projectzero.org/zero/silverstone/latest/repo/
CWPZT0545I: Retrieving zero.cli.tasks-1.1.0.0.26208.zip from host https://www.projectzero.org/zero/silverstone/latest/repo/
CWPZT0545I: Retrieving zero.management.spi-1.1.0.0.25016.zip from host https://www.projectzero.org/zero/silverstone/latest/repo/
CWPZT0545I: Retrieving zero.management.zso-1.1.0.0.25835.zip from host https://www.projectzero.org/zero/silverstone/latest/repo/
CWPZT0545I: Retrieving zero.management.monitor-1.1.0.0.23488.zip from host https://www.projectzero.org/zero/silverstone/latest/repo/
CWPZT0545I: Retrieving zero.network.support-1.1.0.0.25292.zip from host https://www.projectzero.org/zero/silverstone/latest/repo/
CWPZT0600I: Command switch was successful

C:\cli\test\app1>

Can I switch an existing application to the experimental module group in the Sebring CLI?

We should define what an existing application is. For this discussion an "existing" application is an application created with the 1.x revision of the zero.application.template module. A module created with this template has dependencies on 1.x modules. As the application was developed, more dependencies were probably added, but all the modules came from a 1.x repository. If this application is switched to the experimental module group from a Sebring repository, the resolve step will fail because the Sebring repository only contains 2.x modules.

The previous topic discussed options for resolving the application with the 2.x CLI, but what about moving the application to the 2.x modules in Sebring.

This migration can involve several steps, but this topic will only focus on getting the module resolved against the 2.x modules from Sebring. The modules in the Sebring repository may also require application changes, but those changes will be documented in other sections.

There will be two steps to migration. The first is to fix up the ivy.xml in the config directory so that the dynamic revision is [2,3[.

<dependencies>
  <dependency org="zero" name="zero.core" rev="[2.0.0.0, 3.0.0.0["/>         
</dependencies>

The second step will depend on the names of the module groups configured in the CLI. The command zero repository info will display the configured module groups, find the module group that points to the sebring url, most likely experimental.

C:\cli\test\app1>..\..\sebring\1110\zero\zero repository info
The location of the local repository is C:\cli\sebring\1110\zero\zero-repository.

The known module groups are [experimental, silverstone].
The configured modules groups are as follows:

The module group name is experimental.
        The location for the modulegroup experimental configuration is C:\cli\sebring\1110\zero\zero-repository\experimental\site.xml.

        The following are the list of resolvers for resolving maven artifacts:
                resolver name is maven.3 and location is http://repo1.maven.org/maven2/

        The following are the list of resolvers for resolving zero modules:
                resolver name is zero.2 and location is https://www.projectzero.org/zero/sebring/latest/repo/

        The chain resolver remote includes the following resolvers:
                zero.2
                maven.3



The module group name is silverstone.
        The location for the modulegroup silverstone configuration is C:\cli\sebring\1110\zero\zero-repository\silverstone\site.xml.

        The following are the list of resolvers for resolving maven artifacts:
                resolver name is maven.3 and location is http://repo1.maven.org/maven2/

        The following are the list of resolvers for resolving zero modules:
                resolver name is zero.2 and location is https://www.projectzero.org/zero/silverstone/latest/repo/

        The chain resolver remote includes the following resolvers:
                zero.2
                maven.3


CWPZT0600I: Command repository info was successful

Try to switch the application to the sebring module group, for example, zero switch experimental. If you see the switch was successful, then you are switched over to the 2.x modules.

There can be the case, that the application was resolved with the experimental from the 1.x CLI and now you are using the 2.x CLI. The switch command will report that the module group hasn't changed.

C:\cli\test\app1>..\..\sebring\1110\zero\zero switch experimental
CWPZT0957E: The module is currently resolved against module group experimental
CWPZT0600I: Command switch was successful

The application still needs to be resolved when switch reported the module group hasn't changed, use zero update when this occurs, we don't want to use the resolve history in this case.

The final steps require checking that all the 2.x modules where found and then updating the application with any changes documented for Sebring applications.

-- bonanno - 11 Nov 2008