On Mon, Mar 1, 2010 at 11:55, Karl Pauls <karlpa...@gmail.com> wrote:
> On Mon, Mar 1, 2010 at 11:30 AM, Guillaume Nodet <gno...@gmail.com> wrote:
>> On Mon, Mar 1, 2010 at 10:53, Karl Pauls <karlpa...@gmail.com> wrote:
>>> On Mon, Mar 1, 2010 at 2:55 AM, David Jencks <david_jen...@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 <ccust...@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
>>>>> karlpa...@gmail.com
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpa...@gmail.com
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
