commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: [IO] Planning IO 1.4 release
Date Wed, 09 Jan 2008 23:16:10 GMT
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).

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


Mime
View raw message