repository boostrapping

[Stephen McConnell <mc...@apache.org>]

aok123@bellsouth.net wrote:

>>Some questions:
>>
>>* In the RepositoryLoader constructor your creating a temporary
>>  boostrap directory relative to ${user.home}.  I was wondering
>>  if it would be better to use ${java.io.tmpdir}?
>>    
>>
>
>Yeah I thought about that.  I wanted the security of the user's home directory rather than somewhere public where the bootstrap jars can be replaced.  But anywhere is good for me - did you have some reasons of your own for putting it into java.io.tmpdir?
>

No reason - more curiosity. Stay with the user's home - its fine.

>
>  
>
>>* Concerning ArtifactDescriptor - presumably this will be used
>>  as an argument to the repository
>>  e.g. repository.getArtifact( descriptor )?
>>    
>>
>
>Yes I have not gotten there yet.  I'm taking a step back to look over my path in the past couple of days.  It feels ok.  I hope to have a staged bootstrapping mechanism functional soon but I want to do it right.
>

Have been playing around with that.  I think we need to some rethinking 
on the repository.properties.  First off - I've locally (non-committed) 
updated the version of the repository spi and impl to 1.1-dev.  Without 
a distinct version difference users running a build relative to maven 
will not pick up a new version - and I don;t want to switch to snapshot 
because this is bugging in Maven. Anyway - I've pushed a 1.1-dev version 
up to ibiblio that contains an updated repository.properties that 
includes the 1.1-dev impl reference.  Using the I have a test case 
working and bootstraping the repository into existance.

But the repository.properties is icky.

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.

Thoughts?

Steve.

>
>  
>
>>Finally, on RepositoryConfig - I think we should rename
>>getLocalRepository() and setLocalRepository() to getCache() and
>>setCache() respectively - just for clarity.
>>    
>>
>
>Yes that's good because after all we're caching repo files on local disk there it really does not serve as a respo in the sense that an ibiblio does for example.  +1
>
>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