ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: ace-target-devgateway up and running!
Date Sun, 07 Mar 2010 10:36:33 GMT
Hello Toni,

On Mar 6, 2010, at 20:19 , Toni Menzel wrote:

> yep, can confirm that it works also with a custom target that previously
> worked with the ant based build.

Thanks for confirming that.

> Going from that point, will start partitioning this endless list of
> artifacts (see [1] )

Taking it step by step I would prefer that we first make sure that the artifacts that were
defined in [1] are "fixed" so they exactly match the original bundles so we can confirm that
the web based (and possibly file based) server work like in the Ant build.

> into something similar to that [2].

Next step would then be to start grouping those artifacts similar to something you propose
in [2] (or like we do in Apache Felix). Before we start moving things around, I would prefer
having a working server first. Next step would then be to discuss how we actually want to
group things. The Ant based build basically grouped things based mostly on the deployment
view of the system, having groups like "gateway" (now called "target" in our new terminology)
and "server". The idea behind that was that those were different "execution environments"
that needed their own compiler settings and since we mainly used Eclipse we needed those to
be in different Eclipse projects.

> We currently have:
> [   1] [Active     ] [    5] Apache ACE - Configurator (0.8.0.SNAPSHOT)
> [   2] [Active     ] [    5] Apache ACE - ConsoleLogger (0.8.0.SNAPSHOT)
> [   3] [Active     ] [    5] Apache ACE - Deployment (0.8.0.SNAPSHOT)
> [   4] [Active     ] [    5] Apache ACE - Deployment Task (0.8.0.SNAPSHOT)
> [   5] [Active     ] [    5] Apache ACE - Discovery Property based
> (0.8.0.SNAPSHOT)
> [   6] [Active     ] [    5] Apache ACE - Gateway Log (0.8.0.SNAPSHOT)
> [   7] [Active     ] [    5] Apache ACE - Gateway Log Store (0.8.0.SNAPSHOT)
> [   8] [Active     ] [    5] Apache ACE - Identification API
> (0.8.0.SNAPSHOT)
> [   9] [Active     ] [    5] Apache ACE - Log (0.8.0.SNAPSHOT)
> [  10] [Active     ] [    5] Apache ACE - Log Listener (0.8.0.SNAPSHOT)
> [  11] [Active     ] [    5] Apache ACE - Scheduler (0.8.0.SNAPSHOT)

> So, i think there will be a "gateway" group and one for server (=folder).

We had it like that, but I'm not 100% convinced that it's the best idea, because, like you
propose below, we could also split up the source base into functional modules. If you do that,
then it might make more sense to have everything that belongs to such a module in one place.
After all, we're building loosely coupled, reusable components here, so the less emphasis
we place on the physical deployment view, the better.

> Next to that, i am thinking if its a good idea to make a fine granular split
> like that:
> + log
> + identification
> + deployment
> + discovery
> + repository (contains also the obr bundles. but have to look closer into
> the server artifacts)
> + ui (things like webconsole, the felixwebconsole plugin, shell commands and
> so on)
> + spice or common (contains things that do not fit into one of the others
> and are likely something like utility stuff --> e.g. log)

We should, in my opinion, end up with fairly cohesive modules (that consist of a handful of

> In the end i think the whole partitioning should satisfy the following needs
> + logical grouping. So if i am going to understand the ace repository
> principles and implementation, i should find everything in "repository".

Yes, and that is why I'm not sure about the "top level" server/gateway division. I'd rather
look in "repository" for everything that's about repositories.

> + (if possible) just a minimum cross group dependencies. (for example,
> identification builds completely, then discovery, then deployment -> layers)


For example, we recently had a discussion about our scheduler and the one in Apache Sling.
Making both API compatible makes a lot of sense. We should also ensure our scheduler is a
stand alone component that can easily be deployed in any environment that needs scheduling.
Btw, this one already can be deployed like that, we've reused it in quite a few projects now.

> + ease the completion of all other artifacts that don't work (yet) -->
> server and server-webui targets.

This is what I'm not sure about, if you mean first re-arranging and then getting things working
again. I really thing we should first get things working before we start "refactoring" the
build. I also feel that this should not be a hard process. We know what each bundle should
look like exactly.

> Not sure if this is enough to kick off a discussion here - at least it
> should be possible to protect me from totally dumb decisions when doing
> that.

I think it's a good moment to have this discussion (before we start moving things around).
In the mean time I would propose we fix our bundles for the server, because at the moment
it's hard for people to work on different components since "nothing works" ;)

Greetings, Marcel

> [1]
> [2]

View raw message