> >>I think we should not use repository.properties from the jar file - but > >>instead - read it in using getTempFile relative to a well know address. > >>Pull in it in and then bootstrap from the external properties file. > >>This lets us focus on the resource.properties generation under the > >>repository package (where we can use POM dependencies to generate it > >>automatically) - then publish it. This means that we can automatically > >>trigger updating of the repository implementation by updating the remote > >>repository.properties file.
<snip/> > >So the code that pulls down the properties file must be aware of the release > >version of the repository-spi. It can do this in several ways. It can be hard > >coded but who wants that or it can be determined from another properties file > >within the jar. Is there a way to embedd the property into the manifest? > > > > Its already there. > Implementation-Version: 1.1-dev > > >Now I feel we're getting more complicated than we have to. > > > > String spiVersion = > RepositoryLoader.class.getPackage().getImplementationVersion(); That's not complicated at all. Sounds great to me this is falling into place very nicely. > But this assumes that RepositoryLoader or whatever is actually in the > classloader as a result of loading a jar file which may not always be > the case. Right. > However, it would be easy to add the POM based version as a > property using a bit of jelly in maven.xml. Cool but your first option of reading the version from the manifest sounds cleaner. It is always the same value as the POM version right? Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
