ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <tonit....@googlemail.com>
Subject Re: ace-target-devgateway up and running!
Date Sun, 07 Mar 2010 12:17:12 GMT


On 07.03.2010, at 11:36, Marcel Offermans  
<marcel.offermans@luminis.nl> 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
>
>

Mime
View raw message