On 1/14/08, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> On 13-Jan-08, at 8:01 PM, Niall Pemberton wrote:
<snip/>
> >
> > The real debate is going on on legal-discuss - I asked specifically
> > about the NOTICE file generated for Commons Fileupload here:
> > http://apache.markmail.org/message/zsgfkulbut3bowqu
> >
> > that has only one response, but the other thread (which has hotted up
> > and has Roy involved) on whether they have to be in svn is here:
> > http://apache.markmail.org/message/gyvzsubx7ieg3swt
> >
> > ...and in that thread Roy seems to be saying that they should
> >
> > Personally seems like a fuss about nothing to me, but I would suggest
> > mavenites jump in and fight their corner before banning the
> > remote-resources-plugin becomes policy.
>
> It's not going to become ASF policy because no one but a PMC sets
> policy for their project.
>
> We vote on a tag which produces the binaries and in the process of the
> build the notice file is generated.
>
> I appreciate your concern, but worst case scenario is that the
> generate file goes on the tag as well. That's a tweak to the plugin if
> derived resources are not legally binding. Not a big deal. Roy did not
> say anything about banning anything. Roy just expects people to try
> and do things right and correct them if they are not.
>
> I glanced the thread and what it amounts to is an effort in herding
> cats. That's just what it's like here. We definitely don't need more
> policy, as without a backing tool to do it correctly then no one is
> ever going to do it right. If our tool is wrong then we can fix it. I
> can tell you from experience that knowledge about doing releases being
> passed on from release manager to release manager correctly over the
> years approaches zero. Just look at the discussion in that thread.
>
> The only chance of it being done correctly over time is to embody the
> policy in the tool that performs correctly, and anything can be
> corrected.
>
<snap/>
Yup.
> I mailed Roy to talk to him so I will have him tell me what is
> correct, I will explain what our tools do. He can tell me where our
> tool is hosed and then we can fix it.
>
<snip/>
That might be a reasonable segue into the operational side of things
and the practical difficulties in using the tool.
My first experiences produced less-than-desired results, some of that
is captured in my earlier comments on COMMONSSITE-21 [1] (it may be
possible to read through without following the pointer).
The fact that the content generated is a function of various artifacts
(primarily poms IIUC) in the repository(ies) has some tedious
side-effects.
For example, in the generated notice attached to that JIRA issue
(credits to Niall, IIRC) we get:
<notice-snippet>
This product includes/uses software(s) developed by 'an unknown organization'
- Unnamed - commons-beanutils:commons-beanutils:jar:1.7.0
- Unnamed - oro:oro:jar:2.0.8
</notice-snippet>
As a RM, that generates a queasy feeling. The specifics of this
generation are uninteresting (we know why beanutils shows up the way
it does, what it will take to fix it etc.).
Heres a very incomplete list of other "metadata" problems:
* The organization {name, uri} pairs are frequently inconsistent.
This results in vacuous groupings.
* Some of the URIs have expressions (see maven-jar-plugin v2.2 that
triggered this thread -- it has ${pom.artifactId.substring(8)}
percolating into the notice).
These are bad practices showing through, but the fact remains that if
any of these show up in the generated content, it could be a
significant detour to get that corrected the right way. The need to
beat other / dependency artifacts into shape becomes a hurdle.
IOW, while asymptotically the tool will gravitate to producing good
results as more of these things get fixed, ATM there are
above-mentioned difficulties. I am interested in knowing what thought
has gone into this, since others may have mulled over this for longer.
-Rahul
[1] http://issues.apache.org/jira/browse/COMMONSSITE-21
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
