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: Client :: AutoDeploy
Date Wed, 05 Oct 2011 07:15:04 GMT
Hello Jeremias,

On Oct 4, 2011, at 6:26 PM, Jeremias Maerki wrote:

> I've explained earlier what I'm looking around for. So I've been
> thinking about an "AutoDeploy" bundle which reuses FileInstall's Scanner
> class that oversees a local file system folder.

> Whenever a local artifact is added, updated or removed, it synchronizes
> it with the ArtifactRepository. When an artifact is added or removed it
> is also added or removed from a group/feature that's configurable. After
> each synchronization, the changes are committed.

That would work.

One thing to think about is when exactly to commit the changes. ACE makes updates transactional.
Typically file install acts on any change it sees. I know it has heuristics for determining
when a change is still in progress (a file being copied, new files showing up in a folder)
but this is still a big of guesswork. Not crucial during development though: if an update
gets split in half, we just wait for the other half to arrive and then try again.

Depending on the IDE or build system, you could perhaps make the "commit" an explicit action
(at the end of the build cycle of your script or triggered by some "on build succeeded" trigger
in an IDE).

> The developer (it's only useful during development time after all) can
> add that feature to a distribution which can then be deployed to targets.
> That way, a build system can just put new bundles into a directory and
> they automatically get deployed to any application instance that is
> "connected" to the observed folder.

That would be a great integration!

There are a few things to think about here:

1) For ACE, any new bundle needs a new version, if BSN+version are identical, ACE assumes
it's the same bundle, so there's no support for magic names such as "snapshot" versions. This
is not hard to solve though, usually we add a qualifier to the version that contains a datestamp
in a sortable string format.

2) For an OBR, each file needs a unique name. A lot of build systems simply overwrite the
same file (so a bundle with a BSN+version might be called <BSN>.jar where for OBR <BSN>-<version>.jar
would be better.

3) If you run ACE on your local machine, you can get away with using local file:/// URLs for
your artifacts and can skip copying them into the OBR (except that maybe for solving #2 above
you might need to make a copy anyway).

> I've done some research today to understand the client API and I think
> that should be possible.

Definitely.

> Does that make sense? Is that something that
> you think would be a good addition to ACE maybe?

Yes and yes!

> Maybe "AutoDeploy" is not the best name.

Agreed, but I don't have a brilliant suggestion yet for a better name. Anyone else? :)

Greetings, Marcel


Mime
View raw message