[ 
https://issues.apache.org/jira/browse/ACE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632759#comment-13632759
 ] 

Bram de Kruijff commented on ACE-316:
-------------------------------------

Comitted in r1468366. 

The OBR is now in control of the location on disk an this is reflected in the 
API. A create is will return an 201 with a location header identifying where 
the resource is located. The layout is based upon bsn/version (eg. 
org/apache/bla/org.apache.bla-1.0.0.jar).

The default strategy for determining bsn/version is based upon the bundle 
manifest headers. If the resource is not a bundle a fallback to the now 
optional filename parameter is attempted expecting something like  
<bsn>(-<version>)?(.<extension>)?. If a bsn but no version is found the version 
defaults to "0.0.0".

A complicating factor proved to be the VelocityArtifactPreprocessor that also 
uploads processed templates. As i duplicates the OBR upload logic and made 
assumption on that it could assume filename I had to make some behavioral 
changes there. As for configuration resources we must use the filename strategy 
mentioned above it does the following; Assuming the template is of form 
<bsn>-<version>.<extension> a generated variant will be of form 
<bsn>.<targetID>-<targetVersion>.<extension>.

Questions:

* OBR upload code is duplicate over the ArtifactRepositoryImpl and the 
VelocityArtifactPreprocessor passing the OBR around as a string uri. Should we 
not introduce a client service and/or will that be adressed when we introduxe 
real repository services?

* Should the VelocityArtifactPreprocessor (mis)use the obr? We can not assume 
that that will work with an actual (upstream) repository service in the future 
and it is creating a lot of garbage in there. Why not keep those generated 
variants local?




                
> Layout the OBR filesystem differently.
> --------------------------------------
>
>                 Key: ACE-316
>                 URL: https://issues.apache.org/jira/browse/ACE-316
>             Project: ACE
>          Issue Type: Question
>          Components: OBR
>            Reporter: Marcel Offermans
>            Assignee: Bram de Kruijff
>
> Currently, the OBR uses a single folder to store all artifacts. That does not 
> scale too well as OS specific directory limits might interfere. We should 
> implement a more hierarchical storage format, such as: <BSN>/<version> or 
> even one where each part of the BSN becomes a folder.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to