[kepler-dev] [Bug 4702] KAR to module conversion utility

Thu Feb 11 14:11:44 PST 2010

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4702

--- Comment #8 from David Welker <welker4kepler at gmail.com> 2010-02-11 14:11:43 PST ---
Aaron,

This is an inappropriate conversation for this forum. This issue has already
been decided. You have already had the opportunity to express your views and
you failed to persuade others. Deal with it. When it comes to Kepler, no one
always gets what they want or think best. This definitely includes me.

We had good reasons to take a different approach. We decided against OSGi for
many reasons including reasons:

(1) The complexity that it would foist developers. For example, take this
comment from an OSGi-advocate about his experiences trying to implement OSGi at
IBM:

<blockquote>
"As you may imagine, one of the most important goals was to hide OSGi as much
as possible. No services, no Import-Package (but Require-Bundle on one
aggregation bundle), basically reduce OSGi to its minimum. Well, the
appreciation was… limited. All people I was working with were exceptional
bright and determined researchers in MLP. They developed highly sophisticated
algorithms on how to analyze unstructured data, but only a few were software
engineers. So the code was… working, but not production ready. Enforcing them
to apply rules that ultimately made it harder for them getting things done and
as a result slowing them down wasn’t something they welcomed very much."
</blockquote>

Our primary mission at Kepler is to facilitate the development of software that
advances the interests of scientists, not slow it down. In the quote above, the
OSGi advocate explains the frustrations of trying to implement OSGi within a
SINGLE institution. We at Kepler are responsible for creating a platform for
MANY institutions. Adding the complexities of OSGi to the development process
to achieve a small incremental advantage in hiding the implementation of
modules from each other (while sacrificing the ability to do overrides) was
discussed and rejected, given our mission. It makes more sense to stick to
mainstream Java development rather than have kepler-dev become a place where a
primary activity is the fielding a constant barrage of OSGi-related questions.

(2) OSGi may have been developed over 10 years, but it was developed outside of
the Java Community Process and the problems it was meant to address are
different than the problems we are trying to address. The original context of
OSGi was primarily cell phones, where the "modules" tend to be unrelated apps.
Also, there is the issue of security, where want to close off your module from
others. In our context of scientific development, we want our modules to be
more open and there it is both permissible and desirable for one module to
modify the functioning of another in the context of a particular suite. The
overheads of OSGi may be a great solution for cell phones and for development
teams within a single organization. That does not mean it is a great solution
for us.

(3) Before the flexibility of overrides, many participants in Kepler have found
it impossible collaborate with each other. As a result, they tended to fork
their own implementations of Kepler with whatever add-on functionality they
wanted. If we had made the decision to go with OSGi, that would have been the
end of overrides and would have lead to developers to tend to fork. The simple
fact of the matter is, the negotiation costs of making every minor change you
need in someone else's code is simply too high when you have a deadline to
solve a particular scientific problem that is not primarily about Kepler, but
used Kepler. Another point is that OSGi was developed over 10-years has another
implication which you probably would prefer not to talk about. It is old
software. The thing about old software is that mistakes tend to be built into
the software and are hard to get rid of. Take for example the issue of closures
in Java. The reason that closures were not included in Java in the first place
was because of time pressure related to doing the first release. But, it was
found that callbacks in Java were simply too tedious. Having inadequate time to
implement closures, the creators of Java settled on allowing anonymous class
definitions with methods. This is an ugly solution, to say the least. But, it
has remained in place. Only now, with the release of JDK 7 in September, is
Java going to include support for closures. The thing about old software like
OSGi or the JDK is that old mistakes or implementations built for a different
context tend to persist. That OSGi is really really old at 10 years of age, is
not necessarily an argument in its favor.

(4) With the release of JDK 7, which is currently scheduled for September,
there will be built-in Java language features that facilitate modules. Also,
JDK 7 itself is being broken up using Project Jigsaw, a project which has
language features being developed to support it and which will also be
available to others who are interested in taking a similar approach to
modularization. IF we were to use a third-party rather than custom approach to
modules, it would be much more sensible to compare OSGi to the approach taken
by Project Jigsaw. After all, there is a REASON that Sun decided to break up
the JDK itself using a new approach rather than using OSGi. Apparently, they
didn't want to be saddled with all of the complexities and old decisions of
OSGi either. This should be a huge red flag telling you to look before you
leap.

(5) Have you installed something using Eclipse lately? I have. I just installed
a tool for the Google App Engine. And guess what. I had to restart Eclipse in
order for it to work properly. It only partially worked before restarting. Hot
deployment using OSGi apparently doesn't always work out so well after all. I m
not blaming OSGi, but you would be a fool to think it magically solves our
problems, really reduces complexity, or lessens the amount we need to
understand with respect to such issues. As developers, we are going to have to
research and understand in depth all the issues that make hot deployment
successful or not successful and provide guidelines to module developers IF we
even decide that this is that desirable of a feature, regardless.

The bottom-line is this. The decision to not go with OSGi was carefully thought
through, whether you agree with it or not. You had your chance to make your
case. You failed to persuade others. That should be the end of it. Certainly,
using Bugzilla right before the 2.0 release to air your grievances about
decisions that have already been made and that you participated in is simply
not optimal.

-- 
Configure bugmail: http://bugzilla.ecoinformatics.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.