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<david_jen...@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).
