ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Integrating ACE into your development environment...
Date Tue, 14 Jun 2011 09:32:13 GMT
On 14 Jun 2011, at 10:31 , Bram de Kruijff wrote:

> On Mon, Jun 13, 2011 at 10:40 AM, Přemek Brada <brada@kiv.zcu.cz> wrote:
>> I'd think some first-class dev support for ACE would be a good move
>> now that the release is out; in general, "user friendly" development
>> support isn't that common in OSGi world yet, seems to me ;)
>> 
>> As Marcel mentioned, we (actually, one master student of mine) have
>> created an Eclipse plugin that is able to do quite a few things of
>> those suggested - run locally installed ACE server and target off
>> Eclipse, push the bundle created in Eclipse (via standard PDE or
>> bndtools) to the server OBR, have all the bundles in server accessible
>> as special user library on project classpath, and run the target in
>> debug mode.
>> 
>> The implementation is available from
>> https://www.assembla.com/spaces/eclipse-ace/ where both the source and
>> update site are linked. I wonder whether you think that could be a
>> start towards the IDE support Marcel sketched.
> 
> Nice, I wasn't aware of this plugin. Thanks for sharing!

I think this could be a good start!

Some implementation details can of course still be discussed, such as:

Running the server inside Eclipse vs running it outside of it (but still on "localhost").
The need to actually push bundles to an OBR vs running them directly from the local filesystem.

Anyway, I'm sure we'll get to those... :)

>> Besides that, a REST API for communicating with the server would help
>> a lot for such IDE integration. For instance, we had quite a few
>> problems reaching the correct spots in ACE to have the
>> bundle-feature-application-target mapping chain updated correctly when
>> the bundle is published to the server. At the moment, the
>> implementation actually manipulates the xml mapping files directly.

The XML mappings were never meant to be manipulated directly. We created a set of client services
that can be used by any client (web, desktop, ...) to do so. Probably your best bet at understanding
how to work with those is to study the current Vaadin based UI (there is some documentation
as well, but that's far from "complete"):
http://incubator.apache.org/ace/object-graph-in-client.html contains some information on the
entities and their attributes and how to manipulate them
http://incubator.apache.org/ace/software-architecture.html has a bit of background on the
overall architecture (see the "repositories" section)

> Agreed, I would very much like to see a RESTfull client api for the
> whole chain as well. I think there are use cases beyond IDE
> integration and basic updating of bundles. Eg. being able to setup an
> entire configuration offline (using curl or whatever) would be very
> powerful in complex (integration) test scenarios.

Agreed. The first thing we will have to do is to come up with a design for the REST API based
on these client services. That will greatly improve the types of systems we can interface
with.

For the Eclipse integration, you can still go both ways (either invoke the client services
directly or go with REST) but that then becomes more of a personal choice (what do you think
is more convenient to program against).

Greetings, Marcel


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message