ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré>
Subject Re: Integrating ACE into your development environment...
Date Fri, 10 Jun 2011 15:25:25 GMT
Hi Marcel,

You're right around the download page and "communication" around the 
release. I'm gonna update the wiki adding an announce and the download link.

1/ I'm fully agree about usage of ACE during development. Does it mean 
that we will provide plugin for Eclipse and/or IntelliJ supporting ACE. 
If it's the case, why not thinking a kind of UI in Eclipse IDE, even for 
production system ? We should also support a kind of branding for UI.

2/ Now that the release if out, we need to work on the documentation. I 
propose to use the mechanism used in Apache Camel: the documentation 
"source" is on the wiki and we will be able to generate an user guide 
extracted from the wiki and generating professional PDF documents (using 
Prince XML).

2'/ Around new features, I'm gonna resume the full support of Karaf next 
week, both as a runtime container for ACE and a supported target 
(including features).
I have also in mind to provide AutoDeploy/Kalumet feature in ACE (system 
command support, etc).

Next week will be an ACE one for me ;)


On 06/10/2011 04:42 PM, Marcel Offermans wrote:
> Hey guys,
> With the first release out the door (incidentally, did everybody already check out the
download page?), it's time to start working on some new features. One important thing is that
I'd like to more tightly integrate ACE into development environments so you can start using
it right away (instead of it just being used in production). Actually, I've been discussing
this a bit off list with Bram, and I'd like to summarize the ideas we have and invite everybody
here to provide feedback.
> Using ACE during development basically means we want to make the development cycle the
same as the one used later during testing and production. That means we want to run a local
ACE server and a target that basically gets updated every time you "save some change" and
"build new bundles". How you do that obviously depends on the IDE and build tooling you use
and there's lots of different ones out there. In the end they all produce one or more bundles
though, and we'd like ACE to import those immediately and deploy them to the local target.
> We can already run an ACE server and target on localhost, so that's our starting point.
The server could be launched independently of the IDE you use, the target we might want to
launch inside the IDE to facilitate easy debugging and feedback inside the console of the
> As your build cycle will already produce an artifact on the local machine, we don't really
need an OBR in this case. From within the ACE server we can directly point to a file URL.
That saves us one extra copy step. So as soon as bundles have been built, we want to push
them into ACE. For that we'd like to provide a REST client API that can either be used alongside
the web UI or instead of it. Integrating different build and IDE systems based on a REST API
is probably pretty straightforward, so that's why I think this is a good choice here.
> As soon as new or updated bundles have been added (and features and distributions defined)
we can commit the changes and need to notify the target that there's something new to install.
For that the server needs to send this notification (which for the general case might be troublesome
since the server might not be able to reach the target, but in this case is no problem). The
management agent on the target can then listen of these and poll for updates. It no longer
needs to use the periodic scheduler, so we can disable that.
> WDYT? Any thing we're forgetting, can we be even smarter? ;)
> Greetings, Marcel

View raw message