ace-commits mailing list archives

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


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


* 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:
>             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:

View raw message