[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-architecture-council] Who Needs Piggyback CQs?
|
For completeness, the download scanner is a _very_ simple tool that just
scans the download server and matches content based on file names. It
basically looks for JAR files directly in the file system and in ZIP
files. It works entirely based on pattern matching in the file name.
So it really only identifies JAR files that are actually included in
project downloads. It doesn't actually look at any manifest files, so it
would miss, say, references to third-party JARs that are in Orbit by not
directly included in the project downloads.
The scanner is only intended as a tool to assist with confirming that
dependencies are tracked. It's not well suited to, for example, feed
input into an IP Log.
As those of you who have used the tool have no-doubt found out, is
misses a lot of stuff. It has trouble with JAR files that do not conform
to the OSGi naming pattern. I really need to extend it to match based on
parent directory so that it can properly handle Ant JARs, for example.
But, frankly, it's just been easier for me to ignore the Ant JARs when I
use the tool and add a little warning message at the top that describes
the shortcomings.
It's worth pointing out that the download scanner and the tool that Ed
has created work on OSGi bundles only.
I am hopeful that we'll be able to use the output from Ed's tool to
augment the IP Log with information regarding the use of approved JARs
packaged as OSGi bundles in Orbit.
Any third-party library use outside of that context will still require
piggyback CQs.
Wayne
On 31/03/15 12:23 PM, Ed Merks wrote:
Gunnar,
Comments below.
On 31/03/2015 5:08 PM, Gunnar Wagenknecht wrote:
Ed,
Here are my thoughts on this:
+1 on removing the need to _manually_ manage PB CQs
-1 on removing PB CQs in general without replacing them with a
suitable reporting/tracking mechanism
An IP log is not suitable? I think I'll have a hard time getting a
process in place where CQs don't require approval, except maybe for PB
CQs, so another approach is to automate their creation and approval.
But as I say this I'm confused what automatically generated,
automatically approve CQ buys you...
I'd like to see a few changes in the IP process area, though.
(1) Every project should be allowed to consume and redistribute
IP-approved libraries without causing administrative work for PMCs
(and ideally project committers too).
Mike will not be happy that this thread becomes a "let's change
everything" approach...
(2) I prefer to keep the IP Log for listing such usage as per (1).
But you want them to refer to PB CQs, not directly to the original CQs?
(3) The IP process should change to an "opt-in" model for projects on
a "per-release" base.
I expect this is a no go. If you don't want to follow the IP process
you don't belong at Eclipse...
The key to (1) and (2) is likely automation.
The focus of my question is the extent to which PMCs feel the need to
see and approve PB CQs. Personally I don't want to see them, I don't
want to have to approve them, and I don't want to create them...
Your scanner is a good idea, Wayne also has a downloads scanner.
Yes, I've been talking with Wayne. But it's very easy to depend on
something that's resolve in another p2 repository. Analyzing the
dependencies (package and bundle requirements) reveals all this nicely.
But we also need to capture "compile" and/or "test-only" dependencies.
As I mentioned, it's possible to analyze a git repository directly
(but only the bundles and features they contain).
Java code can be analyzed for package imports. But there is also a
growing generation of projects in different languages and not using p2.
I certainly won't be doing that. I'm sure the ocean will boil and
hell will have frozen over before that's done...
Point (3) is probably the most controversial one. Why do we need to
bother with CQs at all if a project doesn't care?
Because Eclipse cares. Because when you come to Eclipse you know what
you're getting, what the license is, and that it's all be reviewed and
put through the meat grinder.
I believe that we are putting too much work onto the IP team
without ever asking ourselves if that is all really necessary.
It's not necessary to be an Eclipse project.
There is probably a significant number of projects which don't need
the full IP program.
The consumers are the ones who need it and can currently expect it...
This may be just guessing, though. But a logo-/branding-program could
help here. IP-approved releases would qualify for the "IP-approved"
logo. The PMI can make it easy to list/verify if a specific release
is IP approved.
I can guarantee that I will never get such a thing past the
committee. :-(
-Gunnar
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal
to the Eclipse Foundation. To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
