ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bram de Kruijff (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACE-316) Layout the OBR filesystem differently.
Date Tue, 16 Apr 2013 11:23:15 GMT

    [ 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

Mime
View raw message