aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amardeep Bhattal (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARIES-929) install subsystems from IDirectory objects
Date Tue, 20 Nov 2012 16:08:58 GMT

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

Amardeep Bhattal commented on ARIES-929:
----------------------------------------

In response to Tom ...

Yes we're basically handing an IDirectory over to be installed, rather than a URL of a file
that may be opened as a ZipInputStream (which is then turned into an IDirectory object). We
can spec the URL to include values for symbolic name and version if required, I'd hope to
have those done in exactly the same way as for subsystem scheme URLs. I do agree that having
a protocol handler for such a scheme is a potentially nice approach as it removes the need
for the IDirectoryFinder interface in Apache Aries, but we don't really want to take "loose"
content from an IDE, gather it up, and compress it so we can present a ZipInputStream. If
it's possible to implement a ZipInputStream that delivers uncompressed content, then this
may be a more viable route - perhaps a bit more elegant externally, but probably more complex
to implement. Ultimately it seemed the simplest thing to do given we can easily represent
our installation data as an IDirectory (regardless of where the actual files are), and given
the install code just opens the URL to generate an IDirectory, was to hand the IDirectory
over directly, so that's the route we took.

In response to John ...

Yes the code was committed by Mark, so in that respect this item is complete. If you are happy
to add an "install(IDirectory)" method to an interface, that would be the simplest approach
of all, but we'd assumed that wasn't feasible as the OSGi spec for the Subsystem interface
does not include such a method. If you're happy to add one anyway, or to add one on a sub-interface,
that could be a good (and straightforward) way to go. I'd be happy with that.
                
> install subsystems from IDirectory objects
> ------------------------------------------
>
>                 Key: ARIES-929
>                 URL: https://issues.apache.org/jira/browse/ARIES-929
>             Project: Aries
>          Issue Type: Improvement
>          Components: Subsystem
>    Affects Versions: 0.4
>         Environment: n/a
>            Reporter: Amardeep Bhattal
>            Assignee: Mark Nuttall
>             Fix For: 0.4
>
>         Attachments: org.apache.aries.subsystem.core.patch, org.apache.aries.subsystem.itests.patch,
org.apache.aries.util-r42.patch
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Subsystems may be installed by calling Subsystem.install(String) (and also the install(String,
InputStream) method). The code treats the given location string as a URI string which can
be opened to obtain installation artifacts, unless the URI has a scheme of "subsystem" in
which case an alternative leg of code is executed to install a persisted subsystem.
> It would be useful to extend this mechanism to add a new scheme ("idirfinder") which
is also treated in special way; in this case the URI is passed to a service which can return
a corresponding IDirectory object that matches the given URI, which the install code can then
use to install a subsystem using the contents of the IDirectory. To achieve this, a modification
to the subsystem install code is required (though not extensive as IDirectory objects are
already used internally during install), and an interface for the IDirectory finder service
must be defined.
> Adding this functionality would allow installation of subsystems from a variety of sources,
including expanded archive, loose config (installation artifacts distributed across disk as
produced by IDEs), in-memory etc as the only requirement is then to provide an IDirectory
front-end to the content. The alternative of gathering the content and producing an archive
file is not desirable due to the overhead this entails, particularly when an IDE is being
used for rapid development, and small changes are being made frequently.

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