You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Kevan Miller <ke...@gmail.com> on 2009/09/09 14:27:00 UTC
[DISCUSS] Release Blueprint 1.0.0
Hi Guillaume,
I guess I'd like to have some discussion about this, before voting...
If there's a desire to move this code to the new incubator project,
I'm not sure why we'd be releasing out of Geronimo, now...
Also, if we do decide to release, I wouldn't think that we'd want the
code to be in sandbox.
--kevan
Re: [DISCUSS] Release Blueprint 1.0.0
Posted by Guillaume Nodet <gn...@gmail.com>.
Thanks for pointing that.
I've fixed that in trunk and will recut a release asap.
On Wed, Sep 9, 2009 at 14:46, Rick McGuire<ri...@gmail.com> wrote:
> I think there may be a problem with the NOTICES file for the api jar files.
> The sources contained there are the OSGi-developed API files. The files
> contain the OSGi copyright, but the NOTICES file only states that his
> contains software developed at the Apache Software Foundation. There's no
> OSGi attribution.
>
> Rick
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Release Blueprint 1.0.0
Posted by Rick McGuire <ri...@gmail.com>.
I think there may be a problem with the NOTICES file for the api jar
files. The sources contained there are the OSGi-developed API files.
The files contain the OSGi copyright, but the NOTICES file only states
that his contains software developed at the Apache Software Foundation.
There's no OSGi attribution.
Rick
Re: [DISCUSS] Release Blueprint 1.0.0
Posted by David Jencks <da...@yahoo.com>.
On Sep 9, 2009, at 1:29 PM, Quintin Beukes wrote:
> What is Blueprint. I had a look around on the site and can't find it
> there.
The code is currently at https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/trunk
It's an implementation of OSGI RFC 124. An early draft of the spec is
available inside http://www.osgi.org/Download/File?url=/download/osgi-4.2-early-draft2.pdf
, but I think there have been a lot of changes since then. IIUC the
final spec draft should be public soon if it isn't already.
Anyway, blueprint is pretty much xml-based spring cleaned up and
running in an osgi environment.
thanks
david jencks
>
> Q
>
> On Wed, Sep 9, 2009 at 7:49 PM, Kevan Miller
> <ke...@gmail.com> wrote:
>>
>> On Sep 9, 2009, at 12:37 PM, David Jencks wrote:
>>
>> Without some major justification I'm seriously -1 on releasing from
>> the
>> sandbox. I don't see any problem with moving this code to
>> components and
>> releasing it from there, whether or not it then moves somewhere else.
>>
>> Agreed that we should not release from sandbox. I'm a bit reluctant
>> about a
>> release, but nor do I see a big reason not to release and don't
>> want to
>> cause problems for Karaf. So, I'm good with a components release.
>> --kevan
>
>
>
> --
> Quintin Beukes
Re: [DISCUSS] Release Blueprint 1.0.0
Posted by Quintin Beukes <qu...@skywalk.co.za>.
What is Blueprint. I had a look around on the site and can't find it there.
Q
On Wed, Sep 9, 2009 at 7:49 PM, Kevan Miller <ke...@gmail.com> wrote:
>
> On Sep 9, 2009, at 12:37 PM, David Jencks wrote:
>
> Without some major justification I'm seriously -1 on releasing from the
> sandbox. I don't see any problem with moving this code to components and
> releasing it from there, whether or not it then moves somewhere else.
>
> Agreed that we should not release from sandbox. I'm a bit reluctant about a
> release, but nor do I see a big reason not to release and don't want to
> cause problems for Karaf. So, I'm good with a components release.
> --kevan
--
Quintin Beukes
Re: [DISCUSS] Release Blueprint 1.0.0
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 9, 2009, at 12:37 PM, David Jencks wrote:
> Without some major justification I'm seriously -1 on releasing from
> the sandbox. I don't see any problem with moving this code to
> components and releasing it from there, whether or not it then moves
> somewhere else.
Agreed that we should not release from sandbox. I'm a bit reluctant
about a release, but nor do I see a big reason not to release and
don't want to cause problems for Karaf. So, I'm good with a components
release.
--kevan
Re: [DISCUSS] Release Blueprint 1.0.0
Posted by Rick McGuire <ri...@gmail.com>.
David Jencks wrote:
> Without some major justification I'm seriously -1 on releasing from
> the sandbox. I don't see any problem with moving this code to
> components and releasing it from there, whether or not it then moves
> somewhere else.
I'm also uncomfortable for the release tag for this being in the
sandbox. Too easy for this to be deleted accidentally from there.
>
>
> Another option is to copy it to servicemix for this release.
>
> Here are some nit's I'd prefer to see fixed or explained before release:
>
> 1. Most subprojects' NOTICE file are hardcoded rather than using
> appended-resources w/remote-resources-plugin. Does every non-test
> bundle really include non-apache software?
I was just checking on this very thing. Neither the blueprint-core jars
nor the blueprint-cm jars contain the OSGi API classes, so their NOTICES
probably should not include the OSGi reference.
>
> 2. the Bundle-Symbolic-Name values are ${artifactId} rather than the
> default from the bundle plugin. I'd really prefer to see "geronimo"
> somewhere in the name
I agree. The symbolic name should be more fully qualified.
> .
>
> 3. I don't understand what most of the stuff in blueprint-bundle
> pom.xml is for and I'd prefer to see it explained. My experiments
> lead me to suspect you don't need the maven-shade-plugin. What is the
> motivation for this bundle in the first place?
>
> 4. blueprint.xsd is not a geronimo schema but it's under
> org/apache/geronimo/blueprint.
>
> 5. blueprint-api uses jar packaging. Why?
>
> In general I'd like to see descriptions in the poms for noobs like me.
>
> thanks
> david jencks
>
> On Sep 9, 2009, at 5:27 AM, Kevan Miller wrote:
>
>> Hi Guillaume,
>> I guess I'd like to have some discussion about this, before voting...
>>
>> If there's a desire to move this code to the new incubator project,
>> I'm not sure why we'd be releasing out of Geronimo, now...
>>
>> Also, if we do decide to release, I wouldn't think that we'd want the
>> code to be in sandbox.
>>
>> --kevan
>
>
Re: [DISCUSS] Release Blueprint 1.0.0
Posted by Guillaume Nodet <gn...@gmail.com>.
2009/9/9 David Jencks <da...@yahoo.com>:
> And another thing... why do we need the servicemix repo listed in the root pom? Shouldn't anything there be on maven central as well?
The latest equinox jar which is used for integration tests is not
available on central. I've created a maven upload request
(MAVENUPLOAD-2587) for that and asked Dan Kulp to push it, but Jazon
Van Zyl is working with the eclipse guys to make everything available
in central. From what I heard, he is reluctant to put new artifacts
there in the mean time, but the mean time is measured in months. So
I had no real other choice than referring to an external repository
:-(
> thanks
> david jencks
>
> On Sep 9, 2009, at 10:11 AM, David Jencks wrote:
>
>>
>> On Sep 9, 2009, at 9:37 AM, David Jencks wrote:
>>
>>> Without some major justification I'm seriously -1 on releasing from the sandbox. I don't see any problem with moving this code to components and releasing it from there, whether or not it then moves somewhere else.
>>>
>>> Another option is to copy it to servicemix for this release.
>>>
>>> Here are some nit's I'd prefer to see fixed or explained before release:
>>>
>>> 1. Most subprojects' NOTICE file are hardcoded rather than using appended-resources w/remote-resources-plugin. Does every non-test bundle really include non-apache software?
blueprint-api includes the apis, blueprint-core includes the core
schema and blueprint-cm includes a schema that is copyrighted from the
OSGi alliance. It has not been released yet (and is bound to change
before being released), so I've changed the namespace to be geronimo
specific, but the file really comes from OSGi. The blueprint-bundle
is a shaded bundle of the three above, so actually needs this NOTICE.
If you know a better way to put non default NOTICE files using the
remote-resources-plugin, I'd be happy to know. I did not really want
to create a new project to generate a remote resource bundle for that.
>>>
>>> 2. the Bundle-Symbolic-Name values are ${artifactId} rather than the default from the bundle plugin. I'd really prefer to see "geronimo" somewhere in the name.
Sounds good. I think I'll change the artifact names directly to
org.apache.geronimo.blueprint.xxx instead.
>>>
>>> 3. I don't understand what most of the stuff in blueprint-bundle pom.xml is for and I'd prefer to see it explained. My experiments lead me to suspect you don't need the maven-shade-plugin. What is the motivation for this bundle in the first place?
Right, we don't. Stricly speaking. The only reason is to have the
blueprint-bundle jar having nice source and javadoc jars associated.
We use the maven bundle plugin to create the jar itself, but then the
associated source and javadocs are just empty. I'll remove the
commented sections, but I don't think we should change the way it's
done, unless you have a simplier way to do that. Given the
blueprint-bundle is really the one that will be used in most of the
cases, I wanted it to have really clean and complete source / javadoc
associated jars.
>>>
>>> 4. blueprint.xsd is not a geronimo schema but it's under org/apache/geronimo/blueprint.
>>
>> I would think that putting the spec schema(s) in the api jar would be a lot more appropriate. Is there some reason they aren't included there?
I could do that, but I'm really reluctant. I can't put it in the
org.osgi.service.compendium package, because if the implementation is
wired to another package which does not include this resource, the
implementation will be screwed. I could put it in
org.apache.geronimo.blueprint package inside the api, but it would
result in split packages. I guess I'll add it to the api bundle, but
include a copy in the core bundle, so that users can easily find it in
the api jar and the implementation will use its own copy in the core
bundle. Though I usually try to avoid having multiple versions of
the same file in svn ... I'll see what I can do.
>>
>> thanks
>> david jencks
>>
>>>
>>> 5. blueprint-api uses jar packaging. Why?
I can't think of a good reason. I'll change it to bundle.
>>>
>>> In general I'd like to see descriptions in the poms for noobs like me.
Will add those.
>>>
>>> thanks
>>> david jencks
>>>
>>> On Sep 9, 2009, at 5:27 AM, Kevan Miller wrote:
>>>
>>>> Hi Guillaume,
>>>> I guess I'd like to have some discussion about this, before voting...
>>>>
>>>> If there's a desire to move this code to the new incubator project, I'm not sure why we'd be releasing out of Geronimo, now...
>>>>
>>>> Also, if we do decide to release, I wouldn't think that we'd want the code to be in sandbox.
I'll move it into
https://svn.apache.org/repos/asf/geronimo/components/ as suggested by
David.
>>>> --kevan
>>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Release Blueprint 1.0.0
Posted by David Jencks <da...@yahoo.com>.
And another thing... why do we need the servicemix repo listed in the
root pom? Shouldn't anything there be on maven central as well?
thanks
david jencks
On Sep 9, 2009, at 10:11 AM, David Jencks wrote:
>
> On Sep 9, 2009, at 9:37 AM, David Jencks wrote:
>
>> Without some major justification I'm seriously -1 on releasing from
>> the sandbox. I don't see any problem with moving this code to
>> components and releasing it from there, whether or not it then
>> moves somewhere else.
>>
>> Another option is to copy it to servicemix for this release.
>>
>> Here are some nit's I'd prefer to see fixed or explained before
>> release:
>>
>> 1. Most subprojects' NOTICE file are hardcoded rather than using
>> appended-resources w/remote-resources-plugin. Does every non-test
>> bundle really include non-apache software?
>>
>> 2. the Bundle-Symbolic-Name values are ${artifactId} rather than
>> the default from the bundle plugin. I'd really prefer to see
>> "geronimo" somewhere in the name.
>>
>> 3. I don't understand what most of the stuff in blueprint-bundle
>> pom.xml is for and I'd prefer to see it explained. My experiments
>> lead me to suspect you don't need the maven-shade-plugin. What is
>> the motivation for this bundle in the first place?
>>
>> 4. blueprint.xsd is not a geronimo schema but it's under org/apache/
>> geronimo/blueprint.
>
> I would think that putting the spec schema(s) in the api jar would
> be a lot more appropriate. Is there some reason they aren't
> included there?
>
> thanks
> david jencks
>
>>
>> 5. blueprint-api uses jar packaging. Why?
>>
>> In general I'd like to see descriptions in the poms for noobs like
>> me.
>>
>> thanks
>> david jencks
>>
>> On Sep 9, 2009, at 5:27 AM, Kevan Miller wrote:
>>
>>> Hi Guillaume,
>>> I guess I'd like to have some discussion about this, before
>>> voting...
>>>
>>> If there's a desire to move this code to the new incubator
>>> project, I'm not sure why we'd be releasing out of Geronimo, now...
>>>
>>> Also, if we do decide to release, I wouldn't think that we'd want
>>> the code to be in sandbox.
>>>
>>> --kevan
>>
>
Re: [DISCUSS] Release Blueprint 1.0.0
Posted by David Jencks <da...@yahoo.com>.
On Sep 9, 2009, at 9:37 AM, David Jencks wrote:
> Without some major justification I'm seriously -1 on releasing from
> the sandbox. I don't see any problem with moving this code to
> components and releasing it from there, whether or not it then moves
> somewhere else.
>
> Another option is to copy it to servicemix for this release.
>
> Here are some nit's I'd prefer to see fixed or explained before
> release:
>
> 1. Most subprojects' NOTICE file are hardcoded rather than using
> appended-resources w/remote-resources-plugin. Does every non-test
> bundle really include non-apache software?
>
> 2. the Bundle-Symbolic-Name values are ${artifactId} rather than the
> default from the bundle plugin. I'd really prefer to see "geronimo"
> somewhere in the name.
>
> 3. I don't understand what most of the stuff in blueprint-bundle
> pom.xml is for and I'd prefer to see it explained. My experiments
> lead me to suspect you don't need the maven-shade-plugin. What is
> the motivation for this bundle in the first place?
>
> 4. blueprint.xsd is not a geronimo schema but it's under org/apache/
> geronimo/blueprint.
I would think that putting the spec schema(s) in the api jar would be
a lot more appropriate. Is there some reason they aren't included
there?
thanks
david jencks
>
> 5. blueprint-api uses jar packaging. Why?
>
> In general I'd like to see descriptions in the poms for noobs like me.
>
> thanks
> david jencks
>
> On Sep 9, 2009, at 5:27 AM, Kevan Miller wrote:
>
>> Hi Guillaume,
>> I guess I'd like to have some discussion about this, before voting...
>>
>> If there's a desire to move this code to the new incubator project,
>> I'm not sure why we'd be releasing out of Geronimo, now...
>>
>> Also, if we do decide to release, I wouldn't think that we'd want
>> the code to be in sandbox.
>>
>> --kevan
>
Re: [DISCUSS] Release Blueprint 1.0.0
Posted by David Jencks <da...@yahoo.com>.
Without some major justification I'm seriously -1 on releasing from
the sandbox. I don't see any problem with moving this code to
components and releasing it from there, whether or not it then moves
somewhere else.
Another option is to copy it to servicemix for this release.
Here are some nit's I'd prefer to see fixed or explained before release:
1. Most subprojects' NOTICE file are hardcoded rather than using
appended-resources w/remote-resources-plugin. Does every non-test
bundle really include non-apache software?
2. the Bundle-Symbolic-Name values are ${artifactId} rather than the
default from the bundle plugin. I'd really prefer to see "geronimo"
somewhere in the name.
3. I don't understand what most of the stuff in blueprint-bundle
pom.xml is for and I'd prefer to see it explained. My experiments
lead me to suspect you don't need the maven-shade-plugin. What is the
motivation for this bundle in the first place?
4. blueprint.xsd is not a geronimo schema but it's under org/apache/
geronimo/blueprint.
5. blueprint-api uses jar packaging. Why?
In general I'd like to see descriptions in the poms for noobs like me.
thanks
david jencks
On Sep 9, 2009, at 5:27 AM, Kevan Miller wrote:
> Hi Guillaume,
> I guess I'd like to have some discussion about this, before voting...
>
> If there's a desire to move this code to the new incubator project,
> I'm not sure why we'd be releasing out of Geronimo, now...
>
> Also, if we do decide to release, I wouldn't think that we'd want
> the code to be in sandbox.
>
> --kevan
Re: [DISCUSS] Release Blueprint 1.0.0
Posted by Rick McGuire <ri...@gmail.com>.
There's also the question of whether we should be releasing this before
the blueprint spec is officially released. This should be soon, but I
don't think the voting on the RI and CT has completed yet. There is
always the possibility of a last second change.
Rick
Kevan Miller wrote:
> Hi Guillaume,
> I guess I'd like to have some discussion about this, before voting...
>
> If there's a desire to move this code to the new incubator project,
> I'm not sure why we'd be releasing out of Geronimo, now...
>
> Also, if we do decide to release, I wouldn't think that we'd want the
> code to be in sandbox.
>
> --kevan
>
Re: [DISCUSS] Release Blueprint 1.0.0
Posted by Guillaume Nodet <gn...@gmail.com>.
I know that the code may be moved at a later point, but I really need
a release of blueprint for Karaf which should be released in the
coming days.
I'm happy to move the code to a non sandboxed location if that looks
better, but i personnally would rather wait until the final location
for this piece of code is known and agreed (be it Aries or somewhere
else, including Geronimo).
As far as the TCK is concerned, I really don't think we need to wait
for that. Felix Framework is being released too, the Felix
ConfigAdmin which the RI has been released already, all of those
including the updated OSGi specs. In addition, if there is a need to
fix stuff, we can always do that in a bug fix release if needed. We
don't necesseraly have to claim passing the TCK, and we could wait for
the TCK to be officialy vote by the OSGi alliance before running it
and see what it gives. If it passes, fine, we can claim that, if it
does not, we can always do a bug fix release.
If I can't make my point, I'll have to use a timestamped version of
blueprint for Karaf, but I'd really like to avoid that as much as
possible and use official releases. Official does not mean bug free,
so again, I don't think we need to hold this vote for the reasons Rick
and Kevan mentioned. I would personally be happy to wait if that
would not delay the Karaf release too much.
On Wed, Sep 9, 2009 at 14:27, Kevan Miller<ke...@gmail.com> wrote:
> Hi Guillaume,
> I guess I'd like to have some discussion about this, before voting...
>
> If there's a desire to move this code to the new incubator project, I'm not
> sure why we'd be releasing out of Geronimo, now...
>
> Also, if we do decide to release, I wouldn't think that we'd want the code
> to be in sandbox.
>
> --kevan
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com