commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: [IO] Planning IO 1.4 release
Date Thu, 10 Jan 2008 00:25:18 GMT
Niall Pemberton wrote:
> On Jan 9, 2008 11:01 PM, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>> On Jan 9, 2008 10:16 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>>> Niall Pemberton wrote:
>>>> On Jan 9, 2008 4:41 PM, Dennis Lundberg <dennisl@apache.org> 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.

> 
> Niall
> 
>>>          <plugin>
>>>            <!--
>>>              - Copy LICENSE.txt and NOTICE.txt so that they are included
>>>              - in distribution jar files.
>>>              -->
>>>            <groupId>org.apache.maven.plugins</groupId>
>>>            <artifactId>maven-antrun-plugin</artifactId>
>>>            <version>1.1</version>
>>>            <executions>
>>>              <execution>
>>>                <id>local.resources</id>
>>>                <phase>generate-sources</phase>
>>>                <goals>
>>>                  <goal>run</goal>
>>>                </goals>
>>>                <configuration>
>>>                  <tasks>
>>>                    <copy
>>> todir="${project.build.directory}/maven-shared-archive-resources/META-INF">
>>>                      <fileset dir="${basedir}">
>>>                        <include name="LICENSE.txt" />
>>>                        <include name="NOTICE.txt" />
>>>                      </fileset>
>>>                    </copy>
>>>                  </tasks>
>>>                </configuration>
>>>              </execution>
>>>            </executions>
>>>          </plugin>
>>>
>>> I haven't tried this for real, but will play around with it and see if
>>> it would work.
>> I tried it and it didn't seem to work, but I could be doing something
>> wrong. My guess is that the javadoc plugin only collects defined
>> "resources" that are in that directory which is why the antrun soln
>> didn't work.

You are right. I have experimented a bit and studied the source code for 
the plugins. What maven-remote-resources-plugin does is inject the 
remotely fetched resources into the resources in the (in memory) pom. So 
what I proposed above will not work.

The antrun that I put in svn is working fine though for the javadoc-jar. 
Commons-io has some other antrun executions, as I mentioned before, 
which makes the sources jar work. It's a hack, but it seems to do its 
job. I will remove (from svn) the now superfluous antrun that rejars the 
-javadoc jar file.

>> On the issue of whether the other antrun solution should go in the
>> commons-parent pom - then I think the remote resources argument was
>> lost at this point and we should have a solution that works for the
>> whole of commons and therefore it should go in commons-parent -
>> otherwise we need to duplicate that solution in every component which
>> doesn't use remote resources. That kind of thing is going to put
>> people off making the switch to m2, whereas we should be trying to
>> make it as easy, issue free as possible.

My standpoint on this is that we should not put everything into 
commons-parent *right away*. The fact that we are still learning m2, 
supports this. First we try something new out in one component. If that 
works out well (after a full release cycle) then we can start do discuss 
moving those bits into commons-parent.

I'm trying my best here to help with the migration to m2. If we are 
going to migrate successfully we need to take many small steps. 
Sometimes we must also be able to take a leap and adjust our file-names 
(just an example) to make them work *together* with m2 instead of the 
opposite. We must dare to let go of the past.

Easy and issue free sound good to me.

>>
>> Niall
>>
>>
>>> WDYT?
>>>
>>>> Niall
>>>>
>>>
>>> <snip/>
>>>
>>> --
>>>
>>> Dennis Lundberg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message