avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: repository boostrapping
Date Mon, 03 Nov 2003 23:18:37 GMT


aok123@bellsouth.net 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: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message