You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Karl Pauls <ka...@gmail.com> on 2010/03/01 01:03:19 UTC
Re: [VOTE] Release Karaf 1.4.0
-1
I'm really sorry but it looks to me like:
org/apache/felix/karaf/deployer/features/FeatureURLHandler.java
org/apache/felix/karaf/shell/commands/EchoAction.java
are missing the license header and
manual/pom.xml
client/dependency-reduced-pom.xml
are missing a header as well. Furthermore,
org.apache.felix.karaf.deployer.spring and a lot of the other modules
have dependencies on spring-core which is not mentioned in the notice
nor in the overall src notice (its mentioned in the overall binary
notice).
Other findings (not show-stoppers) are:
Signatures and checksums work for me but for some reason there are not
only .asc but .asc.asc and .asc.md5/sha and .asc.asc.md5/sha files
around. Very strange (probably something wrong with nexus/maven - not
sure we can do something about it).
Other than that, it looks to me like you are only building the jars
and the sources jars but not the bin and project artifacts we usually
do. Not a problem as such (as you still have the sources for each
artifact) but its somewhat different from what we do normally ...
Some artifacts are still using the osgi jars from felix (they should
switch to use the official org.osgi artifacts as soon as possible).
regards,
Karl
On Wed, Feb 24, 2010 at 7:57 PM, Chris Custine <cc...@apache.org> wrote:
> The Karaf 1.4.0 artifacts have been staged for release.
>
> These release artifacts contain updated copyright year in all NOTICE files
> and includes an updated RELEASE-NOTES file which was not updated in the
> previous release vote. As requested by Richard, I have noted that the vote
> will be open for *at least* 72 hours in order to allow time for proper
> review.
>
> Release notes are here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&styleName=Html&version=12314410
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-015/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 015 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
>
> --
> Chris Custine
> FUSESource :: http://fusesource.com
> My Blog :: http://blog.organicelement.com
> Apache ServiceMix :: http://servicemix.apache.org
> Apache Felix :: http://felix.apache.org
> Apache Directory Server :: http://directory.apache.org
>
--
Karl Pauls
karlpauls@gmail.com
Re: [VOTE] Release Karaf 1.4.0
Posted by David Jencks <da...@yahoo.com>.
> <snip>
>>> Other than that, it looks to me like you are only building the jars
>>> and the sources jars but not the bin and project artifacts we
>>> usually
>>> do. Not a problem as such (as you still have the sources for each
>>> artifact) but its somewhat different from what we do normally ...
>>
>> Is there a good reason for felix to do something other than the
>> defaults
>> from the apache 7 pom? (not that karaf is)
>
> Well, I like that i can unzip a -project.zip and am able to build the
> src inside of it. Having only the sources jars and the pom released
> might be enough to match formal requirements but I'd prefer to have
> something that builds without me assembling a project dir myself. This
> is something that we did override from the apache 7 pom defaults
> specifically because of this. Again, we can discuss whether it makes
> sense or not but until now our releases created bin and project
> artifacts.
>
I'm not sure how you can have overridden behavior new in apache 7 poms
since AFAICT the most recent felix-parent pom uses apache 5...
??
apache 7 includes a apache-release profile that automatically creates
a standard source bundle whose contents are pretty much the same as
the results of svn export. One of my main criteria for voting +1 on
release candidates lately has been checking that these source bundles
build.
thanks
david jencks
> regards,
>
> Karl
>
>> thanks
>> david jencks
>>
>>>
>>> Some artifacts are still using the osgi jars from felix (they should
>>> switch to use the official org.osgi artifacts as soon as possible).
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>
>>> On Wed, Feb 24, 2010 at 7:57 PM, Chris Custine <cc...@apache.org>
>>> wrote:
>>>>
>>>> The Karaf 1.4.0 artifacts have been staged for release.
>>>>
>>>> These release artifacts contain updated copyright year in all
>>>> NOTICE
>>>> files
>>>> and includes an updated RELEASE-NOTES file which was not updated
>>>> in the
>>>> previous release vote. As requested by Richard, I have noted
>>>> that the
>>>> vote
>>>> will be open for *at least* 72 hours in order to allow time for
>>>> proper
>>>> review.
>>>>
>>>> Release notes are here:
>>>>
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&styleName=Html&version=12314410
>>>>
>>>> Staging repository:
>>>> https://repository.apache.org/content/repositories/orgapachefelix-015/
>>>>
>>>> You can use this UNIX script to download the release and verify the
>>>> signatures:
>>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>>>
>>>> Usage:
>>>> sh check_staged_release.sh 015 /tmp/felix-staging
>>>>
>>>> Please vote to approve this release:
>>>>
>>>> [ ] +1 Approve the release
>>>> [ ] -1 Veto the release (please provide specific comments)
>>>>
>>>> This vote will be open for at least 72 hours.
>>>>
>>>>
>>>> --
>>>> Chris Custine
>>>> FUSESource :: http://fusesource.com
>>>> My Blog :: http://blog.organicelement.com
>>>> Apache ServiceMix :: http://servicemix.apache.org
>>>> Apache Felix :: http://felix.apache.org
>>>> Apache Directory Server :: http://directory.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
Re: [VOTE] Release Karaf 1.4.0
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 1, 2010 at 11:55, Karl Pauls <ka...@gmail.com> wrote:
> On Mon, Mar 1, 2010 at 11:30 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Mon, Mar 1, 2010 at 10:53, Karl Pauls <ka...@gmail.com> wrote:
>>> On Mon, Mar 1, 2010 at 2:55 AM, David Jencks <da...@yahoo.com> wrote:
>>>>
>>>> On Feb 28, 2010, at 4:03 PM, Karl Pauls wrote:
>>>>
>>>>> -1
>>>>>
>>>>> I'm really sorry but it looks to me like:
>>>>>
>>>>> org/apache/felix/karaf/deployer/features/FeatureURLHandler.java
>>>>> org/apache/felix/karaf/shell/commands/EchoAction.java
>>>>
>>>> Were these files in the first 1.4.0 release attempt? my rat scan didn't find
>>>> them.
>>>
>>> I don't know - didn't find the time to look into that one.
>>>
>>>>>
>>>>> are missing the license header and
>>>>>
>>>>> manual/pom.xml
>>>>> client/dependency-reduced-pom.xml
>>>>>
>>>>> are missing a header as well. Furthermore,
>>>>> org.apache.felix.karaf.deployer.spring and a lot of the other modules
>>>>> have dependencies on spring-core which is not mentioned in the notice
>>>>> nor in the overall src notice (its mentioned in the overall binary
>>>>> notice).
>>
>> We really need to have a rat profile that we run before the release.
>
> That would be good.
Well, actually we have one.
If you run
mvn -Prat
the report will be generated in
target/karaf-xxx.rat
>
>>>>
>>>> AFAIK the legal requirements and best practice is that LICENSE and NOTICE
>>>> files are about what is actually in the artifact they are in, not anything
>>>> that might be needed to use the artifact. So unless a karaf artifact
>>>> actually includes code copied from spring, the NOTICE files should not
>>>> mention spring. Note that the maven-remote-resources-plugin includes a
>>>> dependencies report in the jar that lists the dependencies and their
>>>> licenses. Does felix have a different policy? If so, why?
>>>
>>> We do have a different policy but we although have talks about
>>> changing it. I guess, the main reason for including stuff in the
>>> NOTICE was that historically, the maven-remote-resource-plugin didn't
>>> work very well for us (nullpointers and other problems for a long
>>> time). The important thing for me is to have a place where we give
>>> credit where credit is due - if it is not he NOTICE we can make it a
>>> different file but we probably should vote on that or something.
>>
>> We don't need to credit something we don't ship. If the user uses a
>> jar that depends on spring, he will be responsible for downloading
>> Spring, so we don't need to credit Spring Source for that afaik.
>> Anyway I think we've tried to comply to the current policy and this
>> issue is not a show stopper imho.
>
> Yeah, I don't think it's a real show stopper either. I just mention it
> as we really should get back to talk about our policy in the first
> place (but I would have been ok with the release if it would not be
> for the missing headers).
>
>>>
>>>>> Other findings (not show-stoppers) are:
>>>>>
>>>>> Signatures and checksums work for me but for some reason there are not
>>>>> only .asc but .asc.asc and .asc.md5/sha and .asc.asc.md5/sha files
>>>>> around. Very strange (probably something wrong with nexus/maven - not
>>>>> sure we can do something about it).
>>>>
>>>> AFAIK this is normal.
>>>
>>> Well, it was normal to have .asc.md5/sha files but having
>>> .asc.asc.md5/sha files? Again, not saying this is the fault of this
>>> release but man, this is getting out of hand no?
>>
>> Yeah, I'm not sure where those come from. I guess we could remove
>> those before
>> staging the repo if needed. i guess that's something to ask to the maven guys.
>
> I think so too. Its just a pain to download them all and they really
> make no sense.
>
>>>
>>>>> Other than that, it looks to me like you are only building the jars
>>>>> and the sources jars but not the bin and project artifacts we usually
>>>>> do. Not a problem as such (as you still have the sources for each
>>>>> artifact) but its somewhat different from what we do normally ...
>>>>
>>>> Is there a good reason for felix to do something other than the defaults
>>>> from the apache 7 pom? (not that karaf is)
>>>
>>> Well, I like that i can unzip a -project.zip and am able to build the
>>> src inside of it. Having only the sources jars and the pom released
>>> might be enough to match formal requirements but I'd prefer to have
>>> something that builds without me assembling a project dir myself. This
>>> is something that we did override from the apache 7 pom defaults
>>> specifically because of this. Again, we can discuss whether it makes
>>> sense or not but until now our releases created bin and project
>>> artifacts.
>>
>>
>> I don't understand. We do have source and binary releases for Karaf.
>> You need to consider the whole Karaf as *one* thing you build. We
>> don't release all the artifacts separatly, so you don't need a source
>> and binary distribution for each of those.
>> The binary and source distributions are available at:
>> https://repository.apache.org/content/repositories/orgapachefelix-015/org/apache/felix/karaf/apache-felix-karaf/1.4.0/
>> You can unzip the source distribution and build karaf if you want.
>> The individial source jars associated to each jar are only here for
>> ease of debugging when using IDE, they are not meant to be used to
>> build the artifacts.
>
> Ah ok. I was mistaken the artifacts to be bundles which we typically
> consider a separate release. If they are not bundles (or at least will
> not possible be released independently) I'm fine with not having the
> -projects files.
>
Well, most of those are OSGi bundles but not really supposed to be
released independantly for now.
> regards,
>
> Karl
>
>>> regards,
>>>
>>> Karl
>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>>
>>>>> Some artifacts are still using the osgi jars from felix (they should
>>>>> switch to use the official org.osgi artifacts as soon as possible).
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>>
>>>>> On Wed, Feb 24, 2010 at 7:57 PM, Chris Custine <cc...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> The Karaf 1.4.0 artifacts have been staged for release.
>>>>>>
>>>>>> These release artifacts contain updated copyright year in all NOTICE
>>>>>> files
>>>>>> and includes an updated RELEASE-NOTES file which was not updated in the
>>>>>> previous release vote. As requested by Richard, I have noted that the
>>>>>> vote
>>>>>> will be open for *at least* 72 hours in order to allow time for proper
>>>>>> review.
>>>>>>
>>>>>> Release notes are here:
>>>>>>
>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&styleName=Html&version=12314410
>>>>>>
>>>>>> Staging repository:
>>>>>> https://repository.apache.org/content/repositories/orgapachefelix-015/
>>>>>>
>>>>>> You can use this UNIX script to download the release and verify the
>>>>>> signatures:
>>>>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>>>>>
>>>>>> Usage:
>>>>>> sh check_staged_release.sh 015 /tmp/felix-staging
>>>>>>
>>>>>> Please vote to approve this release:
>>>>>>
>>>>>> [ ] +1 Approve the release
>>>>>> [ ] -1 Veto the release (please provide specific comments)
>>>>>>
>>>>>> This vote will be open for at least 72 hours.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Chris Custine
>>>>>> FUSESource :: http://fusesource.com
>>>>>> My Blog :: http://blog.organicelement.com
>>>>>> Apache ServiceMix :: http://servicemix.apache.org
>>>>>> Apache Felix :: http://felix.apache.org
>>>>>> Apache Directory Server :: http://directory.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [VOTE] Release Karaf 1.4.0
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Mar 1, 2010 at 11:30 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> On Mon, Mar 1, 2010 at 10:53, Karl Pauls <ka...@gmail.com> wrote:
>> On Mon, Mar 1, 2010 at 2:55 AM, David Jencks <da...@yahoo.com> wrote:
>>>
>>> On Feb 28, 2010, at 4:03 PM, Karl Pauls wrote:
>>>
>>>> -1
>>>>
>>>> I'm really sorry but it looks to me like:
>>>>
>>>> org/apache/felix/karaf/deployer/features/FeatureURLHandler.java
>>>> org/apache/felix/karaf/shell/commands/EchoAction.java
>>>
>>> Were these files in the first 1.4.0 release attempt? my rat scan didn't find
>>> them.
>>
>> I don't know - didn't find the time to look into that one.
>>
>>>>
>>>> are missing the license header and
>>>>
>>>> manual/pom.xml
>>>> client/dependency-reduced-pom.xml
>>>>
>>>> are missing a header as well. Furthermore,
>>>> org.apache.felix.karaf.deployer.spring and a lot of the other modules
>>>> have dependencies on spring-core which is not mentioned in the notice
>>>> nor in the overall src notice (its mentioned in the overall binary
>>>> notice).
>
> We really need to have a rat profile that we run before the release.
That would be good.
>>>
>>> AFAIK the legal requirements and best practice is that LICENSE and NOTICE
>>> files are about what is actually in the artifact they are in, not anything
>>> that might be needed to use the artifact. So unless a karaf artifact
>>> actually includes code copied from spring, the NOTICE files should not
>>> mention spring. Note that the maven-remote-resources-plugin includes a
>>> dependencies report in the jar that lists the dependencies and their
>>> licenses. Does felix have a different policy? If so, why?
>>
>> We do have a different policy but we although have talks about
>> changing it. I guess, the main reason for including stuff in the
>> NOTICE was that historically, the maven-remote-resource-plugin didn't
>> work very well for us (nullpointers and other problems for a long
>> time). The important thing for me is to have a place where we give
>> credit where credit is due - if it is not he NOTICE we can make it a
>> different file but we probably should vote on that or something.
>
> We don't need to credit something we don't ship. If the user uses a
> jar that depends on spring, he will be responsible for downloading
> Spring, so we don't need to credit Spring Source for that afaik.
> Anyway I think we've tried to comply to the current policy and this
> issue is not a show stopper imho.
Yeah, I don't think it's a real show stopper either. I just mention it
as we really should get back to talk about our policy in the first
place (but I would have been ok with the release if it would not be
for the missing headers).
>>
>>>> Other findings (not show-stoppers) are:
>>>>
>>>> Signatures and checksums work for me but for some reason there are not
>>>> only .asc but .asc.asc and .asc.md5/sha and .asc.asc.md5/sha files
>>>> around. Very strange (probably something wrong with nexus/maven - not
>>>> sure we can do something about it).
>>>
>>> AFAIK this is normal.
>>
>> Well, it was normal to have .asc.md5/sha files but having
>> .asc.asc.md5/sha files? Again, not saying this is the fault of this
>> release but man, this is getting out of hand no?
>
> Yeah, I'm not sure where those come from. I guess we could remove
> those before
> staging the repo if needed. i guess that's something to ask to the maven guys.
I think so too. Its just a pain to download them all and they really
make no sense.
>>
>>>> Other than that, it looks to me like you are only building the jars
>>>> and the sources jars but not the bin and project artifacts we usually
>>>> do. Not a problem as such (as you still have the sources for each
>>>> artifact) but its somewhat different from what we do normally ...
>>>
>>> Is there a good reason for felix to do something other than the defaults
>>> from the apache 7 pom? (not that karaf is)
>>
>> Well, I like that i can unzip a -project.zip and am able to build the
>> src inside of it. Having only the sources jars and the pom released
>> might be enough to match formal requirements but I'd prefer to have
>> something that builds without me assembling a project dir myself. This
>> is something that we did override from the apache 7 pom defaults
>> specifically because of this. Again, we can discuss whether it makes
>> sense or not but until now our releases created bin and project
>> artifacts.
>
>
> I don't understand. We do have source and binary releases for Karaf.
> You need to consider the whole Karaf as *one* thing you build. We
> don't release all the artifacts separatly, so you don't need a source
> and binary distribution for each of those.
> The binary and source distributions are available at:
> https://repository.apache.org/content/repositories/orgapachefelix-015/org/apache/felix/karaf/apache-felix-karaf/1.4.0/
> You can unzip the source distribution and build karaf if you want.
> The individial source jars associated to each jar are only here for
> ease of debugging when using IDE, they are not meant to be used to
> build the artifacts.
Ah ok. I was mistaken the artifacts to be bundles which we typically
consider a separate release. If they are not bundles (or at least will
not possible be released independently) I'm fine with not having the
-projects files.
regards,
Karl
>> regards,
>>
>> Karl
>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>> Some artifacts are still using the osgi jars from felix (they should
>>>> switch to use the official org.osgi artifacts as soon as possible).
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>>
>>>> On Wed, Feb 24, 2010 at 7:57 PM, Chris Custine <cc...@apache.org>
>>>> wrote:
>>>>>
>>>>> The Karaf 1.4.0 artifacts have been staged for release.
>>>>>
>>>>> These release artifacts contain updated copyright year in all NOTICE
>>>>> files
>>>>> and includes an updated RELEASE-NOTES file which was not updated in the
>>>>> previous release vote. As requested by Richard, I have noted that the
>>>>> vote
>>>>> will be open for *at least* 72 hours in order to allow time for proper
>>>>> review.
>>>>>
>>>>> Release notes are here:
>>>>>
>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&styleName=Html&version=12314410
>>>>>
>>>>> Staging repository:
>>>>> https://repository.apache.org/content/repositories/orgapachefelix-015/
>>>>>
>>>>> You can use this UNIX script to download the release and verify the
>>>>> signatures:
>>>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>>>>
>>>>> Usage:
>>>>> sh check_staged_release.sh 015 /tmp/felix-staging
>>>>>
>>>>> Please vote to approve this release:
>>>>>
>>>>> [ ] +1 Approve the release
>>>>> [ ] -1 Veto the release (please provide specific comments)
>>>>>
>>>>> This vote will be open for at least 72 hours.
>>>>>
>>>>>
>>>>> --
>>>>> Chris Custine
>>>>> FUSESource :: http://fusesource.com
>>>>> My Blog :: http://blog.organicelement.com
>>>>> Apache ServiceMix :: http://servicemix.apache.org
>>>>> Apache Felix :: http://felix.apache.org
>>>>> Apache Directory Server :: http://directory.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Karl Pauls
karlpauls@gmail.com
Re: [VOTE] Release Karaf 1.4.0
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 1, 2010 at 10:53, Karl Pauls <ka...@gmail.com> wrote:
> On Mon, Mar 1, 2010 at 2:55 AM, David Jencks <da...@yahoo.com> wrote:
>>
>> On Feb 28, 2010, at 4:03 PM, Karl Pauls wrote:
>>
>>> -1
>>>
>>> I'm really sorry but it looks to me like:
>>>
>>> org/apache/felix/karaf/deployer/features/FeatureURLHandler.java
>>> org/apache/felix/karaf/shell/commands/EchoAction.java
>>
>> Were these files in the first 1.4.0 release attempt? my rat scan didn't find
>> them.
>
> I don't know - didn't find the time to look into that one.
>
>>>
>>> are missing the license header and
>>>
>>> manual/pom.xml
>>> client/dependency-reduced-pom.xml
>>>
>>> are missing a header as well. Furthermore,
>>> org.apache.felix.karaf.deployer.spring and a lot of the other modules
>>> have dependencies on spring-core which is not mentioned in the notice
>>> nor in the overall src notice (its mentioned in the overall binary
>>> notice).
We really need to have a rat profile that we run before the release.
>>
>> AFAIK the legal requirements and best practice is that LICENSE and NOTICE
>> files are about what is actually in the artifact they are in, not anything
>> that might be needed to use the artifact. So unless a karaf artifact
>> actually includes code copied from spring, the NOTICE files should not
>> mention spring. Note that the maven-remote-resources-plugin includes a
>> dependencies report in the jar that lists the dependencies and their
>> licenses. Does felix have a different policy? If so, why?
>
> We do have a different policy but we although have talks about
> changing it. I guess, the main reason for including stuff in the
> NOTICE was that historically, the maven-remote-resource-plugin didn't
> work very well for us (nullpointers and other problems for a long
> time). The important thing for me is to have a place where we give
> credit where credit is due - if it is not he NOTICE we can make it a
> different file but we probably should vote on that or something.
We don't need to credit something we don't ship. If the user uses a
jar that depends on spring, he will be responsible for downloading
Spring, so we don't need to credit Spring Source for that afaik.
Anyway I think we've tried to comply to the current policy and this
issue is not a show stopper imho.
>
>>> Other findings (not show-stoppers) are:
>>>
>>> Signatures and checksums work for me but for some reason there are not
>>> only .asc but .asc.asc and .asc.md5/sha and .asc.asc.md5/sha files
>>> around. Very strange (probably something wrong with nexus/maven - not
>>> sure we can do something about it).
>>
>> AFAIK this is normal.
>
> Well, it was normal to have .asc.md5/sha files but having
> .asc.asc.md5/sha files? Again, not saying this is the fault of this
> release but man, this is getting out of hand no?
Yeah, I'm not sure where those come from. I guess we could remove
those before
staging the repo if needed. i guess that's something to ask to the maven guys.
>
>>> Other than that, it looks to me like you are only building the jars
>>> and the sources jars but not the bin and project artifacts we usually
>>> do. Not a problem as such (as you still have the sources for each
>>> artifact) but its somewhat different from what we do normally ...
>>
>> Is there a good reason for felix to do something other than the defaults
>> from the apache 7 pom? (not that karaf is)
>
> Well, I like that i can unzip a -project.zip and am able to build the
> src inside of it. Having only the sources jars and the pom released
> might be enough to match formal requirements but I'd prefer to have
> something that builds without me assembling a project dir myself. This
> is something that we did override from the apache 7 pom defaults
> specifically because of this. Again, we can discuss whether it makes
> sense or not but until now our releases created bin and project
> artifacts.
I don't understand. We do have source and binary releases for Karaf.
You need to consider the whole Karaf as *one* thing you build. We
don't release all the artifacts separatly, so you don't need a source
and binary distribution for each of those.
The binary and source distributions are available at:
https://repository.apache.org/content/repositories/orgapachefelix-015/org/apache/felix/karaf/apache-felix-karaf/1.4.0/
You can unzip the source distribution and build karaf if you want.
The individial source jars associated to each jar are only here for
ease of debugging when using IDE, they are not meant to be used to
build the artifacts.
> regards,
>
> Karl
>
>> thanks
>> david jencks
>>
>>>
>>> Some artifacts are still using the osgi jars from felix (they should
>>> switch to use the official org.osgi artifacts as soon as possible).
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>
>>> On Wed, Feb 24, 2010 at 7:57 PM, Chris Custine <cc...@apache.org>
>>> wrote:
>>>>
>>>> The Karaf 1.4.0 artifacts have been staged for release.
>>>>
>>>> These release artifacts contain updated copyright year in all NOTICE
>>>> files
>>>> and includes an updated RELEASE-NOTES file which was not updated in the
>>>> previous release vote. As requested by Richard, I have noted that the
>>>> vote
>>>> will be open for *at least* 72 hours in order to allow time for proper
>>>> review.
>>>>
>>>> Release notes are here:
>>>>
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&styleName=Html&version=12314410
>>>>
>>>> Staging repository:
>>>> https://repository.apache.org/content/repositories/orgapachefelix-015/
>>>>
>>>> You can use this UNIX script to download the release and verify the
>>>> signatures:
>>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>>>
>>>> Usage:
>>>> sh check_staged_release.sh 015 /tmp/felix-staging
>>>>
>>>> Please vote to approve this release:
>>>>
>>>> [ ] +1 Approve the release
>>>> [ ] -1 Veto the release (please provide specific comments)
>>>>
>>>> This vote will be open for at least 72 hours.
>>>>
>>>>
>>>> --
>>>> Chris Custine
>>>> FUSESource :: http://fusesource.com
>>>> My Blog :: http://blog.organicelement.com
>>>> Apache ServiceMix :: http://servicemix.apache.org
>>>> Apache Felix :: http://felix.apache.org
>>>> Apache Directory Server :: http://directory.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [VOTE] Release Karaf 1.4.0
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Mar 1, 2010 at 2:55 AM, David Jencks <da...@yahoo.com> wrote:
>
> On Feb 28, 2010, at 4:03 PM, Karl Pauls wrote:
>
>> -1
>>
>> I'm really sorry but it looks to me like:
>>
>> org/apache/felix/karaf/deployer/features/FeatureURLHandler.java
>> org/apache/felix/karaf/shell/commands/EchoAction.java
>
> Were these files in the first 1.4.0 release attempt? my rat scan didn't find
> them.
I don't know - didn't find the time to look into that one.
>>
>> are missing the license header and
>>
>> manual/pom.xml
>> client/dependency-reduced-pom.xml
>>
>> are missing a header as well. Furthermore,
>> org.apache.felix.karaf.deployer.spring and a lot of the other modules
>> have dependencies on spring-core which is not mentioned in the notice
>> nor in the overall src notice (its mentioned in the overall binary
>> notice).
>
> AFAIK the legal requirements and best practice is that LICENSE and NOTICE
> files are about what is actually in the artifact they are in, not anything
> that might be needed to use the artifact. So unless a karaf artifact
> actually includes code copied from spring, the NOTICE files should not
> mention spring. Note that the maven-remote-resources-plugin includes a
> dependencies report in the jar that lists the dependencies and their
> licenses. Does felix have a different policy? If so, why?
We do have a different policy but we although have talks about
changing it. I guess, the main reason for including stuff in the
NOTICE was that historically, the maven-remote-resource-plugin didn't
work very well for us (nullpointers and other problems for a long
time). The important thing for me is to have a place where we give
credit where credit is due - if it is not he NOTICE we can make it a
different file but we probably should vote on that or something.
>> Other findings (not show-stoppers) are:
>>
>> Signatures and checksums work for me but for some reason there are not
>> only .asc but .asc.asc and .asc.md5/sha and .asc.asc.md5/sha files
>> around. Very strange (probably something wrong with nexus/maven - not
>> sure we can do something about it).
>
> AFAIK this is normal.
Well, it was normal to have .asc.md5/sha files but having
.asc.asc.md5/sha files? Again, not saying this is the fault of this
release but man, this is getting out of hand no?
>> Other than that, it looks to me like you are only building the jars
>> and the sources jars but not the bin and project artifacts we usually
>> do. Not a problem as such (as you still have the sources for each
>> artifact) but its somewhat different from what we do normally ...
>
> Is there a good reason for felix to do something other than the defaults
> from the apache 7 pom? (not that karaf is)
Well, I like that i can unzip a -project.zip and am able to build the
src inside of it. Having only the sources jars and the pom released
might be enough to match formal requirements but I'd prefer to have
something that builds without me assembling a project dir myself. This
is something that we did override from the apache 7 pom defaults
specifically because of this. Again, we can discuss whether it makes
sense or not but until now our releases created bin and project
artifacts.
regards,
Karl
> thanks
> david jencks
>
>>
>> Some artifacts are still using the osgi jars from felix (they should
>> switch to use the official org.osgi artifacts as soon as possible).
>>
>> regards,
>>
>> Karl
>>
>>
>> On Wed, Feb 24, 2010 at 7:57 PM, Chris Custine <cc...@apache.org>
>> wrote:
>>>
>>> The Karaf 1.4.0 artifacts have been staged for release.
>>>
>>> These release artifacts contain updated copyright year in all NOTICE
>>> files
>>> and includes an updated RELEASE-NOTES file which was not updated in the
>>> previous release vote. As requested by Richard, I have noted that the
>>> vote
>>> will be open for *at least* 72 hours in order to allow time for proper
>>> review.
>>>
>>> Release notes are here:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&styleName=Html&version=12314410
>>>
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapachefelix-015/
>>>
>>> You can use this UNIX script to download the release and verify the
>>> signatures:
>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>>
>>> Usage:
>>> sh check_staged_release.sh 015 /tmp/felix-staging
>>>
>>> Please vote to approve this release:
>>>
>>> [ ] +1 Approve the release
>>> [ ] -1 Veto the release (please provide specific comments)
>>>
>>> This vote will be open for at least 72 hours.
>>>
>>>
>>> --
>>> Chris Custine
>>> FUSESource :: http://fusesource.com
>>> My Blog :: http://blog.organicelement.com
>>> Apache ServiceMix :: http://servicemix.apache.org
>>> Apache Felix :: http://felix.apache.org
>>> Apache Directory Server :: http://directory.apache.org
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>
>
--
Karl Pauls
karlpauls@gmail.com
Re: [VOTE] Release Karaf 1.4.0
Posted by David Jencks <da...@yahoo.com>.
On Feb 28, 2010, at 4:03 PM, Karl Pauls wrote:
> -1
>
> I'm really sorry but it looks to me like:
>
> org/apache/felix/karaf/deployer/features/FeatureURLHandler.java
> org/apache/felix/karaf/shell/commands/EchoAction.java
Were these files in the first 1.4.0 release attempt? my rat scan
didn't find them.
>
> are missing the license header and
>
> manual/pom.xml
> client/dependency-reduced-pom.xml
>
> are missing a header as well. Furthermore,
> org.apache.felix.karaf.deployer.spring and a lot of the other modules
> have dependencies on spring-core which is not mentioned in the notice
> nor in the overall src notice (its mentioned in the overall binary
> notice).
AFAIK the legal requirements and best practice is that LICENSE and
NOTICE files are about what is actually in the artifact they are in,
not anything that might be needed to use the artifact. So unless a
karaf artifact actually includes code copied from spring, the NOTICE
files should not mention spring. Note that the maven-remote-resources-
plugin includes a dependencies report in the jar that lists the
dependencies and their licenses. Does felix have a different policy?
If so, why?
>
> Other findings (not show-stoppers) are:
>
> Signatures and checksums work for me but for some reason there are not
> only .asc but .asc.asc and .asc.md5/sha and .asc.asc.md5/sha files
> around. Very strange (probably something wrong with nexus/maven - not
> sure we can do something about it).
AFAIK this is normal.
>
> Other than that, it looks to me like you are only building the jars
> and the sources jars but not the bin and project artifacts we usually
> do. Not a problem as such (as you still have the sources for each
> artifact) but its somewhat different from what we do normally ...
Is there a good reason for felix to do something other than the
defaults from the apache 7 pom? (not that karaf is)
thanks
david jencks
>
> Some artifacts are still using the osgi jars from felix (they should
> switch to use the official org.osgi artifacts as soon as possible).
>
> regards,
>
> Karl
>
>
> On Wed, Feb 24, 2010 at 7:57 PM, Chris Custine <cc...@apache.org>
> wrote:
>> The Karaf 1.4.0 artifacts have been staged for release.
>>
>> These release artifacts contain updated copyright year in all
>> NOTICE files
>> and includes an updated RELEASE-NOTES file which was not updated in
>> the
>> previous release vote. As requested by Richard, I have noted that
>> the vote
>> will be open for *at least* 72 hours in order to allow time for
>> proper
>> review.
>>
>> Release notes are here:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&styleName=Html&version=12314410
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/
>> orgapachefelix-015/
>>
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh 015 /tmp/felix-staging
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>>
>> This vote will be open for at least 72 hours.
>>
>>
>> --
>> Chris Custine
>> FUSESource :: http://fusesource.com
>> My Blog :: http://blog.organicelement.com
>> Apache ServiceMix :: http://servicemix.apache.org
>> Apache Felix :: http://felix.apache.org
>> Apache Directory Server :: http://directory.apache.org
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
Re: [VOTE] Release Karaf 1.4.0
Posted by Chris Custine <ch...@gmail.com>.
On Sun, Feb 28, 2010 at 5:03 PM, Karl Pauls <ka...@gmail.com> wrote:
> -1
>
> I'm really sorry but it looks to me like:
>
No reason to be sorry! Thats what this process is for!
> org/apache/felix/karaf/deployer/features/FeatureURLHandler.java
> org/apache/felix/karaf/shell/commands/EchoAction.java
>
I figured out that the rat profile we have in our builds uses a fairly old
codehaus version of rat, and for whatever reason the new Apache incubator
version makes these missing headers more obvious. I, like David, had run
rat multiple times in the last week and not seen some of these hits (both of
which have been in multiple previous releases just the way they are).
>
> are missing the license header and
>
> manual/pom.xml
> client/dependency-reduced-pom.xml
>
dependency-reduced-pom.xml is a generated file so it should not have been in
the distribution, but this may be related to the .asc.asc files. I can't
remember, but its possible that I had to start the release build several
times to fix issues and things didn't get properly cleaned in between.
I've fixed the rat issue so that the missing headers show up more
prominently and fixed the missing headers that we know about so I will
cancel this release and start another after I review things a bit more.
I think Guillaume and David have a good discussion going about the rest of
these issues you bring up.
>
> are missing a header as well. Furthermore,
> org.apache.felix.karaf.deployer.spring and a lot of the other modules
> have dependencies on spring-core which is not mentioned in the notice
> nor in the overall src notice (its mentioned in the overall binary
> notice).
>
> Other findings (not show-stoppers) are:
>
> Signatures and checksums work for me but for some reason there are not
> only .asc but .asc.asc and .asc.md5/sha and .asc.asc.md5/sha files
> around. Very strange (probably something wrong with nexus/maven - not
> sure we can do something about it).
>
> Other than that, it looks to me like you are only building the jars
> and the sources jars but not the bin and project artifacts we usually
> do. Not a problem as such (as you still have the sources for each
> artifact) but its somewhat different from what we do normally ...
>
> Some artifacts are still using the osgi jars from felix (they should
> switch to use the official org.osgi artifacts as soon as possible).
>
> regards,
>
> Karl
>
>
> On Wed, Feb 24, 2010 at 7:57 PM, Chris Custine <cc...@apache.org>
> wrote:
> > The Karaf 1.4.0 artifacts have been staged for release.
> >
> > These release artifacts contain updated copyright year in all NOTICE
> files
> > and includes an updated RELEASE-NOTES file which was not updated in the
> > previous release vote. As requested by Richard, I have noted that the
> vote
> > will be open for *at least* 72 hours in order to allow time for proper
> > review.
> >
> > Release notes are here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&styleName=Html&version=12314410
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachefelix-015/
> >
> > You can use this UNIX script to download the release and verify the
> > signatures:
> > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
> >
> > Usage:
> > sh check_staged_release.sh 015 /tmp/felix-staging
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Veto the release (please provide specific comments)
> >
> > This vote will be open for at least 72 hours.
> >
> >
> > --
> > Chris Custine
> > FUSESource :: http://fusesource.com
> > My Blog :: http://blog.organicelement.com
> > Apache ServiceMix :: http://servicemix.apache.org
> > Apache Felix :: http://felix.apache.org
> > Apache Directory Server :: http://directory.apache.org
> >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>