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 ;)
Regards
JB
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 IDE.
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
