On Jan 9, 2008 11:01 PM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
>
> On Jan 9, 2008 10:16 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> > Niall Pemberton wrote:
> > > On Jan 9, 2008 4:41 PM, Dennis Lundberg <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
