On 07.03.2010, at 11:36, Marcel Offermans
<[email protected]> wrote:
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 bundles).
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)
Definitely.
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.
Yea, good reasoning. I did not see this as a new refactoring. More the
artifacts have been accidentally (kind of) put into a single folder at
first. By partioning i saw more chances to split the work and test
their completeness.
However, i am also with finalizing the Server first.
Discussion can keep going anyway.
Toni
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] https://svn.apache.org/repos/asf/incubator/ace/trunk
[2] http://github.com/okidokiteam/exxam
