commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: [IO] Planning IO 1.4 release
Date Thu, 10 Jan 2008 19:52:41 GMT
Niall Pemberton wrote:
> On Jan 10, 2008 1:38 AM, Niall Pemberton <> wrote:
>> On Jan 10, 2008 12:25 AM, Dennis Lundberg <> wrote:
>>> Niall Pemberton wrote:
>>>> On Jan 9, 2008 11:01 PM, Niall Pemberton <>
>>>>> On Jan 9, 2008 10:16 PM, Dennis Lundberg <> wrote:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Jan 9, 2008 4:41 PM, Dennis Lundberg <>
>>>>>>>> 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:
>>>>>>> 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
>>>>>> 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
>>>>>> 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
>>>>>> there that recreates the -javadoc.jar and inserts the LICENSE.txt
>>>>>> NOTICE.txt files. That could probably be removed now.
>>>>>> But it just struck me - we've been going about this the wrong way!
>>>>>> plugins that we use (jar, javadoc, source) supports remote resources.
>>>>>> let us use that functionality instead of trying to create it ourselves.
>>>>>> It's dead simple really: we create an antrun execution, much like
>>>>>> one I made, that copies our *local* resources to the same place that
>>>>>> 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


Dennis Lundberg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message