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. 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
