Niall Pemberton wrote:
On Jan 10, 2008 1:38 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On Jan 10, 2008 12:25 AM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Niall Pemberton wrote:
On Jan 9, 2008 11:01 PM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On Jan 9, 2008 10:16 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Niall Pemberton wrote:
On Jan 9, 2008 4:41 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Niall Pemberton wrote:
OK so now were down to agreeing the exception in IO-77 - once thats
done I can cut an RC.
I'm starting to think that with the javadoc.jar Notice/License issue I
may cut the rc with m1, since m2 seems to painful ATM (I've spent far
too much time battling with m2 recently).
Problem solved in r610444:
https://svn.apache.org/viewvc?view=rev&revision=610444
Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
No, not in my opinion. We've agreed to disagree on which way to go with
this. There are two option, each with its merits and flaws.
A) Use maven-remote-resources-plugin
B) Keep manually edited files in SVN and copy them manually to the
correct places
If supporting one of these (A) isn't allowed in the parent pom, then why
should the other (B) be supported?
Anyway, on to the problem at hand here. I just found another antrun
execution in IO:s pom, in the release profile. There's some code in
there that recreates the -javadoc.jar and inserts the LICENSE.txt and
NOTICE.txt files. That could probably be removed now.
But it just struck me - we've been going about this the wrong way! The
plugins that we use (jar, javadoc, source) supports remote resources. So
let us use that functionality instead of trying to create it ourselves.
It's dead simple really: we create an antrun execution, much like the
one I made, that copies our *local* resources to the same place that the
remote-resources-plugin copies its resources to.
Also because supporting (B) doesn't prevent (A) - whereas the other
way, supporting (A) screws up (B).
It seems that we keep misunderstanding each other. The last thing I
proposed to support (A) was to add maven-remote-resources-plugin to
pluginManagement. This makes sure that all projects that inherits from
commons-parent and *uses* maven-remote-resources-plugin, will use the
same version of said plugin. Nothing more. So nothing in that prevents
(B) from working.
I'm all for solutions that can support one approach, as long as it
doesn't prevent other approaches.
Fair enough, my mis-understanding - I thought you were talking about
the whole remote-resources config rather than just the version in
plugin management. To be honest the main reason I didn't want to put
it back at that time was that it was during the vote for
commons-parent-6 and I didn't want it held up for something that I
believe we had decided not to use. I guess the fact that I screwed up
that release makes it quite funny.
OK I just checked out the fileupload release when Jochen has used that
plugin (via commons-parent-5) - so if people are going to use it we
should put the version in the plugin management so that the builds
re-createable. As an additional note we need to upgrade the javadoc
plugin version in commons=parent as it requires 2.3 to include the
Notice/License from remote resources.
+1 to both those changes.
Niall
<snip/>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
