On Thu, Sep 10, 2009 at 23:35, David Jencks <david_jen...@yahoo.com> wrote:
> I updated the NOTICE file generation to use the recommended remote-resources
> plugin techniques.
>
> I would still like to see something change on:
>
> 1. I still think that the spec xsds need to be in the spec jar and nowhere
> else and available from the spec jar. I haven't understood any arguments
> about why this requires more than one copy or why its a bad idea. Why
> should an alternative blueprint implementation that wants to use our api jar
> need to include its own copy of the schema?
First, remember that we are in a pure OSGi environment.
Second, the small jars (i.e. not the blueprint-bundle one) are mostly
here for separating concerns, but the real artifact to be deployed is
the blueprint-bundle. If you deploy the other ones, you won't be
fully compliant with the spec. The reason is that the spec clearly
specifies that the org.osgi.service.blueprint package should have a
"uses" clause that lists the implementation specific packages that can
be used by clients. In our case, there are some interfaces defined
in the blueprint-core bundle that are exported. The reason for all
that is to make sure that you end up in a consistent state if you have
multiple blueprint extenders in your framework.
Third, the spec does not say that this schema should be made available
at that location, so this is implementation specific. I've included
it there only because i think it will be easier for users to find it.
Last, let's assume you deploy another blueprint implementation. You
have no way to know exactly which api package you will be wired to.
So if you're no wired to your own version of the jar, but to the other
implementation jar, maybe this other implementation will not have the
schema available at the same location, so you can't really rely on
that. So you *need* the other copy internally. If you don't want
multiple copies, we'd have to remove the one from the api jar as it
was previously.
Any other implementation would have to do the same because the spec
does not specify that the schema should be included in the api
package.
> 2. I see that the core and cm bundles don't import what they export. Not
> importing what you export still makes be extremely uneasy. Maybe one can
> argue that the cm bundle is a library since it doesn't appear to export any
> services or have a bundle activator, but the core bundle is surely not a
> library since it registers a bundle listener. Unless there is clear harm in
> importing what we export I would really prefer to follow this principle
> everywhere and couple it with careful version specification in imports and
> exports.
Again, those bundles are not really supposed to be deployed. If it
makes you uncomfortable, I'd rather make them plain jars and not
bundles. But I suppose the same apply to blueprint-bundle too, which
only imports/exports the blueprint api packages.
That said, I've been hit by this problem before and I can try to
re-explain a bit. It's about backward compatibility and consistency
of your class path.
First, make sure we understand what the framework does. When a
bundle export and import the same package, it won't actually do both
at the same time.
When the bundle is resolved, the framework will choose to have the
bundle *either* export the package *or* import it, and the spec does
not mandate any particular option if both can be done. Not that
importing the package necesseraly implies that all constraints are
satisfied (such as uses clauses, version ranges, etc...) along with
consistency in the classloader. Both equinox and felix frameworks
will choose to import the pacakge rather than export it if the
constraints can be satisfied afaik.
Now, let's take an example:
We have two classes:
package foo.bar.api;
interface Interface {
}
package foo.bar.impl;
class Implementation implements Interface {
}
bundle A: exports foo.bar.api;version=1.0
imports foo.bar.api;version=1.0
exports foo.bar.impl;version=1.0
imports foo.bar.impl;version=1.0
bundle B: exports foo.bar.api;version=1.0
imports foo.bar.api;version=1.0
exports foo.bar.impl;version=1.1
imports foo.bar.impl;version=1.1
Also, let's say both those bundles have an OSGi BundleActivator that
will register a service implementing Interface (from the class
Implementation).
We first deploy bundle A, so the framework will make this bundle
export both packages:
bundle A: exports foo.bar.api;version=1.0
exports foo.bar.impl;version=1.0
Now we deploy bundle B. The foo.bar.api is compatible, so the
framework will import this package, but the version for foo.bar.impl
is too low, so this package will be exported:
bundle B: imports foo.bar.api;version=1.0 (from bundle A)
exports foo.bar.impl;version=1.1
In this case, everything is fine. bundle A and B will use their own
implementation classes.
Now, let's say the bundles are deployed in the opposite order.
We first deploy bundle B:
bundle B: exports foo.bar.api;version=1.0
exports foo.bar.impl;version=1.1
The bundle A:
bundle A: imports foo.bar.api;version=1.0
imports foo.bar.impl;version=1.1
The framework will choose to import the foo.bar.impl package, because
this version is compatible with the constraints from bundle A:
version >= 1.0.
What happens now ? Bundle A will not see it's own classes in package
foo.bar.impl, but the classes from bundle B.
This means that the service exported by bundle A will be the same than
the service exported by bundle B. I think this is really unexpected,
but let's go further. The Implementation class is not part of the
API, so it may change between different versions. Let's say that
between version 1.0 and 1.1, the class has been renamed to
MyImplementation. Bundle A will try to load the Implementation class
and this will result in a NoClassDefFoundError. Really unexpected.
So as I said, this is really about backward compatibility. In the
java world, we tend to define interfaces to hide implementation
details behing a known contract. You don't want people to use
implementation classes directly because any incompatible change would
break the whole thing. That's really the same here. I certainly
don't want to have to maintain full backward compatibility on all
implementation details, and neither have people depending on those
classes.
In our case, the blueprint-cm bundle defines an OSGi service, which is
a geronimo custom namespace handler for the namespace
"http://geronimo.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0";.
This service implements org.apache.geronimo.blueprint.NamespaceHandler
interface. This is an imported package and actually, I think
blueprint-cm should not export any package.
I think it would be easier to turn them into plain jars to avoid confusion.
> 3. I'm pretty unhappy with the maven project names at the moment. I'd
> prefer to see them go back to simple names and use the bundle plugin default
> behavior to generate the bundle symbolic names to include the
> org.apache.geronimo fluff.
I'm not strong on that. All the artifacts from felix uses this naming
scheme. I think when you end up with a list of jars in a flat
directory, it's easier to deal with, but i agree it's kinda redundant
in a maven repo. If you really want to change, I'm suggesting to use:
geronimo-blueprint-core
geronimo-blueprint-api
geronimo-blueprint-cm
geronimo-blueprint (instead of blueprint-bundle)
> I also got an itest failure trying to build but haven't investigated yet.
>
>
> thanks
> david jencks
>
> On Sep 10, 2009, at 12:11 PM, Guillaume Nodet wrote:
>
>> Just committed some changes.
>> Please review and I'll upload a new release asap.
>>
>> On Thu, Sep 10, 2009 at 21:05, Kevan Miller <kevan.mil...@gmail.com>
>> wrote:
>>>
>>> On Sep 10, 2009, at 12:44 PM, Guillaume Nodet wrote:
>>>
>>>> On Thu, Sep 10, 2009 at 17:54, Kevan Miller <kevan.mil...@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Sep 10, 2009, at 4:29 AM, Guillaume Nodet wrote:
>>>>>
>>>>>> I've uploaded a new 1.0.0 release of the blueprint project.
>>>>>> I think I've addressed all the issues raised in the discussion thread.
>>>>>>
>>>>>> The staging repository is available at:
>>>>>>
>>>>>> https://repository.apache.org/content/repositories/geronimo-staging-054/
>>>>>>
>>>>>> The corresponding tag is available at
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://svn.apache.org/repos/asf/geronimo/components/blueprint/tags/blueprint-1.0.0/
>>>>>>
>>>>>> Please review and vote:
>>>>>> [ ] +1 Release
>>>>>> [ ] -1 Do not release
>>>>>>
>>>>>> The vote will remain open for 72 hours.
>>>>>
>>>>> The following files do not contain apache source license headers.
>>>>>
>>>>>
>>>>>
>>>>> ./blueprint-api/src/main/java/org/osgi/service/blueprint/container/package.html
>>>>>
>>>>>
>>>>> ./blueprint-api/src/main/java/org/osgi/service/blueprint/container/packageinfo
>>>>>
>>>>>
>>>>> ./blueprint-api/src/main/java/org/osgi/service/blueprint/reflect/package.html
>>>>>
>>>>>
>>>>> ./blueprint-api/src/main/java/org/osgi/service/blueprint/reflect/packageinfo
>>>>
>>>> Those come straight from the blueprint OSGi from the osgi alliance
>>>> afaik.
>>>> I can add them with the OSGi alliance copyright, but I'm not even sure
>>>> what's the comments syntax for the packageinfo file
>>>
>>> OK. I should have noticed that these were in blueprint-api. I would not
>>> add
>>> anything to them.
>>>
>>>>> ./blueprint-core/src/main/resources/OSGI-INF/permissions.perm
>>>>> ./blueprint-core/src/test/resources/cache.xsd
>>>>> ./blueprint-core/src/test/resources/test-bad-id-ref.xml
>>>>> ./blueprint-core/src/test/resources/test-constructor.xml
>>>>> ./blueprint-core/src/test/resources/test-depends-on.xml
>>>>> ./blueprint-core/src/test/resources/test-generics.xml
>>>>> ./blueprint-core/src/test/resources/test-simple-component.xml
>>>>> ./blueprint-core/src/test/resources/test-wiring.xml
>>>>> ./blueprint-core/src/test/resources/test.xml
>>>>> ./blueprint-sample/src/main/resources/OSGI-INF/blueprint/config.xml
>>>>
>>>> Those need to be fixed, right.
>>>>
>>>>> Unless convinced otherwise, I think those must be fixed.
>>>>>
>>>>> The README should be updated to not reference 1.0.0-SNAPSHOT. Also, the
>>>>> README instructions do not reference the correct maven
>>>>> groupid/artifactid
>>>>> for blueprint bundles:
>>>>>
>>>>> Current:
>>>>>
>>>>>
>>>>> file:///<m2_repo>/org/apache/geronimo/blueprint-bundle/1.0.0-SNAPSHOT/blueprint-bundle-1.0.0-SNAPSHOT.jar
>>>>> Should be:
>>>>>
>>>>>
>>>>> file:///<m2_repo/org/apache/geronimo/blueprint/org.apache.geronimo.blueprint.bundle/1.0.0/org.apache.geronimo.blueprint.bundle-1.0.0.jar
>>>>
>>>> Yeah, the REAME is outdated. I'll have a look.
>>>
>>> Let me know, and I can update, if you want. Strings are still in my emacs
>>> buffer... ;-)
>>>
>>>>
>>>>> Was there any NOTICE information associated with the original OSGi
>>>>> Alliance
>>>>> source? If so, it might need to be moved over...
>>>>
>>>> I haven't seen any NOTICE files from the OSGi Alliance, but will
>>>> double check to make sure.
>>>
>>> Thanks.
>>>
>>> --kevan
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
