Hello David, On Jul 24, 2009, at 21:35 , David Savage wrote:
One of the open areas it would be good to get feed back from the community is around the problem of class space visibility and the different semantics at compile and runtime.
What I would like to do is to look at this from an architectural point of view. When developing an application, I often use the "4+1 view" [1], and the views we're dealing with here are: 1) the "development view", dealing with components and packages, which basically maps to our compile time view of the application, and 2) the "physical view" (or "deployment view"), which deals with "the allocation of artifacts to nodes" and basically deals with the runtime view you mention above.
In my mind, these views are different by design and my main reason for not liking both the Eclipse and the Maven models (one bundle per project/pom) is that they completely ignore these differences and force everybody into thinking both should be the same.
One of the goals of Sigil is to use the same semantics at compile time as used by OSGi to build a class space at runtime.
If you stick to the idea that both views are not the same then let's look at each view in more detail.
The development view, when creating an application, is usually a consistent class space, built out of both code you develop and third party code you use. In general, this maps quite nicely onto a single IDE project.
The deployment view is basically something you create out of the classes that were created in the development view. You can look at this view as some kind of mapping that describes how classes (or packages) are grouped into bundles. I could imagine having some kind of XML model that describes this mapping and that can somehow be validated.
[...] but equally it seems kinda bizarre to be adding another dimension to this whole problem when people are worried about the complexity of OSGi. If there is a way to do this without exposing developers to it that would be /great/ but as with OSGi I don't think we should worry about doing the right thing at the base layer IDE tools and other schemes can always simpilify this whole space down again to joe blogs. I guess it's a question of what is "right".
I agree here, we should first try to figure out what is "right" and from there make it "easier". Of course, part of "easier", at least in my book, would mean that whatever we come up with is not tied to a single IDE implementation (at least I don't fancy writing and maintaining multiple IDE integrations).
So I guess the end result of this email is, what are your thoughts?
I skipped parts of your mail, because I wanted to discuss some overall concepts first.
* Is anyone still there (i.e. has this email lost you all?)?
I hope so! :) Greetings, Marcel [1] http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model
