[
http://jira.amdatu.org/jira/browse/AMDATU-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868#comment-12868
]
Marcel Offermans commented on AMDATU-599:
-----------------------------------------
Historically, there is also the "ace-repository-provider-filebased", which was
a shortcut we initially took when building the server. It has more or less
similar limitations to the Ant task. From its JavaDoc:
{code}
/**
* This class reads data from the filesystem. It contains deployment data in
the following format: <storage dir>/<target-name>/<bundle-version>/<jars>
* example : storage-directory/ storage-directory/target-a
storage-directory/target-a/1.0.0
* storage-directory/target-a/1.0.0/bundle1.jar
storage-directory/target-a/1.0.0/bundle2.jar storage-directory/target-a/1.1.0
* storage-directory/target-a/1.1.0/bundle2.jar
storage-directory/target-a/1.1.0/bundle3.jar The versions are in the
* org.osgi.framework.Version format.
*/
public class FileBasedProvider implements DeploymentProvider, ManagedService {
{code}
There are a couple of things to explore before starting a design:
* The most basic version of such a service would literally build deployment
packages based on artifacts and metadata that you feed it, focussing only on
building a deployment package from that metadata. It would be the
responsibility of the caller to provide all artifacts, their mime types, the
correct resource processors for them and make sure they're ordered correctly
within the stream.
* A more advanced version could be "smart" by leveraging the ArtifactHelper and
ArtifactRecognizer in ACE, both of which are used to recognize artifacts and
make sure that eventually the right resource processor ends up in the
deployment package. This would make life more convenient for the caller.
* In essence, this is what the ACE server does, and both the definition of the
deployment package and the "extraction" of it are now fully REST controllable.
An option therefore would be to simply launch an ACE server, feed it the
artifacts and extract the deployment package on the other end. A potential
downside is that this might not be the quickest way (but we can probably make
the server more lightweight by a) removing some features we don't need in this
scenario and b) selecting more lightweight implementations for others (thinking
about replacing Jetty with the more lightweight HTTP server in Felix for
example).
> Create DeploymentPackage generator
> ----------------------------------
>
> Key: AMDATU-599
> URL: http://jira.amdatu.org/jira/browse/AMDATU-599
> Project: Amdatu
> Issue Type: Task
> Reporter: Bram de Kruijff
> Fix For: Backlog
>
>
> There are many cases where it may be handy to be able to generate
> DeploymentPackage which are the basis for provisioning. Unfortunatly, ACE
> only provides a streaming implementation coupled to ACE/OSGi and an ANT task
> that only supports bundles and is coupled to ANT.
> Therefore it seems wise to create a DeploymentPackage "generator"
> library/service that can re-reused. Sample use cases are:
> * Creating DeploymentPackage artifacts from any build ANT/Maven
> * Creating DeploymentPackages on the fly in integration test cases
> (AMDATU-591)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
http://jira.amdatu.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Amdatu-developers mailing list
[email protected]
http://lists.amdatu.org/mailman/listinfo/amdatu-developers
