You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2010/06/09 19:55:41 UTC
NOTICE/DEPENDENCIES files for Felix subproject releases
With the latest release of the framework and Gogo modules, we've tried
to update the release process for how we handle the NOTICE file. Our
past usage is apparently not aligned with the intended usage, where the
NOTICE file should only contained notices for included third-party
software whose license requires notice. Our new approach (for now) is this:
1. Include a NOTICE file which contains only required notices.
2. Include a DEPENDENCIES file which contains our acknowledgments
about the software the subproject uses.
For the most part, this isn't a major hassle and largely boils down to this:
1. Rename the current NOTICE file to DEPENDENCIES.
2. Create a new NOTICE file that contains notices only for the "used"
software requiring notices in the DEPENDENCIES file.
Although the new DEPENDENCIES file is very similar to the old NOTICE
file, the template is slightly different as indicated here:
https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
Of course, in the long term we can try to move to automating the
generation of the NOTICE and/or DEPENDENCIES files, which would make our
lives simpler. If any subprojects currently are able to automate this
information, as long as the generated files contain information
consistent with what is proposed here, then the exact formatting is not
that important. But for hand generated files, follow this template.
If you want to see examples, look in the framework or gogo subprojects.
-> richard
p.s. This is obviously all open for discussion to the specifics, but
until then we should use this approach for releases in an effort to
better align with Apache process (with perhaps the exception of Karaf
since if/when it goes TLP then its PMC will decide how to do releases).
Re: Fwd: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by Karl Pauls <ka...@gmail.com>.
On Thu, Jun 10, 2010 at 4:52 AM, Justin Edelson
<ju...@justinedelson.com> wrote:
> On Wed, Jun 9, 2010 at 2:55 PM, Felix Meschberger <fm...@gmail.com>wrote:
>
>> Hi,
>>
>> On 09.06.2010 20:05, Justin Edelson wrote:
>> > Should we follow Felix's lead here?
>>
>> I don't think so.
>>
>> In Sling we are using the remote resources plugin which manages this all
>> an an ASF compliant way for us. Exceptions (where LICENSE data is not
>> available from the Maven repository) can still be entered manually.
>>
>> As a consequence we already have the correct NOTICE, LICENSE, and
>> DEPENDENCIES files.
>>
> Richard seems to suggest that this automated method isn't good enough. But
> if you think it is, then I'm fine with it.
Iirc, we have some cases in Felix where it is not picking things up
due to the complicated way the artifacts are assembled. AFAIK, we
don't have such cases in sling so we should be fine.
regards,
Karl
> Justin
>
>
>>
>> Regards
>> Felix
>>
>> >
>> > ---------- Forwarded message ----------
>> > From: Richard S. Hall <he...@ungoverned.org>
>> > Date: Wed, Jun 9, 2010 at 1:55 PM
>> > Subject: NOTICE/DEPENDENCIES files for Felix subproject releases
>> > To: dev <de...@felix.apache.org>
>> >
>> >
>> > With the latest release of the framework and Gogo modules, we've tried to
>> > update the release process for how we handle the NOTICE file. Our past
>> usage
>> > is apparently not aligned with the intended usage, where the NOTICE file
>> > should only contained notices for included third-party software whose
>> > license requires notice. Our new approach (for now) is this:
>> >
>> > 1. Include a NOTICE file which contains only required notices.
>> > 2. Include a DEPENDENCIES file which contains our acknowledgments
>> > about the software the subproject uses.
>> >
>> > For the most part, this isn't a major hassle and largely boils down to
>> this:
>> >
>> > 1. Rename the current NOTICE file to DEPENDENCIES.
>> > 2. Create a new NOTICE file that contains notices only for the "used"
>> > software requiring notices in the DEPENDENCIES file.
>> >
>> > Although the new DEPENDENCIES file is very similar to the old NOTICE
>> file,
>> > the template is slightly different as indicated here:
>> >
>> >
>> >
>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>> >
>> > Of course, in the long term we can try to move to automating the
>> generation
>> > of the NOTICE and/or DEPENDENCIES files, which would make our lives
>> simpler.
>> > If any subprojects currently are able to automate this information, as
>> long
>> > as the generated files contain information consistent with what is
>> proposed
>> > here, then the exact formatting is not that important. But for hand
>> > generated files, follow this template.
>> >
>> > If you want to see examples, look in the framework or gogo subprojects.
>> >
>> > -> richard
>> >
>> > p.s. This is obviously all open for discussion to the specifics, but
>> until
>> > then we should use this approach for releases in an effort to better
>> align
>> > with Apache process (with perhaps the exception of Karaf since if/when it
>> > goes TLP then its PMC will decide how to do releases).
>> >
>>
>
--
Karl Pauls
karlpauls@gmail.com
Re: Fwd: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by Justin Edelson <ju...@justinedelson.com>.
On Wed, Jun 9, 2010 at 2:55 PM, Felix Meschberger <fm...@gmail.com>wrote:
> Hi,
>
> On 09.06.2010 20:05, Justin Edelson wrote:
> > Should we follow Felix's lead here?
>
> I don't think so.
>
> In Sling we are using the remote resources plugin which manages this all
> an an ASF compliant way for us. Exceptions (where LICENSE data is not
> available from the Maven repository) can still be entered manually.
>
> As a consequence we already have the correct NOTICE, LICENSE, and
> DEPENDENCIES files.
>
Richard seems to suggest that this automated method isn't good enough. But
if you think it is, then I'm fine with it.
Justin
>
> Regards
> Felix
>
> >
> > ---------- Forwarded message ----------
> > From: Richard S. Hall <he...@ungoverned.org>
> > Date: Wed, Jun 9, 2010 at 1:55 PM
> > Subject: NOTICE/DEPENDENCIES files for Felix subproject releases
> > To: dev <de...@felix.apache.org>
> >
> >
> > With the latest release of the framework and Gogo modules, we've tried to
> > update the release process for how we handle the NOTICE file. Our past
> usage
> > is apparently not aligned with the intended usage, where the NOTICE file
> > should only contained notices for included third-party software whose
> > license requires notice. Our new approach (for now) is this:
> >
> > 1. Include a NOTICE file which contains only required notices.
> > 2. Include a DEPENDENCIES file which contains our acknowledgments
> > about the software the subproject uses.
> >
> > For the most part, this isn't a major hassle and largely boils down to
> this:
> >
> > 1. Rename the current NOTICE file to DEPENDENCIES.
> > 2. Create a new NOTICE file that contains notices only for the "used"
> > software requiring notices in the DEPENDENCIES file.
> >
> > Although the new DEPENDENCIES file is very similar to the old NOTICE
> file,
> > the template is slightly different as indicated here:
> >
> >
> >
> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
> >
> > Of course, in the long term we can try to move to automating the
> generation
> > of the NOTICE and/or DEPENDENCIES files, which would make our lives
> simpler.
> > If any subprojects currently are able to automate this information, as
> long
> > as the generated files contain information consistent with what is
> proposed
> > here, then the exact formatting is not that important. But for hand
> > generated files, follow this template.
> >
> > If you want to see examples, look in the framework or gogo subprojects.
> >
> > -> richard
> >
> > p.s. This is obviously all open for discussion to the specifics, but
> until
> > then we should use this approach for releases in an effort to better
> align
> > with Apache process (with perhaps the exception of Karaf since if/when it
> > goes TLP then its PMC will decide how to do releases).
> >
>
Re: Fwd: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 09.06.2010 20:05, Justin Edelson wrote:
> Should we follow Felix's lead here?
I don't think so.
In Sling we are using the remote resources plugin which manages this all
an an ASF compliant way for us. Exceptions (where LICENSE data is not
available from the Maven repository) can still be entered manually.
As a consequence we already have the correct NOTICE, LICENSE, and
DEPENDENCIES files.
Regards
Felix
>
> ---------- Forwarded message ----------
> From: Richard S. Hall <he...@ungoverned.org>
> Date: Wed, Jun 9, 2010 at 1:55 PM
> Subject: NOTICE/DEPENDENCIES files for Felix subproject releases
> To: dev <de...@felix.apache.org>
>
>
> With the latest release of the framework and Gogo modules, we've tried to
> update the release process for how we handle the NOTICE file. Our past usage
> is apparently not aligned with the intended usage, where the NOTICE file
> should only contained notices for included third-party software whose
> license requires notice. Our new approach (for now) is this:
>
> 1. Include a NOTICE file which contains only required notices.
> 2. Include a DEPENDENCIES file which contains our acknowledgments
> about the software the subproject uses.
>
> For the most part, this isn't a major hassle and largely boils down to this:
>
> 1. Rename the current NOTICE file to DEPENDENCIES.
> 2. Create a new NOTICE file that contains notices only for the "used"
> software requiring notices in the DEPENDENCIES file.
>
> Although the new DEPENDENCIES file is very similar to the old NOTICE file,
> the template is slightly different as indicated here:
>
>
> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>
> Of course, in the long term we can try to move to automating the generation
> of the NOTICE and/or DEPENDENCIES files, which would make our lives simpler.
> If any subprojects currently are able to automate this information, as long
> as the generated files contain information consistent with what is proposed
> here, then the exact formatting is not that important. But for hand
> generated files, follow this template.
>
> If you want to see examples, look in the framework or gogo subprojects.
>
> -> richard
>
> p.s. This is obviously all open for discussion to the specifics, but until
> then we should use this approach for releases in an effort to better align
> with Apache process (with perhaps the exception of Karaf since if/when it
> goes TLP then its PMC will decide how to do releases).
>
Fwd: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by Justin Edelson <ju...@justinedelson.com>.
Should we follow Felix's lead here?
---------- Forwarded message ----------
From: Richard S. Hall <he...@ungoverned.org>
Date: Wed, Jun 9, 2010 at 1:55 PM
Subject: NOTICE/DEPENDENCIES files for Felix subproject releases
To: dev <de...@felix.apache.org>
With the latest release of the framework and Gogo modules, we've tried to
update the release process for how we handle the NOTICE file. Our past usage
is apparently not aligned with the intended usage, where the NOTICE file
should only contained notices for included third-party software whose
license requires notice. Our new approach (for now) is this:
1. Include a NOTICE file which contains only required notices.
2. Include a DEPENDENCIES file which contains our acknowledgments
about the software the subproject uses.
For the most part, this isn't a major hassle and largely boils down to this:
1. Rename the current NOTICE file to DEPENDENCIES.
2. Create a new NOTICE file that contains notices only for the "used"
software requiring notices in the DEPENDENCIES file.
Although the new DEPENDENCIES file is very similar to the old NOTICE file,
the template is slightly different as indicated here:
https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
Of course, in the long term we can try to move to automating the generation
of the NOTICE and/or DEPENDENCIES files, which would make our lives simpler.
If any subprojects currently are able to automate this information, as long
as the generated files contain information consistent with what is proposed
here, then the exact formatting is not that important. But for hand
generated files, follow this template.
If you want to see examples, look in the framework or gogo subprojects.
-> richard
p.s. This is obviously all open for discussion to the specifics, but until
then we should use this approach for releases in an effort to better align
with Apache process (with perhaps the exception of Karaf since if/when it
goes TLP then its PMC will decide how to do releases).
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/10/10 10:45, Guillaume Nodet wrote:
> On the DEPENDENCIES, i guess we should first discuss what we want this file
> to be used for exactly. "acknowledgments about the software the subproject
> uses" is a bit vague. Is that at runtime ? compile time ? build-time
> (including maven, plugins and all...) ? I do think maven is in a good
> position to actually know all the things we need.
>
Yes, I'm all for automating it and we need to define it more precisely.
The new process in place right now is in effect until we can refine it,
because if we don't just do something then often nothing gets done.
We've had the discussion about automating this before, but didn't really
get very far. :-(
> As for the formatting of the NOTICE file, I don't really get why we wouldn't
> leverage the work that has been done by other people in trying to integrate
> those legal requirements in maven. Just want to mention that every other
> project using maven I know about use the maven-remote-resources-plugin.
> It's even in the root apache pom iirc.
>
Again, see above.
> Anyway, looking at the gogo/runtime as an example, I see the following
> NOTICE
> =======
> Apache Felix Gogo Runtime
> Copyright 2010 The Apache Software Foundation
>
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
> Licensed under the Apache License 2.0.
>
> This product includes software developed at
> The OSGi Alliance (http://www.osgi.org/).
> Copyright (c) OSGi Alliance (2000, 2009).
> Licensed under the Apache License 2.0.
> =======
> Not sure why we say it *includes* software developped at the OSGi Alliance.
> In that case, nothing comes from the Alliance.
>
Not really true. As we know, the original packages contributed by Peter
Kriens were org.osgi.service.command, but in an effort to foster our
experimentation and to avoid legal issues, we changed the package name
to org.apache.felix.service.command. Since the original code was
attributed to the OSGi Alliance, I kept that attribution in the NOTICE
file since all I did was rename the package, not replace the code.
Technically, it is not clear if this is necessary or if the original
code was really from the OSGi Alliance or from Peter Kriens personally,
but I did it this way to be safe for now.
> All the classes in the final jar comes from this module, hence from the ASF.
> I think the case where we include software is rare: it's the case when we
> ship an api package, that's mostly it.
>
> I would suggest investigating the use of the maven-remote-resources-plugin
> and keep the DEPENDENCIES file generated by maven.
> I'll try to provide a patch on gogo as an example so that we can discuss
> things further.
>
Feel free. If we can get something completely automated, I'd be happy,
although I'm still not convinced it will work for every subproject,
e.g., in framework we actually embed the source code of the OSGi API...
-> richard
>
> On Thu, Jun 10, 2010 at 15:52, Richard S. Hall<he...@ungoverned.org> wrote:
>
>
>> On 6/10/10 9:47, Guillaume Nodet wrote:
>>
>>
>>> I think we should keep the amount of legal files to the bare minimum, i.e.
>>> make sure the LICENSE and NOTICE files are correct wrt the ASF ways of
>>> doing
>>> things. Anything else is not mandatory and imho, should be removed,
>>> unless
>>> generated, to avoid the extra work of maintaining those files for no real
>>> added value.
>>>
>>>
>>>
>> Not sure to what you are referring, this is exactly what is being done now.
>> The DEPENDENCIES file is not a legal file, so that is a non-issue. If you
>> are saying you are against acknowledging the software we depend on, then we
>> can have that discussion, but it has nothing to do with the legal files.
>>
>> -> richard
>>
>>
>> On Thu, Jun 10, 2010 at 15:41, Richard S. Hall<he...@ungoverned.org>
>>
>>> wrote:
>>>
>>>
>>>
>>>
>>>> On 6/10/10 9:03, Justin Edelson wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> On 6/10/10 8:54 AM, Richard S. Hall wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 6/9/10 17:11, Justin Edelson wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hmmm. When I looked at the framework DEPENDENCIES file, there was a
>>>>>>> reference to codehaus, but I didn't think the framework depends upon
>>>>>>> codehaus libraries, just some Maven plugin.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I think it was the RAT plugin, but this has since moved to Apache,
>>>>>> right?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> My (albeit very vague) understanding is that it is in the process of
>>>>> being moved. In any case, the framework pom still references the
>>>>> codehaus version.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Yeah, that should probably be upgraded at some point.
>>>>
>>>>
>>>> I think it very classy to acknowledge plugins like this. It just isn't
>>>>
>>>>
>>>>
>>>>> clear to me that, based on your original email, that was your intent.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> As I said, we'll have to clear that up...when I find the time, I'll edit
>>>> the wiki page...
>>>>
>>>> -> richard
>>>>
>>>>
>>>> Justin
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Justin
>>>>>>>
>>>>>>> On Jun 9, 2010, at 4:49 PM, David Jencks<da...@yahoo.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> The DEPENDENCIES file is completely optional as far as apache policy
>>>>>>>> is concerned. I wrote the maven code that generates these with the
>>>>>>>> intention of giving users hints about the other software that would
>>>>>>>> likely be needed to actually use the artifact containing the
>>>>>>>> DEPENDENCIES file. As such, it only includes (appropriately scoped)
>>>>>>>> dependencies, not all the maven stuff that may have been used to
>>>>>>>> generate the artifact.
>>>>>>>>
>>>>>>>> Since felix is an osgi based project that uses osgi to hook up
>>>>>>>> bundles, and avoids require-bundle like the plague, and there's no
>>>>>>>> good reason to suppose that the maven dependencies will be the actual
>>>>>>>> providers of the required imports, a strong case could be made that
>>>>>>>> felix should simply not include DEPENDENCIES files.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Jun 9, 2010, at 12:30 PM, Richard S. Hall wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 6/9/10 14:52, Justin Edelson wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Richard-
>>>>>>>>>> Perhaps this is supposed to be obvious, but I think it would be
>>>>>>>>>> helpful to
>>>>>>>>>> define the term "uses" with respect to the DEPENDENCIES file. IIUC,
>>>>>>>>>> it
>>>>>>>>>> includes dependencies (in any scope) as well as software executed
>>>>>>>>>> as part of
>>>>>>>>>> the build (i.e. Maven Plugins), but the inclusion of the latter may
>>>>>>>>>> not be
>>>>>>>>>> intuitive.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> True. We need to be clearer...
>>>>>>>>>
>>>>>>>>> -> richard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Justin
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 9, 2010 at 1:55 PM, Richard S.
>>>>>>>>>> Hall<he...@ungoverned.org>wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> With the latest release of the framework and Gogo modules, we've
>>>>>>>>>>> tried to
>>>>>>>>>>> update the release process for how we handle the NOTICE file. Our
>>>>>>>>>>> past usage
>>>>>>>>>>> is apparently not aligned with the intended usage, where the
>>>>>>>>>>> NOTICE file
>>>>>>>>>>> should only contained notices for included third-party software
>>>>>>>>>>> whose
>>>>>>>>>>> license requires notice. Our new approach (for now) is this:
>>>>>>>>>>>
>>>>>>>>>>> 1. Include a NOTICE file which contains only required notices.
>>>>>>>>>>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>>>>>>>>>>> about the software the subproject uses.
>>>>>>>>>>>
>>>>>>>>>>> For the most part, this isn't a major hassle and largely boils
>>>>>>>>>>> down to
>>>>>>>>>>> this:
>>>>>>>>>>>
>>>>>>>>>>> 1. Rename the current NOTICE file to DEPENDENCIES.
>>>>>>>>>>> 2. Create a new NOTICE file that contains notices only for the
>>>>>>>>>>> "used"
>>>>>>>>>>> software requiring notices in the DEPENDENCIES file.
>>>>>>>>>>>
>>>>>>>>>>> Although the new DEPENDENCIES file is very similar to the old
>>>>>>>>>>> NOTICE file,
>>>>>>>>>>> the template is slightly different as indicated here:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Of course, in the long term we can try to move to automating the
>>>>>>>>>>> generation
>>>>>>>>>>> of the NOTICE and/or DEPENDENCIES files, which would make our
>>>>>>>>>>> lives simpler.
>>>>>>>>>>> If any subprojects currently are able to automate this
>>>>>>>>>>> information, as long
>>>>>>>>>>> as the generated files contain information consistent with what is
>>>>>>>>>>> proposed
>>>>>>>>>>> here, then the exact formatting is not that important. But for
>>>>>>>>>>> hand
>>>>>>>>>>> generated files, follow this template.
>>>>>>>>>>>
>>>>>>>>>>> If you want to see examples, look in the framework or gogo
>>>>>>>>>>> subprojects.
>>>>>>>>>>>
>>>>>>>>>>> -> richard
>>>>>>>>>>>
>>>>>>>>>>> p.s. This is obviously all open for discussion to the specifics,
>>>>>>>>>>> but until
>>>>>>>>>>> then we should use this approach for releases in an effort to
>>>>>>>>>>> better align
>>>>>>>>>>> with Apache process (with perhaps the exception of Karaf since
>>>>>>>>>>> if/when it
>>>>>>>>>>> goes TLP then its PMC will decide how to do releases).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by Guillaume Nodet <gn...@gmail.com>.
On the DEPENDENCIES, i guess we should first discuss what we want this file
to be used for exactly. "acknowledgments about the software the subproject
uses" is a bit vague. Is that at runtime ? compile time ? build-time
(including maven, plugins and all...) ? I do think maven is in a good
position to actually know all the things we need.
As for the formatting of the NOTICE file, I don't really get why we wouldn't
leverage the work that has been done by other people in trying to integrate
those legal requirements in maven. Just want to mention that every other
project using maven I know about use the maven-remote-resources-plugin.
It's even in the root apache pom iirc.
Anyway, looking at the gogo/runtime as an example, I see the following
NOTICE
=======
Apache Felix Gogo Runtime
Copyright 2010 The Apache Software Foundation
This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
Licensed under the Apache License 2.0.
This product includes software developed at
The OSGi Alliance (http://www.osgi.org/).
Copyright (c) OSGi Alliance (2000, 2009).
Licensed under the Apache License 2.0.
=======
Not sure why we say it *includes* software developped at the OSGi Alliance.
In that case, nothing comes from the Alliance.
All the classes in the final jar comes from this module, hence from the ASF.
I think the case where we include software is rare: it's the case when we
ship an api package, that's mostly it.
I would suggest investigating the use of the maven-remote-resources-plugin
and keep the DEPENDENCIES file generated by maven.
I'll try to provide a patch on gogo as an example so that we can discuss
things further.
On Thu, Jun 10, 2010 at 15:52, Richard S. Hall <he...@ungoverned.org> wrote:
> On 6/10/10 9:47, Guillaume Nodet wrote:
>
>> I think we should keep the amount of legal files to the bare minimum, i.e.
>> make sure the LICENSE and NOTICE files are correct wrt the ASF ways of
>> doing
>> things. Anything else is not mandatory and imho, should be removed,
>> unless
>> generated, to avoid the extra work of maintaining those files for no real
>> added value.
>>
>>
>
> Not sure to what you are referring, this is exactly what is being done now.
> The DEPENDENCIES file is not a legal file, so that is a non-issue. If you
> are saying you are against acknowledging the software we depend on, then we
> can have that discussion, but it has nothing to do with the legal files.
>
> -> richard
>
>
> On Thu, Jun 10, 2010 at 15:41, Richard S. Hall<he...@ungoverned.org>
>> wrote:
>>
>>
>>
>>> On 6/10/10 9:03, Justin Edelson wrote:
>>>
>>>
>>>
>>>> On 6/10/10 8:54 AM, Richard S. Hall wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> On 6/9/10 17:11, Justin Edelson wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hmmm. When I looked at the framework DEPENDENCIES file, there was a
>>>>>> reference to codehaus, but I didn't think the framework depends upon
>>>>>> codehaus libraries, just some Maven plugin.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> I think it was the RAT plugin, but this has since moved to Apache,
>>>>> right?
>>>>>
>>>>>
>>>>>
>>>>>
>>>> My (albeit very vague) understanding is that it is in the process of
>>>> being moved. In any case, the framework pom still references the
>>>> codehaus version.
>>>>
>>>>
>>>>
>>>>
>>> Yeah, that should probably be upgraded at some point.
>>>
>>>
>>> I think it very classy to acknowledge plugins like this. It just isn't
>>>
>>>
>>>> clear to me that, based on your original email, that was your intent.
>>>>
>>>>
>>>>
>>>>
>>> As I said, we'll have to clear that up...when I find the time, I'll edit
>>> the wiki page...
>>>
>>> -> richard
>>>
>>>
>>> Justin
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Justin
>>>>>>
>>>>>> On Jun 9, 2010, at 4:49 PM, David Jencks<da...@yahoo.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> The DEPENDENCIES file is completely optional as far as apache policy
>>>>>>> is concerned. I wrote the maven code that generates these with the
>>>>>>> intention of giving users hints about the other software that would
>>>>>>> likely be needed to actually use the artifact containing the
>>>>>>> DEPENDENCIES file. As such, it only includes (appropriately scoped)
>>>>>>> dependencies, not all the maven stuff that may have been used to
>>>>>>> generate the artifact.
>>>>>>>
>>>>>>> Since felix is an osgi based project that uses osgi to hook up
>>>>>>> bundles, and avoids require-bundle like the plague, and there's no
>>>>>>> good reason to suppose that the maven dependencies will be the actual
>>>>>>> providers of the required imports, a strong case could be made that
>>>>>>> felix should simply not include DEPENDENCIES files.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Jun 9, 2010, at 12:30 PM, Richard S. Hall wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 6/9/10 14:52, Justin Edelson wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Richard-
>>>>>>>>> Perhaps this is supposed to be obvious, but I think it would be
>>>>>>>>> helpful to
>>>>>>>>> define the term "uses" with respect to the DEPENDENCIES file. IIUC,
>>>>>>>>> it
>>>>>>>>> includes dependencies (in any scope) as well as software executed
>>>>>>>>> as part of
>>>>>>>>> the build (i.e. Maven Plugins), but the inclusion of the latter may
>>>>>>>>> not be
>>>>>>>>> intuitive.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> True. We need to be clearer...
>>>>>>>>
>>>>>>>> -> richard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Justin
>>>>>>>>>
>>>>>>>>> On Wed, Jun 9, 2010 at 1:55 PM, Richard S.
>>>>>>>>> Hall<he...@ungoverned.org>wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> With the latest release of the framework and Gogo modules, we've
>>>>>>>>>> tried to
>>>>>>>>>> update the release process for how we handle the NOTICE file. Our
>>>>>>>>>> past usage
>>>>>>>>>> is apparently not aligned with the intended usage, where the
>>>>>>>>>> NOTICE file
>>>>>>>>>> should only contained notices for included third-party software
>>>>>>>>>> whose
>>>>>>>>>> license requires notice. Our new approach (for now) is this:
>>>>>>>>>>
>>>>>>>>>> 1. Include a NOTICE file which contains only required notices.
>>>>>>>>>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>>>>>>>>>> about the software the subproject uses.
>>>>>>>>>>
>>>>>>>>>> For the most part, this isn't a major hassle and largely boils
>>>>>>>>>> down to
>>>>>>>>>> this:
>>>>>>>>>>
>>>>>>>>>> 1. Rename the current NOTICE file to DEPENDENCIES.
>>>>>>>>>> 2. Create a new NOTICE file that contains notices only for the
>>>>>>>>>> "used"
>>>>>>>>>> software requiring notices in the DEPENDENCIES file.
>>>>>>>>>>
>>>>>>>>>> Although the new DEPENDENCIES file is very similar to the old
>>>>>>>>>> NOTICE file,
>>>>>>>>>> the template is slightly different as indicated here:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Of course, in the long term we can try to move to automating the
>>>>>>>>>> generation
>>>>>>>>>> of the NOTICE and/or DEPENDENCIES files, which would make our
>>>>>>>>>> lives simpler.
>>>>>>>>>> If any subprojects currently are able to automate this
>>>>>>>>>> information, as long
>>>>>>>>>> as the generated files contain information consistent with what is
>>>>>>>>>> proposed
>>>>>>>>>> here, then the exact formatting is not that important. But for
>>>>>>>>>> hand
>>>>>>>>>> generated files, follow this template.
>>>>>>>>>>
>>>>>>>>>> If you want to see examples, look in the framework or gogo
>>>>>>>>>> subprojects.
>>>>>>>>>>
>>>>>>>>>> -> richard
>>>>>>>>>>
>>>>>>>>>> p.s. This is obviously all open for discussion to the specifics,
>>>>>>>>>> but until
>>>>>>>>>> then we should use this approach for releases in an effort to
>>>>>>>>>> better align
>>>>>>>>>> with Apache process (with perhaps the exception of Karaf since
>>>>>>>>>> if/when it
>>>>>>>>>> goes TLP then its PMC will decide how to do releases).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/10/10 9:47, Guillaume Nodet wrote:
> I think we should keep the amount of legal files to the bare minimum, i.e.
> make sure the LICENSE and NOTICE files are correct wrt the ASF ways of doing
> things. Anything else is not mandatory and imho, should be removed, unless
> generated, to avoid the extra work of maintaining those files for no real
> added value.
>
Not sure to what you are referring, this is exactly what is being done
now. The DEPENDENCIES file is not a legal file, so that is a non-issue.
If you are saying you are against acknowledging the software we depend
on, then we can have that discussion, but it has nothing to do with the
legal files.
-> richard
> On Thu, Jun 10, 2010 at 15:41, Richard S. Hall<he...@ungoverned.org> wrote:
>
>
>> On 6/10/10 9:03, Justin Edelson wrote:
>>
>>
>>> On 6/10/10 8:54 AM, Richard S. Hall wrote:
>>>
>>>
>>>
>>>> On 6/9/10 17:11, Justin Edelson wrote:
>>>>
>>>>
>>>>
>>>>> Hmmm. When I looked at the framework DEPENDENCIES file, there was a
>>>>> reference to codehaus, but I didn't think the framework depends upon
>>>>> codehaus libraries, just some Maven plugin.
>>>>>
>>>>>
>>>>>
>>>> I think it was the RAT plugin, but this has since moved to Apache, right?
>>>>
>>>>
>>>>
>>> My (albeit very vague) understanding is that it is in the process of
>>> being moved. In any case, the framework pom still references the
>>> codehaus version.
>>>
>>>
>>>
>> Yeah, that should probably be upgraded at some point.
>>
>>
>> I think it very classy to acknowledge plugins like this. It just isn't
>>
>>> clear to me that, based on your original email, that was your intent.
>>>
>>>
>>>
>> As I said, we'll have to clear that up...when I find the time, I'll edit
>> the wiki page...
>>
>> -> richard
>>
>>
>> Justin
>>
>>>
>>>
>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>>
>>>>> Justin
>>>>>
>>>>> On Jun 9, 2010, at 4:49 PM, David Jencks<da...@yahoo.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> The DEPENDENCIES file is completely optional as far as apache policy
>>>>>> is concerned. I wrote the maven code that generates these with the
>>>>>> intention of giving users hints about the other software that would
>>>>>> likely be needed to actually use the artifact containing the
>>>>>> DEPENDENCIES file. As such, it only includes (appropriately scoped)
>>>>>> dependencies, not all the maven stuff that may have been used to
>>>>>> generate the artifact.
>>>>>>
>>>>>> Since felix is an osgi based project that uses osgi to hook up
>>>>>> bundles, and avoids require-bundle like the plague, and there's no
>>>>>> good reason to suppose that the maven dependencies will be the actual
>>>>>> providers of the required imports, a strong case could be made that
>>>>>> felix should simply not include DEPENDENCIES files.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On Jun 9, 2010, at 12:30 PM, Richard S. Hall wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 6/9/10 14:52, Justin Edelson wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Richard-
>>>>>>>> Perhaps this is supposed to be obvious, but I think it would be
>>>>>>>> helpful to
>>>>>>>> define the term "uses" with respect to the DEPENDENCIES file. IIUC,
>>>>>>>> it
>>>>>>>> includes dependencies (in any scope) as well as software executed
>>>>>>>> as part of
>>>>>>>> the build (i.e. Maven Plugins), but the inclusion of the latter may
>>>>>>>> not be
>>>>>>>> intuitive.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> True. We need to be clearer...
>>>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Justin
>>>>>>>>
>>>>>>>> On Wed, Jun 9, 2010 at 1:55 PM, Richard S.
>>>>>>>> Hall<he...@ungoverned.org>wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> With the latest release of the framework and Gogo modules, we've
>>>>>>>>> tried to
>>>>>>>>> update the release process for how we handle the NOTICE file. Our
>>>>>>>>> past usage
>>>>>>>>> is apparently not aligned with the intended usage, where the
>>>>>>>>> NOTICE file
>>>>>>>>> should only contained notices for included third-party software
>>>>>>>>> whose
>>>>>>>>> license requires notice. Our new approach (for now) is this:
>>>>>>>>>
>>>>>>>>> 1. Include a NOTICE file which contains only required notices.
>>>>>>>>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>>>>>>>>> about the software the subproject uses.
>>>>>>>>>
>>>>>>>>> For the most part, this isn't a major hassle and largely boils
>>>>>>>>> down to
>>>>>>>>> this:
>>>>>>>>>
>>>>>>>>> 1. Rename the current NOTICE file to DEPENDENCIES.
>>>>>>>>> 2. Create a new NOTICE file that contains notices only for the
>>>>>>>>> "used"
>>>>>>>>> software requiring notices in the DEPENDENCIES file.
>>>>>>>>>
>>>>>>>>> Although the new DEPENDENCIES file is very similar to the old
>>>>>>>>> NOTICE file,
>>>>>>>>> the template is slightly different as indicated here:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Of course, in the long term we can try to move to automating the
>>>>>>>>> generation
>>>>>>>>> of the NOTICE and/or DEPENDENCIES files, which would make our
>>>>>>>>> lives simpler.
>>>>>>>>> If any subprojects currently are able to automate this
>>>>>>>>> information, as long
>>>>>>>>> as the generated files contain information consistent with what is
>>>>>>>>> proposed
>>>>>>>>> here, then the exact formatting is not that important. But for hand
>>>>>>>>> generated files, follow this template.
>>>>>>>>>
>>>>>>>>> If you want to see examples, look in the framework or gogo
>>>>>>>>> subprojects.
>>>>>>>>>
>>>>>>>>> -> richard
>>>>>>>>>
>>>>>>>>> p.s. This is obviously all open for discussion to the specifics,
>>>>>>>>> but until
>>>>>>>>> then we should use this approach for releases in an effort to
>>>>>>>>> better align
>>>>>>>>> with Apache process (with perhaps the exception of Karaf since
>>>>>>>>> if/when it
>>>>>>>>> goes TLP then its PMC will decide how to do releases).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>
>
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by Guillaume Nodet <gn...@gmail.com>.
I think we should keep the amount of legal files to the bare minimum, i.e.
make sure the LICENSE and NOTICE files are correct wrt the ASF ways of doing
things. Anything else is not mandatory and imho, should be removed, unless
generated, to avoid the extra work of maintaining those files for no real
added value.
On Thu, Jun 10, 2010 at 15:41, Richard S. Hall <he...@ungoverned.org> wrote:
> On 6/10/10 9:03, Justin Edelson wrote:
>
>> On 6/10/10 8:54 AM, Richard S. Hall wrote:
>>
>>
>>> On 6/9/10 17:11, Justin Edelson wrote:
>>>
>>>
>>>> Hmmm. When I looked at the framework DEPENDENCIES file, there was a
>>>> reference to codehaus, but I didn't think the framework depends upon
>>>> codehaus libraries, just some Maven plugin.
>>>>
>>>>
>>> I think it was the RAT plugin, but this has since moved to Apache, right?
>>>
>>>
>> My (albeit very vague) understanding is that it is in the process of
>> being moved. In any case, the framework pom still references the
>> codehaus version.
>>
>>
>
> Yeah, that should probably be upgraded at some point.
>
>
> I think it very classy to acknowledge plugins like this. It just isn't
>> clear to me that, based on your original email, that was your intent.
>>
>>
>
> As I said, we'll have to clear that up...when I find the time, I'll edit
> the wiki page...
>
> -> richard
>
>
> Justin
>>
>>
>>
>>> -> richard
>>>
>>>
>>>
>>>> Justin
>>>>
>>>> On Jun 9, 2010, at 4:49 PM, David Jencks<da...@yahoo.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>> The DEPENDENCIES file is completely optional as far as apache policy
>>>>> is concerned. I wrote the maven code that generates these with the
>>>>> intention of giving users hints about the other software that would
>>>>> likely be needed to actually use the artifact containing the
>>>>> DEPENDENCIES file. As such, it only includes (appropriately scoped)
>>>>> dependencies, not all the maven stuff that may have been used to
>>>>> generate the artifact.
>>>>>
>>>>> Since felix is an osgi based project that uses osgi to hook up
>>>>> bundles, and avoids require-bundle like the plague, and there's no
>>>>> good reason to suppose that the maven dependencies will be the actual
>>>>> providers of the required imports, a strong case could be made that
>>>>> felix should simply not include DEPENDENCIES files.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Jun 9, 2010, at 12:30 PM, Richard S. Hall wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On 6/9/10 14:52, Justin Edelson wrote:
>>>>>>
>>>>>>
>>>>>>> Richard-
>>>>>>> Perhaps this is supposed to be obvious, but I think it would be
>>>>>>> helpful to
>>>>>>> define the term "uses" with respect to the DEPENDENCIES file. IIUC,
>>>>>>> it
>>>>>>> includes dependencies (in any scope) as well as software executed
>>>>>>> as part of
>>>>>>> the build (i.e. Maven Plugins), but the inclusion of the latter may
>>>>>>> not be
>>>>>>> intuitive.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> True. We need to be clearer...
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Justin
>>>>>>>
>>>>>>> On Wed, Jun 9, 2010 at 1:55 PM, Richard S.
>>>>>>> Hall<he...@ungoverned.org>wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> With the latest release of the framework and Gogo modules, we've
>>>>>>>> tried to
>>>>>>>> update the release process for how we handle the NOTICE file. Our
>>>>>>>> past usage
>>>>>>>> is apparently not aligned with the intended usage, where the
>>>>>>>> NOTICE file
>>>>>>>> should only contained notices for included third-party software
>>>>>>>> whose
>>>>>>>> license requires notice. Our new approach (for now) is this:
>>>>>>>>
>>>>>>>> 1. Include a NOTICE file which contains only required notices.
>>>>>>>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>>>>>>>> about the software the subproject uses.
>>>>>>>>
>>>>>>>> For the most part, this isn't a major hassle and largely boils
>>>>>>>> down to
>>>>>>>> this:
>>>>>>>>
>>>>>>>> 1. Rename the current NOTICE file to DEPENDENCIES.
>>>>>>>> 2. Create a new NOTICE file that contains notices only for the
>>>>>>>> "used"
>>>>>>>> software requiring notices in the DEPENDENCIES file.
>>>>>>>>
>>>>>>>> Although the new DEPENDENCIES file is very similar to the old
>>>>>>>> NOTICE file,
>>>>>>>> the template is slightly different as indicated here:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>>>>>>>
>>>>>>>>
>>>>>>>> Of course, in the long term we can try to move to automating the
>>>>>>>> generation
>>>>>>>> of the NOTICE and/or DEPENDENCIES files, which would make our
>>>>>>>> lives simpler.
>>>>>>>> If any subprojects currently are able to automate this
>>>>>>>> information, as long
>>>>>>>> as the generated files contain information consistent with what is
>>>>>>>> proposed
>>>>>>>> here, then the exact formatting is not that important. But for hand
>>>>>>>> generated files, follow this template.
>>>>>>>>
>>>>>>>> If you want to see examples, look in the framework or gogo
>>>>>>>> subprojects.
>>>>>>>>
>>>>>>>> -> richard
>>>>>>>>
>>>>>>>> p.s. This is obviously all open for discussion to the specifics,
>>>>>>>> but until
>>>>>>>> then we should use this approach for releases in an effort to
>>>>>>>> better align
>>>>>>>> with Apache process (with perhaps the exception of Karaf since
>>>>>>>> if/when it
>>>>>>>> goes TLP then its PMC will decide how to do releases).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/10/10 9:03, Justin Edelson wrote:
> On 6/10/10 8:54 AM, Richard S. Hall wrote:
>
>> On 6/9/10 17:11, Justin Edelson wrote:
>>
>>> Hmmm. When I looked at the framework DEPENDENCIES file, there was a
>>> reference to codehaus, but I didn't think the framework depends upon
>>> codehaus libraries, just some Maven plugin.
>>>
>> I think it was the RAT plugin, but this has since moved to Apache, right?
>>
> My (albeit very vague) understanding is that it is in the process of
> being moved. In any case, the framework pom still references the
> codehaus version.
>
Yeah, that should probably be upgraded at some point.
> I think it very classy to acknowledge plugins like this. It just isn't
> clear to me that, based on your original email, that was your intent.
>
As I said, we'll have to clear that up...when I find the time, I'll edit
the wiki page...
-> richard
> Justin
>
>
>> -> richard
>>
>>
>>> Justin
>>>
>>> On Jun 9, 2010, at 4:49 PM, David Jencks<da...@yahoo.com> wrote:
>>>
>>>
>>>> The DEPENDENCIES file is completely optional as far as apache policy
>>>> is concerned. I wrote the maven code that generates these with the
>>>> intention of giving users hints about the other software that would
>>>> likely be needed to actually use the artifact containing the
>>>> DEPENDENCIES file. As such, it only includes (appropriately scoped)
>>>> dependencies, not all the maven stuff that may have been used to
>>>> generate the artifact.
>>>>
>>>> Since felix is an osgi based project that uses osgi to hook up
>>>> bundles, and avoids require-bundle like the plague, and there's no
>>>> good reason to suppose that the maven dependencies will be the actual
>>>> providers of the required imports, a strong case could be made that
>>>> felix should simply not include DEPENDENCIES files.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Jun 9, 2010, at 12:30 PM, Richard S. Hall wrote:
>>>>
>>>>
>>>>> On 6/9/10 14:52, Justin Edelson wrote:
>>>>>
>>>>>> Richard-
>>>>>> Perhaps this is supposed to be obvious, but I think it would be
>>>>>> helpful to
>>>>>> define the term "uses" with respect to the DEPENDENCIES file. IIUC, it
>>>>>> includes dependencies (in any scope) as well as software executed
>>>>>> as part of
>>>>>> the build (i.e. Maven Plugins), but the inclusion of the latter may
>>>>>> not be
>>>>>> intuitive.
>>>>>>
>>>>>>
>>>>> True. We need to be clearer...
>>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>>> Justin
>>>>>>
>>>>>> On Wed, Jun 9, 2010 at 1:55 PM, Richard S.
>>>>>> Hall<he...@ungoverned.org>wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> With the latest release of the framework and Gogo modules, we've
>>>>>>> tried to
>>>>>>> update the release process for how we handle the NOTICE file. Our
>>>>>>> past usage
>>>>>>> is apparently not aligned with the intended usage, where the
>>>>>>> NOTICE file
>>>>>>> should only contained notices for included third-party software whose
>>>>>>> license requires notice. Our new approach (for now) is this:
>>>>>>>
>>>>>>> 1. Include a NOTICE file which contains only required notices.
>>>>>>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>>>>>>> about the software the subproject uses.
>>>>>>>
>>>>>>> For the most part, this isn't a major hassle and largely boils
>>>>>>> down to
>>>>>>> this:
>>>>>>>
>>>>>>> 1. Rename the current NOTICE file to DEPENDENCIES.
>>>>>>> 2. Create a new NOTICE file that contains notices only for the "used"
>>>>>>> software requiring notices in the DEPENDENCIES file.
>>>>>>>
>>>>>>> Although the new DEPENDENCIES file is very similar to the old
>>>>>>> NOTICE file,
>>>>>>> the template is slightly different as indicated here:
>>>>>>>
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>>>>>>
>>>>>>>
>>>>>>> Of course, in the long term we can try to move to automating the
>>>>>>> generation
>>>>>>> of the NOTICE and/or DEPENDENCIES files, which would make our
>>>>>>> lives simpler.
>>>>>>> If any subprojects currently are able to automate this
>>>>>>> information, as long
>>>>>>> as the generated files contain information consistent with what is
>>>>>>> proposed
>>>>>>> here, then the exact formatting is not that important. But for hand
>>>>>>> generated files, follow this template.
>>>>>>>
>>>>>>> If you want to see examples, look in the framework or gogo
>>>>>>> subprojects.
>>>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>> p.s. This is obviously all open for discussion to the specifics,
>>>>>>> but until
>>>>>>> then we should use this approach for releases in an effort to
>>>>>>> better align
>>>>>>> with Apache process (with perhaps the exception of Karaf since
>>>>>>> if/when it
>>>>>>> goes TLP then its PMC will decide how to do releases).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by Justin Edelson <ju...@gmail.com>.
On 6/10/10 8:54 AM, Richard S. Hall wrote:
> On 6/9/10 17:11, Justin Edelson wrote:
>> Hmmm. When I looked at the framework DEPENDENCIES file, there was a
>> reference to codehaus, but I didn't think the framework depends upon
>> codehaus libraries, just some Maven plugin.
>
> I think it was the RAT plugin, but this has since moved to Apache, right?
My (albeit very vague) understanding is that it is in the process of
being moved. In any case, the framework pom still references the
codehaus version.
I think it very classy to acknowledge plugins like this. It just isn't
clear to me that, based on your original email, that was your intent.
Justin
>
> -> richard
>
>>
>> Justin
>>
>> On Jun 9, 2010, at 4:49 PM, David Jencks <da...@yahoo.com> wrote:
>>
>>> The DEPENDENCIES file is completely optional as far as apache policy
>>> is concerned. I wrote the maven code that generates these with the
>>> intention of giving users hints about the other software that would
>>> likely be needed to actually use the artifact containing the
>>> DEPENDENCIES file. As such, it only includes (appropriately scoped)
>>> dependencies, not all the maven stuff that may have been used to
>>> generate the artifact.
>>>
>>> Since felix is an osgi based project that uses osgi to hook up
>>> bundles, and avoids require-bundle like the plague, and there's no
>>> good reason to suppose that the maven dependencies will be the actual
>>> providers of the required imports, a strong case could be made that
>>> felix should simply not include DEPENDENCIES files.
>>>
>>> thanks
>>> david jencks
>>>
>>> On Jun 9, 2010, at 12:30 PM, Richard S. Hall wrote:
>>>
>>>> On 6/9/10 14:52, Justin Edelson wrote:
>>>>> Richard-
>>>>> Perhaps this is supposed to be obvious, but I think it would be
>>>>> helpful to
>>>>> define the term "uses" with respect to the DEPENDENCIES file. IIUC, it
>>>>> includes dependencies (in any scope) as well as software executed
>>>>> as part of
>>>>> the build (i.e. Maven Plugins), but the inclusion of the latter may
>>>>> not be
>>>>> intuitive.
>>>>>
>>>>
>>>> True. We need to be clearer...
>>>>
>>>> -> richard
>>>>
>>>>> Justin
>>>>>
>>>>> On Wed, Jun 9, 2010 at 1:55 PM, Richard S.
>>>>> Hall<he...@ungoverned.org>wrote:
>>>>>
>>>>>
>>>>>> With the latest release of the framework and Gogo modules, we've
>>>>>> tried to
>>>>>> update the release process for how we handle the NOTICE file. Our
>>>>>> past usage
>>>>>> is apparently not aligned with the intended usage, where the
>>>>>> NOTICE file
>>>>>> should only contained notices for included third-party software whose
>>>>>> license requires notice. Our new approach (for now) is this:
>>>>>>
>>>>>> 1. Include a NOTICE file which contains only required notices.
>>>>>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>>>>>> about the software the subproject uses.
>>>>>>
>>>>>> For the most part, this isn't a major hassle and largely boils
>>>>>> down to
>>>>>> this:
>>>>>>
>>>>>> 1. Rename the current NOTICE file to DEPENDENCIES.
>>>>>> 2. Create a new NOTICE file that contains notices only for the "used"
>>>>>> software requiring notices in the DEPENDENCIES file.
>>>>>>
>>>>>> Although the new DEPENDENCIES file is very similar to the old
>>>>>> NOTICE file,
>>>>>> the template is slightly different as indicated here:
>>>>>>
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>>>>>
>>>>>>
>>>>>> Of course, in the long term we can try to move to automating the
>>>>>> generation
>>>>>> of the NOTICE and/or DEPENDENCIES files, which would make our
>>>>>> lives simpler.
>>>>>> If any subprojects currently are able to automate this
>>>>>> information, as long
>>>>>> as the generated files contain information consistent with what is
>>>>>> proposed
>>>>>> here, then the exact formatting is not that important. But for hand
>>>>>> generated files, follow this template.
>>>>>>
>>>>>> If you want to see examples, look in the framework or gogo
>>>>>> subprojects.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>> p.s. This is obviously all open for discussion to the specifics,
>>>>>> but until
>>>>>> then we should use this approach for releases in an effort to
>>>>>> better align
>>>>>> with Apache process (with perhaps the exception of Karaf since
>>>>>> if/when it
>>>>>> goes TLP then its PMC will decide how to do releases).
>>>>>>
>>>>>>
>>>>>
>>>
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/9/10 17:11, Justin Edelson wrote:
> Hmmm. When I looked at the framework DEPENDENCIES file, there was a
> reference to codehaus, but I didn't think the framework depends upon
> codehaus libraries, just some Maven plugin.
I think it was the RAT plugin, but this has since moved to Apache, right?
-> richard
>
> Justin
>
> On Jun 9, 2010, at 4:49 PM, David Jencks <da...@yahoo.com> wrote:
>
>> The DEPENDENCIES file is completely optional as far as apache policy
>> is concerned. I wrote the maven code that generates these with the
>> intention of giving users hints about the other software that would
>> likely be needed to actually use the artifact containing the
>> DEPENDENCIES file. As such, it only includes (appropriately scoped)
>> dependencies, not all the maven stuff that may have been used to
>> generate the artifact.
>>
>> Since felix is an osgi based project that uses osgi to hook up
>> bundles, and avoids require-bundle like the plague, and there's no
>> good reason to suppose that the maven dependencies will be the actual
>> providers of the required imports, a strong case could be made that
>> felix should simply not include DEPENDENCIES files.
>>
>> thanks
>> david jencks
>>
>> On Jun 9, 2010, at 12:30 PM, Richard S. Hall wrote:
>>
>>> On 6/9/10 14:52, Justin Edelson wrote:
>>>> Richard-
>>>> Perhaps this is supposed to be obvious, but I think it would be
>>>> helpful to
>>>> define the term "uses" with respect to the DEPENDENCIES file. IIUC, it
>>>> includes dependencies (in any scope) as well as software executed
>>>> as part of
>>>> the build (i.e. Maven Plugins), but the inclusion of the latter may
>>>> not be
>>>> intuitive.
>>>>
>>>
>>> True. We need to be clearer...
>>>
>>> -> richard
>>>
>>>> Justin
>>>>
>>>> On Wed, Jun 9, 2010 at 1:55 PM, Richard S.
>>>> Hall<he...@ungoverned.org>wrote:
>>>>
>>>>
>>>>> With the latest release of the framework and Gogo modules, we've
>>>>> tried to
>>>>> update the release process for how we handle the NOTICE file. Our
>>>>> past usage
>>>>> is apparently not aligned with the intended usage, where the
>>>>> NOTICE file
>>>>> should only contained notices for included third-party software whose
>>>>> license requires notice. Our new approach (for now) is this:
>>>>>
>>>>> 1. Include a NOTICE file which contains only required notices.
>>>>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>>>>> about the software the subproject uses.
>>>>>
>>>>> For the most part, this isn't a major hassle and largely boils
>>>>> down to
>>>>> this:
>>>>>
>>>>> 1. Rename the current NOTICE file to DEPENDENCIES.
>>>>> 2. Create a new NOTICE file that contains notices only for the "used"
>>>>> software requiring notices in the DEPENDENCIES file.
>>>>>
>>>>> Although the new DEPENDENCIES file is very similar to the old
>>>>> NOTICE file,
>>>>> the template is slightly different as indicated here:
>>>>>
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>>>>
>>>>>
>>>>> Of course, in the long term we can try to move to automating the
>>>>> generation
>>>>> of the NOTICE and/or DEPENDENCIES files, which would make our
>>>>> lives simpler.
>>>>> If any subprojects currently are able to automate this
>>>>> information, as long
>>>>> as the generated files contain information consistent with what is
>>>>> proposed
>>>>> here, then the exact formatting is not that important. But for hand
>>>>> generated files, follow this template.
>>>>>
>>>>> If you want to see examples, look in the framework or gogo
>>>>> subprojects.
>>>>>
>>>>> -> richard
>>>>>
>>>>> p.s. This is obviously all open for discussion to the specifics,
>>>>> but until
>>>>> then we should use this approach for releases in an effort to
>>>>> better align
>>>>> with Apache process (with perhaps the exception of Karaf since
>>>>> if/when it
>>>>> goes TLP then its PMC will decide how to do releases).
>>>>>
>>>>>
>>>>
>>
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by Justin Edelson <ju...@gmail.com>.
Hmmm. When I looked at the framework DEPENDENCIES file, there was a
reference to codehaus, but I didn't think the framework depends upon
codehaus libraries, just some Maven plugin.
Justin
On Jun 9, 2010, at 4:49 PM, David Jencks <da...@yahoo.com> wrote:
> The DEPENDENCIES file is completely optional as far as apache policy
> is concerned. I wrote the maven code that generates these with the
> intention of giving users hints about the other software that would
> likely be needed to actually use the artifact containing the
> DEPENDENCIES file. As such, it only includes (appropriately scoped)
> dependencies, not all the maven stuff that may have been used to
> generate the artifact.
>
> Since felix is an osgi based project that uses osgi to hook up
> bundles, and avoids require-bundle like the plague, and there's no
> good reason to suppose that the maven dependencies will be the
> actual providers of the required imports, a strong case could be
> made that felix should simply not include DEPENDENCIES files.
>
> thanks
> david jencks
>
> On Jun 9, 2010, at 12:30 PM, Richard S. Hall wrote:
>
>> On 6/9/10 14:52, Justin Edelson wrote:
>>> Richard-
>>> Perhaps this is supposed to be obvious, but I think it would be
>>> helpful to
>>> define the term "uses" with respect to the DEPENDENCIES file.
>>> IIUC, it
>>> includes dependencies (in any scope) as well as software executed
>>> as part of
>>> the build (i.e. Maven Plugins), but the inclusion of the latter
>>> may not be
>>> intuitive.
>>>
>>
>> True. We need to be clearer...
>>
>> -> richard
>>
>>> Justin
>>>
>>> On Wed, Jun 9, 2010 at 1:55 PM, Richard S.
>>> Hall<he...@ungoverned.org>wrote:
>>>
>>>
>>>> With the latest release of the framework and Gogo modules, we've
>>>> tried to
>>>> update the release process for how we handle the NOTICE file. Our
>>>> past usage
>>>> is apparently not aligned with the intended usage, where the
>>>> NOTICE file
>>>> should only contained notices for included third-party software
>>>> whose
>>>> license requires notice. Our new approach (for now) is this:
>>>>
>>>> 1. Include a NOTICE file which contains only required notices.
>>>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>>>> about the software the subproject uses.
>>>>
>>>> For the most part, this isn't a major hassle and largely boils
>>>> down to
>>>> this:
>>>>
>>>> 1. Rename the current NOTICE file to DEPENDENCIES.
>>>> 2. Create a new NOTICE file that contains notices only for the
>>>> "used"
>>>> software requiring notices in the DEPENDENCIES file.
>>>>
>>>> Although the new DEPENDENCIES file is very similar to the old
>>>> NOTICE file,
>>>> the template is slightly different as indicated here:
>>>>
>>>>
>>>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>>>
>>>> Of course, in the long term we can try to move to automating the
>>>> generation
>>>> of the NOTICE and/or DEPENDENCIES files, which would make our
>>>> lives simpler.
>>>> If any subprojects currently are able to automate this
>>>> information, as long
>>>> as the generated files contain information consistent with what
>>>> is proposed
>>>> here, then the exact formatting is not that important. But for hand
>>>> generated files, follow this template.
>>>>
>>>> If you want to see examples, look in the framework or gogo
>>>> subprojects.
>>>>
>>>> -> richard
>>>>
>>>> p.s. This is obviously all open for discussion to the specifics,
>>>> but until
>>>> then we should use this approach for releases in an effort to
>>>> better align
>>>> with Apache process (with perhaps the exception of Karaf since if/
>>>> when it
>>>> goes TLP then its PMC will decide how to do releases).
>>>>
>>>>
>>>
>
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/9/10 16:49, David Jencks wrote:
> The DEPENDENCIES file is completely optional as far as apache policy is concerned. I wrote the maven code that generates these with the intention of giving users hints about the other software that would likely be needed to actually use the artifact containing the DEPENDENCIES file. As such, it only includes (appropriately scoped) dependencies, not all the maven stuff that may have been used to generate the artifact.
>
> Since felix is an osgi based project that uses osgi to hook up bundles, and avoids require-bundle like the plague, and there's no good reason to suppose that the maven dependencies will be the actual providers of the required imports, a strong case could be made that felix should simply not include DEPENDENCIES files.
>
There is no real requirement to include DEPENDENCIES other than trying
to acknowledge the other software we use. Even though we avoid
require-bundle, it is still typically possible to know which software we
use, so we just try to be nice and acknowledge it. I was originally
going to call the file ACKNOWLEDGMENTS, but decided to use DEPENDENCIES
so that it would be the same as the generated file if people wanted to
generate it. Ultimately, we could decide to stop doing this, but for now
we do.
-> richard
> thanks
> david jencks
>
> On Jun 9, 2010, at 12:30 PM, Richard S. Hall wrote:
>
>
>> On 6/9/10 14:52, Justin Edelson wrote:
>>
>>> Richard-
>>> Perhaps this is supposed to be obvious, but I think it would be helpful to
>>> define the term "uses" with respect to the DEPENDENCIES file. IIUC, it
>>> includes dependencies (in any scope) as well as software executed as part of
>>> the build (i.e. Maven Plugins), but the inclusion of the latter may not be
>>> intuitive.
>>>
>>>
>> True. We need to be clearer...
>>
>> -> richard
>>
>>
>>> Justin
>>>
>>> On Wed, Jun 9, 2010 at 1:55 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>>>
>>>
>>>
>>>> With the latest release of the framework and Gogo modules, we've tried to
>>>> update the release process for how we handle the NOTICE file. Our past usage
>>>> is apparently not aligned with the intended usage, where the NOTICE file
>>>> should only contained notices for included third-party software whose
>>>> license requires notice. Our new approach (for now) is this:
>>>>
>>>> 1. Include a NOTICE file which contains only required notices.
>>>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>>>> about the software the subproject uses.
>>>>
>>>> For the most part, this isn't a major hassle and largely boils down to
>>>> this:
>>>>
>>>> 1. Rename the current NOTICE file to DEPENDENCIES.
>>>> 2. Create a new NOTICE file that contains notices only for the "used"
>>>> software requiring notices in the DEPENDENCIES file.
>>>>
>>>> Although the new DEPENDENCIES file is very similar to the old NOTICE file,
>>>> the template is slightly different as indicated here:
>>>>
>>>>
>>>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>>>
>>>> Of course, in the long term we can try to move to automating the generation
>>>> of the NOTICE and/or DEPENDENCIES files, which would make our lives simpler.
>>>> If any subprojects currently are able to automate this information, as long
>>>> as the generated files contain information consistent with what is proposed
>>>> here, then the exact formatting is not that important. But for hand
>>>> generated files, follow this template.
>>>>
>>>> If you want to see examples, look in the framework or gogo subprojects.
>>>>
>>>> -> richard
>>>>
>>>> p.s. This is obviously all open for discussion to the specifics, but until
>>>> then we should use this approach for releases in an effort to better align
>>>> with Apache process (with perhaps the exception of Karaf since if/when it
>>>> goes TLP then its PMC will decide how to do releases).
>>>>
>>>>
>>>>
>>>
>>>
>
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by David Jencks <da...@yahoo.com>.
The DEPENDENCIES file is completely optional as far as apache policy is concerned. I wrote the maven code that generates these with the intention of giving users hints about the other software that would likely be needed to actually use the artifact containing the DEPENDENCIES file. As such, it only includes (appropriately scoped) dependencies, not all the maven stuff that may have been used to generate the artifact.
Since felix is an osgi based project that uses osgi to hook up bundles, and avoids require-bundle like the plague, and there's no good reason to suppose that the maven dependencies will be the actual providers of the required imports, a strong case could be made that felix should simply not include DEPENDENCIES files.
thanks
david jencks
On Jun 9, 2010, at 12:30 PM, Richard S. Hall wrote:
> On 6/9/10 14:52, Justin Edelson wrote:
>> Richard-
>> Perhaps this is supposed to be obvious, but I think it would be helpful to
>> define the term "uses" with respect to the DEPENDENCIES file. IIUC, it
>> includes dependencies (in any scope) as well as software executed as part of
>> the build (i.e. Maven Plugins), but the inclusion of the latter may not be
>> intuitive.
>>
>
> True. We need to be clearer...
>
> -> richard
>
>> Justin
>>
>> On Wed, Jun 9, 2010 at 1:55 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>>
>>
>>> With the latest release of the framework and Gogo modules, we've tried to
>>> update the release process for how we handle the NOTICE file. Our past usage
>>> is apparently not aligned with the intended usage, where the NOTICE file
>>> should only contained notices for included third-party software whose
>>> license requires notice. Our new approach (for now) is this:
>>>
>>> 1. Include a NOTICE file which contains only required notices.
>>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>>> about the software the subproject uses.
>>>
>>> For the most part, this isn't a major hassle and largely boils down to
>>> this:
>>>
>>> 1. Rename the current NOTICE file to DEPENDENCIES.
>>> 2. Create a new NOTICE file that contains notices only for the "used"
>>> software requiring notices in the DEPENDENCIES file.
>>>
>>> Although the new DEPENDENCIES file is very similar to the old NOTICE file,
>>> the template is slightly different as indicated here:
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>>
>>> Of course, in the long term we can try to move to automating the generation
>>> of the NOTICE and/or DEPENDENCIES files, which would make our lives simpler.
>>> If any subprojects currently are able to automate this information, as long
>>> as the generated files contain information consistent with what is proposed
>>> here, then the exact formatting is not that important. But for hand
>>> generated files, follow this template.
>>>
>>> If you want to see examples, look in the framework or gogo subprojects.
>>>
>>> -> richard
>>>
>>> p.s. This is obviously all open for discussion to the specifics, but until
>>> then we should use this approach for releases in an effort to better align
>>> with Apache process (with perhaps the exception of Karaf since if/when it
>>> goes TLP then its PMC will decide how to do releases).
>>>
>>>
>>
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/9/10 14:52, Justin Edelson wrote:
> Richard-
> Perhaps this is supposed to be obvious, but I think it would be helpful to
> define the term "uses" with respect to the DEPENDENCIES file. IIUC, it
> includes dependencies (in any scope) as well as software executed as part of
> the build (i.e. Maven Plugins), but the inclusion of the latter may not be
> intuitive.
>
True. We need to be clearer...
-> richard
> Justin
>
> On Wed, Jun 9, 2010 at 1:55 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>
>> With the latest release of the framework and Gogo modules, we've tried to
>> update the release process for how we handle the NOTICE file. Our past usage
>> is apparently not aligned with the intended usage, where the NOTICE file
>> should only contained notices for included third-party software whose
>> license requires notice. Our new approach (for now) is this:
>>
>> 1. Include a NOTICE file which contains only required notices.
>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>> about the software the subproject uses.
>>
>> For the most part, this isn't a major hassle and largely boils down to
>> this:
>>
>> 1. Rename the current NOTICE file to DEPENDENCIES.
>> 2. Create a new NOTICE file that contains notices only for the "used"
>> software requiring notices in the DEPENDENCIES file.
>>
>> Although the new DEPENDENCIES file is very similar to the old NOTICE file,
>> the template is slightly different as indicated here:
>>
>>
>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>
>> Of course, in the long term we can try to move to automating the generation
>> of the NOTICE and/or DEPENDENCIES files, which would make our lives simpler.
>> If any subprojects currently are able to automate this information, as long
>> as the generated files contain information consistent with what is proposed
>> here, then the exact formatting is not that important. But for hand
>> generated files, follow this template.
>>
>> If you want to see examples, look in the framework or gogo subprojects.
>>
>> -> richard
>>
>> p.s. This is obviously all open for discussion to the specifics, but until
>> then we should use this approach for releases in an effort to better align
>> with Apache process (with perhaps the exception of Karaf since if/when it
>> goes TLP then its PMC will decide how to do releases).
>>
>>
>
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by Justin Edelson <ju...@justinedelson.com>.
Richard-
Perhaps this is supposed to be obvious, but I think it would be helpful to
define the term "uses" with respect to the DEPENDENCIES file. IIUC, it
includes dependencies (in any scope) as well as software executed as part of
the build (i.e. Maven Plugins), but the inclusion of the latter may not be
intuitive.
Justin
On Wed, Jun 9, 2010 at 1:55 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> With the latest release of the framework and Gogo modules, we've tried to
> update the release process for how we handle the NOTICE file. Our past usage
> is apparently not aligned with the intended usage, where the NOTICE file
> should only contained notices for included third-party software whose
> license requires notice. Our new approach (for now) is this:
>
> 1. Include a NOTICE file which contains only required notices.
> 2. Include a DEPENDENCIES file which contains our acknowledgments
> about the software the subproject uses.
>
> For the most part, this isn't a major hassle and largely boils down to
> this:
>
> 1. Rename the current NOTICE file to DEPENDENCIES.
> 2. Create a new NOTICE file that contains notices only for the "used"
> software requiring notices in the DEPENDENCIES file.
>
> Although the new DEPENDENCIES file is very similar to the old NOTICE file,
> the template is slightly different as indicated here:
>
>
> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>
> Of course, in the long term we can try to move to automating the generation
> of the NOTICE and/or DEPENDENCIES files, which would make our lives simpler.
> If any subprojects currently are able to automate this information, as long
> as the generated files contain information consistent with what is proposed
> here, then the exact formatting is not that important. But for hand
> generated files, follow this template.
>
> If you want to see examples, look in the framework or gogo subprojects.
>
> -> richard
>
> p.s. This is obviously all open for discussion to the specifics, but until
> then we should use this approach for releases in an effort to better align
> with Apache process (with perhaps the exception of Karaf since if/when it
> goes TLP then its PMC will decide how to do releases).
>
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/9/10 14:58, Guillaume Nodet wrote:
> Isn't the DEPENDENCIES file genereted by maven?
>
It can be, but apparently it is buggy and didn't work very well in some
tests...but this is precisely why I leave it open for generation...
-> richard
> On Wednesday, June 9, 2010, Richard S. Hall<he...@ungoverned.org> wrote:
>
>> On 6/9/10 13:55, Richard S. Hall wrote:
>>
>> With the latest release of the framework and Gogo modules, we've tried to update the release process for how we handle the NOTICE file. Our past usage is apparently not aligned with the intended usage, where the NOTICE file should only contained notices for included third-party software whose license requires notice. Our new approach (for now) is this:
>>
>> 1. Include a NOTICE file which contains only required notices.
>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>> about the software the subproject uses.
>>
>> For the most part, this isn't a major hassle and largely boils down to this:
>>
>> 1. Rename the current NOTICE file to DEPENDENCIES.
>> 2. Create a new NOTICE file that contains notices only for the "used"
>> software requiring notices in the DEPENDENCIES file.
>>
>>
>> Sorry, that should say: "included" software, not "used" software...
>>
>>
>> Although the new DEPENDENCIES file is very similar to the old NOTICE file, the template is slightly different as indicated here:
>>
>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>
>> Of course, in the long term we can try to move to automating the generation of the NOTICE and/or DEPENDENCIES files, which would make our lives simpler. If any subprojects currently are able to automate this information, as long as the generated files contain information consistent with what is proposed here, then the exact formatting is not that important. But for hand generated files, follow this template.
>>
>> If you want to see examples, look in the framework or gogo subprojects.
>>
>> -> richard
>>
>> p.s. This is obviously all open for discussion to the specifics, but until then we should use this approach for releases in an effort to better align with Apache process (with perhaps the exception of Karaf since if/when it goes TLP then its PMC will decide how to do releases).
>>
>>
>>
>
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by Guillaume Nodet <gn...@gmail.com>.
Isn't the DEPENDENCIES file genereted by maven?
On Wednesday, June 9, 2010, Richard S. Hall <he...@ungoverned.org> wrote:
> On 6/9/10 13:55, Richard S. Hall wrote:
>
> With the latest release of the framework and Gogo modules, we've tried to update the release process for how we handle the NOTICE file. Our past usage is apparently not aligned with the intended usage, where the NOTICE file should only contained notices for included third-party software whose license requires notice. Our new approach (for now) is this:
>
> 1. Include a NOTICE file which contains only required notices.
> 2. Include a DEPENDENCIES file which contains our acknowledgments
> about the software the subproject uses.
>
> For the most part, this isn't a major hassle and largely boils down to this:
>
> 1. Rename the current NOTICE file to DEPENDENCIES.
> 2. Create a new NOTICE file that contains notices only for the "used"
> software requiring notices in the DEPENDENCIES file.
>
>
> Sorry, that should say: "included" software, not "used" software...
>
>
> Although the new DEPENDENCIES file is very similar to the old NOTICE file, the template is slightly different as indicated here:
>
> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>
> Of course, in the long term we can try to move to automating the generation of the NOTICE and/or DEPENDENCIES files, which would make our lives simpler. If any subprojects currently are able to automate this information, as long as the generated files contain information consistent with what is proposed here, then the exact formatting is not that important. But for hand generated files, follow this template.
>
> If you want to see examples, look in the framework or gogo subprojects.
>
> -> richard
>
> p.s. This is obviously all open for discussion to the specifics, but until then we should use this approach for releases in an effort to better align with Apache process (with perhaps the exception of Karaf since if/when it goes TLP then its PMC will decide how to do releases).
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/9/10 13:55, Richard S. Hall wrote:
> With the latest release of the framework and Gogo modules, we've tried
> to update the release process for how we handle the NOTICE file. Our
> past usage is apparently not aligned with the intended usage, where
> the NOTICE file should only contained notices for included third-party
> software whose license requires notice. Our new approach (for now) is
> this:
>
> 1. Include a NOTICE file which contains only required notices.
> 2. Include a DEPENDENCIES file which contains our acknowledgments
> about the software the subproject uses.
>
> For the most part, this isn't a major hassle and largely boils down to
> this:
>
> 1. Rename the current NOTICE file to DEPENDENCIES.
> 2. Create a new NOTICE file that contains notices only for the "used"
> software requiring notices in the DEPENDENCIES file.
Sorry, that should say: "included" software, not "used" software...
>
> Although the new DEPENDENCIES file is very similar to the old NOTICE
> file, the template is slightly different as indicated here:
>
>
> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>
>
> Of course, in the long term we can try to move to automating the
> generation of the NOTICE and/or DEPENDENCIES files, which would make
> our lives simpler. If any subprojects currently are able to automate
> this information, as long as the generated files contain information
> consistent with what is proposed here, then the exact formatting is
> not that important. But for hand generated files, follow this template.
>
> If you want to see examples, look in the framework or gogo subprojects.
>
> -> richard
>
> p.s. This is obviously all open for discussion to the specifics, but
> until then we should use this approach for releases in an effort to
> better align with Apache process (with perhaps the exception of Karaf
> since if/when it goes TLP then its PMC will decide how to do releases).
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/15/10 8:11, Felix Meschberger wrote:
> Hi,
>
> I have created FELIX-2411 as a container to fix all our subprojects over
> time.
>
> I have also updated an earlier patch to the parent POM attached to
> FELIX-1747 to use the latest Apache Parent POM 7, which already is
> correctly configured to use the Maven Remote Resources plugin and
> generate valid ASF source artifacts to vote upon.
>
> IMHO we should really be using the Maven Remote Resources plugin to
> generate the legal files.
>
> Regards
> Felix
>
> [1] https://issues.apache.org/jira/browse/FELIX-2411
> [2] https://issues.apache.org/jira/browse/FELIX-1747
>
Thanks for looking into this Felix.
I played with it a little bit by trying to build framework and OBR with
it...it didn't give me the best results, but this is likely because it
doesn't understand that we are embedding source and or byte code. Any
subproject using BND to embed byte code from other dependencies will
likely not be correct.
So, we could potentially use this to automate information gathering, but
it doesn't help us with the verification. We should probably create some
documentation and perhaps an example on how to use it and augment its
results.
Thanks.
-> richard
> On 09.06.2010 19:55, Richard S. Hall wrote:
>
>> With the latest release of the framework and Gogo modules, we've tried
>> to update the release process for how we handle the NOTICE file. Our
>> past usage is apparently not aligned with the intended usage, where the
>> NOTICE file should only contained notices for included third-party
>> software whose license requires notice. Our new approach (for now) is this:
>>
>> 1. Include a NOTICE file which contains only required notices.
>> 2. Include a DEPENDENCIES file which contains our acknowledgments
>> about the software the subproject uses.
>>
>> For the most part, this isn't a major hassle and largely boils down to
>> this:
>>
>> 1. Rename the current NOTICE file to DEPENDENCIES.
>> 2. Create a new NOTICE file that contains notices only for the "used"
>> software requiring notices in the DEPENDENCIES file.
>>
>> Although the new DEPENDENCIES file is very similar to the old NOTICE
>> file, the template is slightly different as indicated here:
>>
>>
>> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>>
>>
>> Of course, in the long term we can try to move to automating the
>> generation of the NOTICE and/or DEPENDENCIES files, which would make our
>> lives simpler. If any subprojects currently are able to automate this
>> information, as long as the generated files contain information
>> consistent with what is proposed here, then the exact formatting is not
>> that important. But for hand generated files, follow this template.
>>
>> If you want to see examples, look in the framework or gogo subprojects.
>>
>> -> richard
>>
>> p.s. This is obviously all open for discussion to the specifics, but
>> until then we should use this approach for releases in an effort to
>> better align with Apache process (with perhaps the exception of Karaf
>> since if/when it goes TLP then its PMC will decide how to do releases).
>>
>>
Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
I have created FELIX-2411 as a container to fix all our subprojects over
time.
I have also updated an earlier patch to the parent POM attached to
FELIX-1747 to use the latest Apache Parent POM 7, which already is
correctly configured to use the Maven Remote Resources plugin and
generate valid ASF source artifacts to vote upon.
IMHO we should really be using the Maven Remote Resources plugin to
generate the legal files.
Regards
Felix
[1] https://issues.apache.org/jira/browse/FELIX-2411
[2] https://issues.apache.org/jira/browse/FELIX-1747
On 09.06.2010 19:55, Richard S. Hall wrote:
> With the latest release of the framework and Gogo modules, we've tried
> to update the release process for how we handle the NOTICE file. Our
> past usage is apparently not aligned with the intended usage, where the
> NOTICE file should only contained notices for included third-party
> software whose license requires notice. Our new approach (for now) is this:
>
> 1. Include a NOTICE file which contains only required notices.
> 2. Include a DEPENDENCIES file which contains our acknowledgments
> about the software the subproject uses.
>
> For the most part, this isn't a major hassle and largely boils down to
> this:
>
> 1. Rename the current NOTICE file to DEPENDENCIES.
> 2. Create a new NOTICE file that contains notices only for the "used"
> software requiring notices in the DEPENDENCIES file.
>
> Although the new DEPENDENCIES file is very similar to the old NOTICE
> file, the template is slightly different as indicated here:
>
>
> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29
>
>
> Of course, in the long term we can try to move to automating the
> generation of the NOTICE and/or DEPENDENCIES files, which would make our
> lives simpler. If any subprojects currently are able to automate this
> information, as long as the generated files contain information
> consistent with what is proposed here, then the exact formatting is not
> that important. But for hand generated files, follow this template.
>
> If you want to see examples, look in the framework or gogo subprojects.
>
> -> richard
>
> p.s. This is obviously all open for discussion to the specifics, but
> until then we should use this approach for releases in an effort to
> better align with Apache process (with perhaps the exception of Karaf
> since if/when it goes TLP then its PMC will decide how to do releases).
>