ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: Integrating ACE into your development environment...
Date Fri, 17 Jun 2011 18:31:32 GMT
Hello Premek,

On 16 Jun 2011, at 12:34 , Přemek Brada wrote:

> On 14 June 2011 11:32, Marcel Offermans <> wrote:
>> 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").
> Yes, we went the (for us) easiest way for the start, running the
> server outside Eclipse. Running it in-process should make things
> easier for communicating with it; see below.
>> The need to actually push bundles to an OBR vs running them directly from the local
> We weren't aware (did not study the server's implementation enough
> probably) that the bundles need not be pushed to OBR. Again, running
> them from the local filesystem would be nice simplification.

The ACE server, when defining a new artifact, just needs a URL to load this artifact from.
By default, this is a URL that points to an OBR, but any URL will do.

>>>> 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"):
>> contains some information
on the entities and their attributes and how to manipulate them
>> has a bit of background
on the overall architecture (see the "repositories" section)
> This is certainly a thing which needs to be refactored.  To explain
> the design, we started before the Vaadin UI was in the creation, the
> student wasn't successful at analysing the working of the previous UI,
> and anyway running the server outside Eclipse made these services
> inaccessible (they are local, not remote, if I understand it
> correclty). Of course we wouldn't mess up with the XML directly if we
> knew a way to do it.

Those services are not necessarily local. For example, in the past we had a Swing based client,
so those client bundles can either live on a client or on the server (where we tied them up
to web sessions so we are able to have multiple clients run side by side).

But okay, it's something we can refactor!

>>> 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.
> Yes; we'll try to put together ideas what kind of API would be useful
> from the ACE IDE implementation we did.

Ok, great.

>> 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).
> If we use the REST API, we could have the IDE connect to a standalone
> server/repository which I think could be handy if more people develop
> bundles for the same app managed by a "dev server". Invoking locally
> limits that to the single developer's local (in-process) server.

As explained above, that is not necessarily true, but I fully agree that a REST based API
would be very flexible, so let's go for that!

Greetings, Marcel

View raw message