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. 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
