On Tue, Feb 26, 2008 at 7:02 PM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> Simon Laws wrote: > > Sebastien > > > > This looks interesting. Can you say a little about how this will be > used. > > I'm interested as I'd like to see us open up the contribution service a > bit > > and provide some interfaces that allow us to operate on contributions > (find > > artifacts, read artifacts, resolve artifacts etc.) rather than having > the > > contribution service as a black box. Is this where you are going? > > > > Simon > > > > Yes that's where I'm going :), I'm trying to implement discrete > functions to: > - add/list/remove contributions/composites/nodes > - analyze/resolve/validate contributions and their dependencies > - read/compile-build/write composites without requiring a runtime > > ContributionScanner is similar to PackagingProcessor but without URIs > (which bloat memory with a big workspace) and without an InputStream > (which doesn't apply to contribution directories). > > For everything else I'm trying to reuse as much of the underlying model, > for example use artifact processors for turning contributions into > contribution models, use model resolvers to resolve contribution > dependencies (see the other changes to contribution-impl in SVN r631293). > > I'm planning to commit the analyze/validate/find-dependencies functions > to module workspace-impl. > > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Ok, sounds great. I would add another line to the functions list. Something like... - associate composites with nodes/apply physical binding defaults/propagate physical addresses based on domain level wiring I'm collecting these various bits of info here ( http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Contribution+Processing) as I come across them in the hope that we can build some documentation. Simon
