ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Přemek Brada <br...@kiv.zcu.cz>
Subject Re: Integrating ACE into your development environment...
Date Thu, 16 Jun 2011 10:34:31 GMT
On 14 June 2011 11:32, Marcel Offermans <marcel.offermans@luminis.nl> 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 filesystem.

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.

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

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.

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

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

Premek


-- 
Premek Brada (Ing et MSc, PhD)
  Lecturer in Software enginering, Webmaster
  Department of Computer Science and Engineering
  University of West Bohemia in Pilsen, CZ
  << brada at kiv.zcu.cz | www.kiv.zcu.cz/~brada/ | +420-377-63-2435 >>

Mime
View raw message