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 < [email protected]> wrote: > On Feb 19, 2010, at 10:19 , Toni Menzel wrote: > > > On Fri, Feb 19, 2010 at 9:31 AM, Carsten Ziegeler <[email protected]> > 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 [email protected] http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
