You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ace.apache.org by Toni Menzel <to...@okidokiteam.com> on 2010/03/06 20:19:06 UTC
Re: ace-target-devgateway up and running!
yep, can confirm that it works also with a custom target that previously
worked with the ant based build.
Going from that point, will start partitioning this endless list of
artifacts (see [1] )
into something similar to that [2].
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).
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)
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".
+ (if possible) just a minimum cross group dependencies. (for example,
identification builds completely, then discovery, then deployment -> layers)
+ ease the completion of all other artifacts that don't work (yet) -->
server and server-webui targets.
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.
Toni
[1] https://svn.apache.org/repos/asf/incubator/ace/trunk
[2] http://github.com/okidokiteam/exxam
On Fri, Feb 19, 2010 at 10:59 AM, Marcel Offermans <
marcel.offermans@luminis.nl> wrote:
> On Feb 19, 2010, at 10:19 , Toni Menzel wrote:
>
> > On Fri, Feb 19, 2010 at 9:31 AM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> >> Toni Menzel wrote:
> >>> Cool guys! Nice to see discussion here ;)
> >>> Because this (interesting) thread is now 2 weeks old, whats the status
> >>> with this?
> >>> Just ask before i get into this. Last mail ("need coffee") sounds
> >>> inspiring but also raises a question about pending work.
> >>>
> >> The build now works for me - at least it builds :) I haven't checked if
> >> it is running afterwards.
> >
> > Well.. it builds since ever.. It should WORK ;) Will give it a rewamp
> > after the Devcon/JAX buzz..
>
> Indeed, the issue is that the build does not yet produce exactly the same
> artifacts as the original Ant build, therefore it does not work yet.
>
> The target works.
> The web based server does not.
>
> This is a matter of comparing bundles and fixing bnd/pom files, so it
> should not be too hard for anybody to work on.
>
> Greetings, Marcel
>
>
--
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
toni@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
Re: ace-target-devgateway up and running!
Posted by Toni Menzel <to...@googlemail.com>.
On 07.03.2010, at 11:36, Marcel Offermans
<ma...@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
>
>
Re: ace-target-devgateway up and running!
Posted by Marcel Offermans <ma...@luminis.nl>.
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.
> 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