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: pass (athena.apache.org: domain of niall.pemberton@gmail.com
 designates 209.85.146.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=KvffBEbqKKA9aSpdzTjxt09lXNt2GrryKj6QW2aiKH3LB4zA/ehGXEewfOlIEbw0NHTg2bP/grLjbTOldOwgAbQgNeDoDsu4RJoYrzXe9W2+C5qQaNTCkAcS5rZUyNsmm/PfduN/NFLjcsKAD7mLi3FSsHuXrqihZBjZmk1H4bM=
Message-ID: <55afdc850801091942v2230584s5196eb3dea2feb17@mail.gmail.com>
Date: Thu, 10 Jan 2008 03:42:14 +0000
From: "Niall Pemberton" <niall.pemberton@gmail.com>
To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Subject: Re: [IO] Planning IO 1.4 release
In-Reply-To: <55afdc850801091738w49b2ff0h9daefd9122de0142@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <55afdc850801051751r6c579650v18c86574884af01e@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>

On Jan 10, 2008 1:38 AM, Niall Pemberton <niall.pemberton@gmail.com> 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.

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.

Niall

> > >
> > > 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. 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.
>
> 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.
>
> > 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.
>
> > 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. 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. 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.
>
> 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