Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <478675C8.80700@apache.org>
Date: Thu, 10 Jan 2008 20:45:12 +0100
From: Dennis Lundberg <dennisl@apache.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Jakarta Commons Developers List <dev@commons.apache.org>
Subject: Re: [IO] Planning IO 1.4 release
References: <55afdc850801051751r6c579650v18c86574884af01e@mail.gmail.com>
	 <55afdc850801090104h75d4ab28n375d5b11fbafcf4a@mail.gmail.com>
	 <31cc37360801090124r30517297u5455d268c06f1a87@mail.gmail.com>
	 <55afdc850801090639u7a3f0f42rdf1b0b4db7187297@mail.gmail.com>
	 <4784F937.3070609@apache.org>
	 <55afdc850801091339v1d69c3bfk462a59f6cbf831a2@mail.gmail.com>
	 <478547A2.7020602@apache.org>
	 <55afdc850801091501n6f0689danfde4fd222553fcbe@mail.gmail.com>
	 <55afdc850801091516y628199a6qf42a967cb32039a8@mail.gmail.com>
	 <478565EE.6070708@apache.org>
 <55afdc850801091738w49b2ff0h9daefd9122de0142@mail.gmail.com>
In-Reply-To: <55afdc850801091738w49b2ff0h9daefd9122de0142@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Niall Pemberton wrote:
> On Jan 10, 2008 12:25 AM, Dennis Lundberg <dennisl@apache.org> wrote:
>> 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.
> 
> 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.

:-)

>>> 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.
> 
> But thats not what happened with remote-resources which you put into
> commons-parent - which caused duplicate LICENSE and NOTICE files and
> garbage in the NOTICE file.

Right, that was a bad thing to do, and it was me who did it. Apart from 
that it's an excellent example of what *not* to do ;-) Messing around 
with the parent until something is tried and tested can lead to unwanted 
effects.

> I've tested this change on commons Chain,
> both with the normal setup and by deleting the NOTICE/LICENSE file and
> configuring the remote-resources plugin. Both worked OK. I think we
> should put it in - if down the road a problem appears then fixing it
> and doing a release is not that big a deal.

It's good that it works for both setups.

> So at the moment three people (Jochen, Rahul and myself) think it
> should go in and one (Dennis) is against - I'll leave it a while for
> other opinions, but if the majority agree then I'll commit it.

That's what votes are for.

>> I'm trying my best here to help with the migration to m2. If we are
> 
> Despite all recent argument, it is appreciated and I hope I haven't
> upset you too much.

I just feel that there is sooo much discussion necessary to pull 
something off here in commons. We have a saying in Sweden that sums it 
up, but I'm not sure how it works after translation. It goes something 
like this:

   "Much talk, but no work"

I wish that some of the energy that goes into the discussions would go 
into actual coding instead...

>> 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.
> 
> I assume your talking about removing the ".txt" extensions from the
> NOTICE and LICENSE files. Firstly at least some of us think its more
> (windows) user-friendly to keep them. Secondly using Validator as an
> example - it currently has three working build systems - ant, m1 and
> m2 - so renaming the files to make m2 more easily means fixing the ant
> and m1 builds as well - and correcting at least one other build is
> going to apply to most other components as well, unless we wait until
> all are on m2.

That is a sign that it's time to make a jump, in this case drop support 
for at least one of the three build systems. IMO if a component switches 
to m2 it's time to drop the m1 support in that component. My comment was 
meant generally, the file extensions was just an illustrative example.

> I think we need working m2 builds to encourage
> components to make the switch (and I've done quite a bit to help with
> that) and so a less invassive solution is needed which I proposed in
> MRRESOURCES-31. Its not maven were working against with this issue -
> its the apache-jar-resource-bundle.

Again, if you have to jump through too many hoops to make it happen, 
it's sign that something is wrong. We're bending over backwards to 
maintain one-to-many build systems.

> I believe that if the maven team
> does MRRESOURCES-31 and the dependencies meta-data (i.e. poms) get
> fixed so the contents of the NOTICE file are good - then I think you'd
> have a better chance of persuading commons to adopt remote-resources.
> It doesn't then leave much argument against using it - or at least
> making it available in commons parent.

The metadata is the most serious flaw with using 
remote-resources-plugin, because it is difficult for us to fix. But for 
components with zero dependencies, which is rather common (!) here in 
commons, using the remote-resources-plugin should work fine.

> Niall
> 
>> Easy and issue free sound good to me.
>>
>>>> Niall
>>>>
>>>>
>>>>> WDYT?
>>>>>
>>>>>> Niall
>>>>>>
>>>>> <snip/>
> 
> ---------------------------------------------------------------------
> 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