Niall Pemberton wrote:
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).
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
