You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Guillaume Nodet <gn...@gmail.com> on 2009/09/10 10:29:09 UTC
[VOTE] Release Blueprint 1.0.0 (3thd try)
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.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
[CANCEL][VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by Guillaume Nodet <gn...@gmail.com>.
Cancelling this vote.
On Thu, Sep 10, 2009 at 10:29, Guillaume Nodet <gn...@gmail.com> 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.
>
> --
> 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
Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Sep 11, 2009 at 09:39, David Jencks <da...@yahoo.com> wrote:
>
> On Sep 11, 2009, at 12:19 AM, Guillaume Nodet wrote:
>
>> On Thu, Sep 10, 2009 at 23:35, David Jencks <da...@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.
>
> Does osgi work better if you package interfaces and implementation together
> in the same bundle? IIUC you are saying here that the blueprint service is
> really designed to only work this way.
So the schema is a side issue I think. But in OSGi, everything is
about modularity and if you want to really leverage OSGi, you need to
carefully design your bundles. If don't have an extensive experience
in this area, and other felix guys might be better able to answer, but
usually, the best way to achieve that is to package the interface
packages with the service implementation in a single bundle (for
bundles that mostly expose a standalone OSGi service). If you have a
whiteboard pattern, you don't really want to include the api in each
service. But services like the OSGi preference services,
configuration admin, HTTP service, etc... are best done this way
afaik.
I think having too fined grained bundles is not ideal, but having too
coarsed grained bundles either ...
For blueprint, the spec says the following:
"A Blueprint extender must not manage a Blueprint bundle if there is a class
space incompatibility for the org.osgi.service.blueprint packages. For
example, if the Blueprint bundle uses the BlueprintContainer class, then it
must import the org.osgi.service.blueprint.container package. The Blue-
print extender and the Blueprint bundle must then share the same class
space for this package. Type compatibility can be verified by loading a class
from the blueprint packages via the Blueprint extender bundle and the Blue-
print bundle’s loadClass methods. If the Blueprint bundle cannot load the
class or the class is identical to the class loaded from the extender, then the
two bundles are compatible for the given package. If the Blueprint extender
is not class space compatible with the Blueprint bundle, then Blueprint
extender must not start to manage the Blueprint bundle."
and also:
"To mitigate type incompatibility problems, a Blueprint extender must
export the org.osgi.service.blueprint package. In the uses: directive, it
should list any packages of classes that can be shared between the Blueprint
extender and the Blueprint bundle. Blueprint bundles should import this
package."
Those problems comes from the fact that Blueprint is an extender and
is not a plain OSGi service, so things have to be carefully done to
avoid class space inconsistencies.
>>
>>> 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.
>
> I need some time to digest this. Meanwhile.... it seems to me that two
> other solutions to this problem are:
> 1. don't export the implementation classes
> 2. use restrictive version ranges on the implementation packages. (Of
> course this implies that you can predict the future of your classes) For
> instance, if A imported foo.bar.impl;version:=[1.0,1.1) then it could not
> import B's 1.1 version.
Right, those are the two solutions. In this very case, given the
blueprint-api, -core and -cm are not really supposed to be used
directly, but they are all embedded in blueprint-bundle, I think we
should just make them plain jars. It just removes the problem.
We had this very discussion on the camel dev list a few days ago, and
the constraints have to be thought carefully.
What we decided is:
* for third party dependencies: use a range up to the next major
version, i.e. [2.1,3)
* for inter camel dependencies, use a range up to the next minor
version, i.e. [2.1,2.2)
* for a few jars that are tightly tied together at implementation
level, use a closed range: i.e. [2.1,2.1]
> many thanks for the detailed example!
> david jencks
>>
>>> 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 <ke...@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Sep 10, 2009, at 12:44 PM, Guillaume Nodet wrote:
>>>>>
>>>>>> On Thu, Sep 10, 2009 at 17:54, Kevan Miller <ke...@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
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by David Jencks <da...@yahoo.com>.
On Sep 11, 2009, at 12:19 AM, Guillaume Nodet wrote:
> On Thu, Sep 10, 2009 at 23:35, David Jencks <da...@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.
Does osgi work better if you package interfaces and implementation
together in the same bundle? IIUC you are saying here that the
blueprint service is really designed to only work this way.
>
>> 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.
I need some time to digest this. Meanwhile.... it seems to me that
two other solutions to this problem are:
1. don't export the implementation classes
2. use restrictive version ranges on the implementation packages. (Of
course this implies that you can predict the future of your classes)
For instance, if A imported foo.bar.impl;version:=[1.0,1.1) then it
could not import B's 1.1 version.
many thanks for the detailed example!
david jencks
>
>> 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 <ke...@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.miller@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
Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Sep 10, 2009 at 23:35, David Jencks <da...@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 <ke...@gmail.com>
>> wrote:
>>>
>>> On Sep 10, 2009, at 12:44 PM, Guillaume Nodet wrote:
>>>
>>>> On Thu, Sep 10, 2009 at 17:54, Kevan Miller <ke...@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
Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 10, 2009, at 5:35 PM, David Jencks 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?
>
> 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.
>
> 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 wasn't happy with the names, but saw they were consistent with Felix.
> I also got an itest failure trying to build but haven't investigated
> yet.
I saw 1 failure running with Java 6. I also had a clean run with Java
6. Seemed to be a test timeout, but didn't look in detail. Here's the
failure:
Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 23.163
sec <<< FAILURE!
testManagedServiceFactory [equinox/3.5.0]
(org.apache.geronimo.blueprint.itests.TestConfigAdmin) Time elapsed:
11.263 sec <<< ERROR!
java.lang.RuntimeException: Gave up waiting for service
(&(objectClass=org.osgi.service.blueprint.container.BlueprintContainer)
(osgi
.blueprint.container.symbolicname=org.apache.geronimo.blueprint.sample))
--kevan
Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by David Jencks <da...@yahoo.com>.
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?
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.
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 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 <ke...@gmail.com>
> wrote:
>>
>> On Sep 10, 2009, at 12:44 PM, Guillaume Nodet wrote:
>>
>>> On Thu, Sep 10, 2009 at 17:54, Kevan Miller <ke...@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
Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 10, 2009, at 3:11 PM, Guillaume Nodet wrote:
> Just committed some changes.
> Please review and I'll upload a new release asap.
Looks good.
--kevan
Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by Guillaume Nodet <gn...@gmail.com>.
Just committed some changes.
Please review and I'll upload a new release asap.
On Thu, Sep 10, 2009 at 21:05, Kevan Miller <ke...@gmail.com> wrote:
>
> On Sep 10, 2009, at 12:44 PM, Guillaume Nodet wrote:
>
>> On Thu, Sep 10, 2009 at 17:54, Kevan Miller <ke...@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
Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 10, 2009, at 12:44 PM, Guillaume Nodet wrote:
> On Thu, Sep 10, 2009 at 17:54, Kevan Miller <ke...@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
Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by David Jencks <da...@yahoo.com>.
On Sep 10, 2009, at 1:43 PM, Alan D. Cabrera wrote:
>
> On Sep 10, 2009, at 9:44 AM, Guillaume Nodet wrote:
>
>> On Thu, Sep 10, 2009 at 17:54, Kevan Miller
>> <ke...@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
>
> Should these maybe be released separately, like the spec jars?
They are already in a separate bundle/jar, and since there's a good
chance that all of the blueprint implementation will go elsewhere soon
I'm not sure its a good idea to move the api jar away from the impl
jar. In principle however I think that would be a good next step when
a more final location for blueprint is clear.
thanks
david jencks
>
>
> Regards,
> Alan
>
Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
On Sep 10, 2009, at 9:44 AM, Guillaume Nodet wrote:
> On Thu, Sep 10, 2009 at 17:54, Kevan Miller <ke...@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
Should these maybe be released separately, like the spec jars?
Regards,
Alan
Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Sep 10, 2009 at 17:54, Kevan Miller <ke...@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
> ./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.
> 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.
>
> Everything else looked good to me.
>
> --kevan
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Posted by Kevan Miller <ke...@gmail.com>.
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
./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
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
Was there any NOTICE information associated with the original OSGi
Alliance source? If so, it might need to be moved over...
Everything else looked good to me.
--kevan