Niall Pemberton wrote:
On Jan 10, 2008 12:25 AM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
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.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
