Sorry, by abstracting new ones, the purpose is not to reinvent the
wheel, it's to fill the gap (for instance to create the persistence.xml).
I agree: the samples should reuse the existing and propose new one to
deal the gaps.
Regards
JB
On 09/13/2015 07:51 PM, Christian Schneider wrote:
The CDI and JEE annotations are exactly taylored to the enterprise use
cases. I doubt that we can create better ones.
Abstracting away from the technology can only mean you introduce another
layer of indirection. This can only make sense if the underlying
technology is crappy which I think is not the case.
I am looking forward to see what you propose but I think reinventing the
whole set of annotations will probably not be the way to go. We saw this
path in the karaf 4 commands and I think the result is not good.
Instead I propose we look at the annotations and examples you provide
and think how they could be implemented with existing standards + a
minimal set of additional
annotations that fit well into an existing technology.
Christian
Am 13.09.2015 um 19:13 schrieb Jean-Baptiste Onofré:
Hi Christian,
Workload is one thing, multi-dependencies/pom/etc is something.
In the annotations, even if the workload is the same, it's the kind of
annotations. The purpose is to provide more high level, use case
centric annotations, more than low level technical one.
I agree that we could extend the maven-blueprint-plugin, but I would
prefer to keep it more high level and decoupled from the underlying
technology involved.
karaf-boot purpose is to be straight forward and avoid the "big mess &
soup about what should I use, what the version, etc".
I'm still convince that at least a BoM provided by karaf-boot is
interesting.
I'm also still think that an abstract Karaf oriented is valid.
Regards
JB
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
