On 10/16/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
On 10/16/06, Dion Gillard <[EMAIL PROTECTED]> wrote:
> I'm -1 on it as it stands, as I have a few problems with the proposed POM:
Ok, you have just convinced me that it is better to make the next
release of commons-fileupload without waiting for the availability of
the commons-parent POM. :-(
I haven't got any objections against you arguments, but it's nasty
asking several times whether "we are ready" and now getting blocking
votes again.
I'm sorry I missed the previous votes, but I can easily change my vote
once I understand the issues better.
> - remove [EMAIL PROTECTED] as the continuum email address and make it
> [email protected]
Done.
> - why do we need a dummy repository?
The comment says it: It should prevent accidental deploys to the
Apache repositories, which are configured in the parent POM (the
Apache root POM). The idea is that I have to use the -Prc or -Prelease
command line switches for deploying. It wasn't my idea, but I like it.
Ok, that makes sense. An updated comment about what switches are
needed from the command like to override it would work for me.
> - what value does the scm section provide to inheriters?
None, you are right. I have removed it. But the same holds true for
the issueManagement section. Removed as well.
> - When building distributions the notice.txt is placed in the top
> level of the generated archive - is it possible to get this in there
> somehow too?
You are referring to the distribution archives, not to the jar files,
are you? They are generated by the assembly plugin and I am unaware of
any possibility to configure that from a parent POM.
Me either, hence the question. If it's not possible, fair enough.
> - Is it possible to get the m2 bug fixed which forces us to use a
> whole slew of ant xml to copy over various resources?
>
> Any hope of getting these answered?
1.) It isn't clear that the point is even considered a bug. Copying
the whole "source
directory" (which is the base directory) may be considered a
feature by some.
2.) We need to get the fix into the source plugins SVN version. From
my experience,
that can easily take some months.
3.) We need to have a released version of the source plugin containing
the fix. That will
easily take some months more.
In other words, I don't believe it's reasonable. Besides, I can't see
what problems you have with the current solution. It does exactly what
it's supposed to: Makes sure that the LICENSE.txt and NOTICE.txt files
are part of the generated jar files.
If it's not likely to be 'fixed' and soon, I'm happy with what we've
got. I would have preferred the cleaner solution, but it doesn't seem
feasible.
That makes my vote a +0 now you've clarified that for me.
Jochen
--
My wife Mary and I have been married for forty-seven years and not
once have we had an argument serious enough to consider divorce;
murder, yes, but divorce, never.
(Jack Benny)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://www.multitask.com.au/people/dion/
Rule of Acquisition #91: Hear all, trust nothing.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
