I agree with Bob. One important
difference we make in Hudson is, rather than supporting 1000's of
plugins by keeping backward compatibilities with outdated
technologies, we take bold steps to move to new technologies and
try to keep the core more stable, scalable and modern. On the
process we may keep only few 100s of most important plugins
working better on the modern core. But that is sufficient for
enterprises with huge Hudson installation looking for a much
stabler CI server.
Having said that, we have a bug existing for more than a year
stating
Hudson
does not work when deployed to Glassfish 4.x. I'm wondering
if this simple workaround is stable enough to include it in the
next bugfix release and then take up the task of moving to the
standard DI implementation.
Now comes the question, which is the standard DI ?
I have very limited knowledge of CDI. Based on my understanding
(through limited reading)
CDI
= DI + additional contexts. In Hudson we use only DI (Guice).
There are three DI implementations (Guice, HK2, Spring). Weld
which is a
CDI reference
implementation, has its own DI (I think it is simplified spring
DI) and additional contexts.
Theoretically I would think the DI in CDI would be switchable (or
play nicely with other DI). That means either you use the default
DI in Weld or plug in Guice/
HK2 as DI. Looks like
Glassfish 4.x is making
HK2 work with CDI.
Do we need to have the full CDI (which is a superset) bundled in
Hudson or use only the subset but standard DI in Hudson so that
when we run on EE7 containers with CDI already in place, the
bundled DI becomes "inactive" allowing the container CDI to take
over (or am I just being ignorant here
:-) ).
So which one is the standard DI -- HK2, Guice, Spring, Weld DI?
- Winston
I think the future is upon is. My humble opinion is
we need to find a CDI-compatible implementation that will work
fine with Tomcat and Jetty (and I guess Glassfish for the
diehards).
Editorial comment: Hudson can't continue to be a graveyard
for old technologies.
Whatever we choose, thanks, Kaz, for digging into this!
_______________________________________________
hudson-dev mailing list
hudson-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hudson-dev