Trejkaz wrote:
public class Activator extends DependencyActivatorBase {
public void init(BundleContext c, DependencyManager m) {
m.add(createService()
.setInterface(FooService.class.getName(), null)
.setImplementation(FooServiceImpl.class)
.add
(createServiceDependency().setClass(BarService.class).setRequired(true))
);
}
}
I think I'll hold off on using iPOJO heavily until this is possible,
because it's great! I've never been a huge fan of XML because people
seem to throw it around and try to pretend that it isn't API (Spring
is one of the greatest offenders here.) In reality it is just more
API, but which forces you to write your program in two languages. The
Java equivalent is even more compact than the XML, and Java is already
pretty verbose!
I am no big fan of annotations, but I think they are actually less
verbose than the API-based approach, because iPOJO reads most default
values (e.g., data type) from the byte code, so they don't need to be
specified in iPOJO annotations.
Otherwise, I guess the API-based iPOJO approach will be in trunk shortly.
I'll have my little complaint though. Fluent doesn't just mean it's
Java, it means when you read it out loud it almost sounds like
English. As such you'll notice that fluent APIs don't tend to use the
word "set" in the method names.
e.g. this is fluent:
assertThat(m, isEqualTo(n));
And this is fluent:
m.add(new Service() {{
withInterface(FooService.class.getName(),
null).andImplementation(FooServiceImpl.class);
withDependencyOn(BarService.class).required();
withependencyOn(BazService.class, "(name=something)").temporal();
}});
But the examples posted in this thread thus far, I would not fit into
the fluent category. They're more like a classical builder API. Not
that there's anything wrong with that, I just don't want to see people
start abusing terminology and then (slippery slope) 2 years down the
track the entire JRE is considered to be a fluent API.
Makes sense to me.
-> richard
TX
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
