TWiki > Dev > PackageRepository	TWiki webs: Dev | Doc | Main | TWiki | Sandbox
	Dev . { Changes | Index | Search | Go }

• Principle
• Cache
• Versioning
• Publication
• Ideas, questions?

Principle

A repository specifier can be placed somewhere on the classpath (typically at the end). This means that if there is import some.pkg; in the source, and that package does not exist locally, it we be looked up in the repository. If it is found, the jar file for the latest version is downloaded, and stored in a cache. Then everything happens as if that jar was on the classpath.

There will be an official repository at http://packages.sf.net/repository/, and it should probably be included at the end of nicec's classpath by default.

Cache

The cache can be shared between projects, since jar filenames include a version number. The cache must be created somewhere the user has write access to, so on unix it would be in ~/.nice-repository/ (~ being user.home). What about other platforms (windows)? Is user.home always a good place?

Versioning

Once a project starts to use a version of an imported package, that version should stay the same until explicitely requested. Therefore, the version number must be stored somewhere. At the moment it's in a file nice.versions in the current directory. It contains lines of the form some.pkg:version. This file should be commited to the source code repository (e.g. CVS) for the project, so that every developer uses the same version, and that upgrades are tracked.

Explicit upgrades should be possible, for instance by edition of the nice.versions file. In addition, there could be a tool that tries to automatically upgrade imported packages to their newest version. After getting the new versions, it would try a compilation then unit testing. If all goes well, then the nice.versions would be automatically updated.

Publication

This is about creating packages and uploading them into a repository. First, a version number must be chosen. There is a manually chosen prefix, and an automatically attributed suffix. The prefix could be specified in the nice.versions file in the entry for the package itself, and default to 0.0 if absent. The suffix would typically be a representation of the UTC date and time, so it grows over time. This allows several versions of a package to continue to evolve in parallel. Changes of the prefix could be done when an API or behaviour change needs to break backward compatibility, and automatic upgrades would not cross those version changes.

Once the jar is created, it needs to be uploaded to a repository. Version a.b.c for package foo.bar would be located at foo/bar/foo.bar-a.b.c.jar inside the repository. It can be =scp='ed manually there. A small publication program can automate this. The question is whether it's worth to include a Java implementation of ssh (jsch is 84K in jar format), or rely on ssh/scp being installed on the system.

Alternatively, it's probably a good idea to promote continuous builds of published packages. It's especially important when packages start to import each other: you need to make sure they can use the latest versions, otherwise it will become difficult to find compatible versions. We have CVS space on package.sf.net, so we could encourage people to put libraries there. This would open the possibility to have discussions for package names, to make sure there is some coherence. Then we can install a single continuous build script, which would be triggered by CVS commits, and rebuild everything that needs to, then publish the resulting packages if they work. This is where the date suffix in versions becomes particularly handy.

Ideas, questions?

Comments are welcome.

-- DanielBonniot - 02 Aug 2004

Definitely need a java version of ssh, as ssh/scp are most definitely not available on Windows machines, and it can be a bit of a chore to find one that works the way you want without a lot of configuration difficulties.

I'll write some more later when I've had a chance to review in more detail.

-- BrynKeller - 04 Aug 2004

About ssh, the question is whether if we expect people to upload new versions manually. As I said in the part about pulication, it might be a better idea to rely on continuous builds, in which case it's not a big deal to expect ssh to be present, at least for the time being.

-- DanielBonniot - 23 Aug 2004

Ah, okay. I'd vote in favor of continuous builds, then.

-- BrynKeller - 23 Aug 2004