[
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