ME likes!!! I am going through hoops to get that worked out...
Are we sticking it into 1.3 ? On Thu, Mar 10, 2011 at 11:46 AM, Rickard Öberg <[email protected]> wrote: > Hi, > > I've been thinking about the bootstrap procedure, and the now common > problem of assemblers having to take arguments for "visibility" (most > commonly), and how maybe it would be possible to separate those things > out. > > One thing we did with layers and modules was to change from "addLayer" > to "layerAssembly", so that code could reference the same layer many > times without creating more layers. This is basically a declarative > rather than imperative approach. One might say: "duh". > > How about we use the same for Module artifacts? Instead of: > module.addServices(SomeService.class,OtherService.class).visibleIn(Visibility.application); > > we could do: > module.services(SomeService.class,OtherService.class).visibleIn(Visibility.application); > and then there would be no problem to do: > module.services(SomeService.class).identifiedBy("someservice"); > > With this in place we could then open up for specification-based > settings, such as: > // Expose all services in layer > module.services(Specifications.TRUE).visibleIn(Visibility.layer); > i.e. ModuleAssembly would have: > ServiceDeclaration services(Class<? extends ServiceComposite>... > serviceTypes); > and > ServiceDeclaration services(Specification<Class> serviceSpecification); > > or if we separate the current ServiceDeclaration so that it is the > fluent API only, and put the actual settings for a particular service > in ServiceAssembly, then it could be: > ServiceDeclaration services(Specification<ServiceAssembly> > serviceSpecification); > where the Specification could inspect any aspect of the current > assembly to figure out whether it should be worked on by the > ServiceDeclaration. > > With this we would get a more declarative approach to assembly, and > can more easily separate various responsibilities and general > settings. > > Whaddyathink? > > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
