[EMAIL PROTECTED] wrote:
Have been playing around with that. I think we need to some rethinking on the repository.properties.
But the repository.properties is icky.
<snip/>
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.
That's smart - I like it. So let me see - thinking out loud now. We generate the repository.properties file from the project.xml in the repository-spi
Yep.
on the fly and have it hangling out there in the repo as another artifact rather than a jar file resource. Then we pull down the repository.properties from the repo as an artifact and load it to download the bootstraping dependencies.
Yep.
What ever we do the repository.properties file as a repo artifact must use the same versioning scheme. Meaning for the 1.1-dev release of the avalon-repository-spi we would have a repository-1.1-dev.properties file. Bottom line is we must avoid version collisions by differentiating the artifact by revision like any other repo artifact.
Yep.
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();
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. However, it would be easy to add the POM based version as a property using a bit of jelly in maven.xml.
Steve.
In the end we are going to have to generate something that gets packaged into the jar that makes the code release version aware so it can pull down dependency info from the repo.
Perhaps the best route to take is to just auto-generate the repository.properties file from the POM on jar creation and package it in. I have no solid idea just thinking out loud here. Anyway the properties file becomes a build byproduct generated from the POM rather than a cvs resource.
Perhaps the best route for us is to write a goal into the project within the maven.xml?
Alex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
