On 12/12/10 17:03, Pete Carapetyan wrote:
Richard, I think we are appearing to disagree when in fact we are
probably in perfect agreement. Making OSGi work as an implementation
is a function of manipulating bits and bytes at the file level. This
is the part of OSGi that I would eventually hope for tooling to do for
me, as Pax currently does mostly already.
What we both agree on is the modularity concerns themselves. As a
developer I cannot wish away an understanding of visibility
constraints, nor should I. The implementation can be shunted off to
tooling, but the not the design of the constraints themselves. Eclipse
itself is an example of such tooling - where one can design
constraints and allow the tooling to manage the bits and bytes at the
file level. Not such a bad thing.
Yeah, I didn't think we were disagreeing. I was just emphasizing my
original point. :-)
So, yes, I agree that tooling can make some aspects better, but
ultimately you have to understand the core modularity concepts of OSGi,
because this is about design and tools cannot guess that.
-> richard
On Sun, Dec 12, 2010 at 3:53 PM, Richard S. Hall<[email protected]> wrote:
On 12/12/10 16:46, Pete Carapetyan wrote:
To the OPS4J community I represent the mainstream corporate developer
who only wants to consume OSGi but not understand it.
A recipe for difficulties.
Trying to use something that will lay underneath your entire system, but
not
wanting to spend any time learning about it is not a good idea. If that
is
truly your plan, I'd recommend not using OSGi at all, since you'll only
come
away with a bad impression.
Please allow me to affirm - OSGi is not there yet for that kind of
attitude to be workable.
It's not such an evil idea though. When I started coding 15 years ago
anyone who used any other tool than vi was typically regarded as a
heretic. Now we use Eclipse and wait for stuff to turn red before we
remember that we mis-spelled something, or remembered that we didn't
add it to the classpath yet.
OSGi is not that hard, nor is it an end in itself. We will eventually
rely on tools to do much of the housekeeping for us, so we can focus
on the code. My opinion - even it if I'm alone on this. Pax is already
a lot closer than anything else in this regard.
You cannot ignore the visibility constraints placed on your code by OSGi. In
fact, this is the sole point of the OSGi module layer and requires a
conscious effort to make sure you do it right. Of course, it doesn't impose
much more than just striving for good design (i.e., encapsulation with only
exposing what you want to make public), but most people come from a work
where if it is "public" and it is on the class path, then it is fair game.
This attitude will lead to epic fail when using OSGi. It would be like doing
object-oriented programming and just assuming you should make everything
private or everything public, because you don't want to understand those
messy access control concepts.
-> richard
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
