You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Thomas Recloux <th...@gmail.com> on 2005/02/03 07:48:05 UTC
Re: I18n site
> I wil try to use it on my project and post my feed back here.
I used it, I just add to set the required version of the maven yo
1.1-SNAPSHOT instead od 1.1.
It works fine for a single project but I had some problems with the
multiproject:site. I think that the children projects are overiding
the parent project's bundle.
An improvement could be the plugin not to 'escape' the properties, so
we could add bigger blocks in the properties files. Actually if you
need to insert a link, you must use three properties.
Could I retrieve the sources of the patch ?
Should I add this comments in jira or follow the thread in maven-dev ?
--
Thomas Recloux
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: I18n site
Posted by Brett Porter <br...@apache.org>.
It's pure Java, so the localization should be significantly easier.
There are a couple of approaches:
- for Maven 1.0.x, we could make a jelly wrapper that mimics the
existing functionality, and calls into the java plugin jar.
- for Maven 1.1.x, we can probably have the core load them directly
fairly easily, and add a mapping file to do the same goal mimicing.
The first steps will have to be to separate some of the jumbled
functionality (like report registration in xdoc instead of site, etc).
Another alternative is that xdoc stays as is and becomes deprecated, and
the new functionality is introduced into the site plugin as "v 2.0".
It is definitely more work - but in the long run it will be much much less.
Just thinking out loud at this point - I think right after alpha-2 is
released (2 weeks) is a good time to do this. It's up to you about how
much more work localizing m1 will take as to whether it is worth doing
it first... I thought it was basically done, so worth finishing first
and saving this work until later, but it is starting to appear to be the
opposite (especially with all the dom4j/jaxen problems hitting the site
in maven 1.1).
- Brett
Arnaud HERITIER wrote:
>...
>
>
>>Are you sure you wouldn't rather invest this effort into the
>>m2 localization? :)
>>
>>
>
>How could we investigate on this ?
>Is there some tests on how to integrate a m2 plugin in m1 ?
>
>Arnaud
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: I18n site
Posted by Arnaud HERITIER <ah...@gmail.com>.
...
>
> Are you sure you wouldn't rather invest this effort into the
> m2 localization? :)
How could we investigate on this ?
Is there some tests on how to integrate a m2 plugin in m1 ?
Arnaud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: I18n site
Posted by Brett Porter <br...@apache.org>.
If you have an enclosing tag, you probably want a method like:
{
get classloader
construct new classloader, add resource
set new classloader
invokeBody( output );
set old classloader back
}
Are you sure you wouldn't rather invest this effort into the m2
localization? :)
- Brett
Vincent Siveton wrote:
>Hello every body,
>
>Always about Jelly Fmt tag, Xdoc plugin and classloader, I am a bit confused
>by Maven 1.0.2.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: I18n site
Posted by Vincent Siveton <vi...@gmail.com>.
Hello every body,
Always about Jelly Fmt tag, Xdoc plugin and classloader, I am a bit confused
by Maven 1.0.2.
What is the difference between a defined Jelly Tag (extends BaseTagSupport)
and a closing tag defined in a plugin?
Please lets see a diff file between 2 plugin.jelly files:
* The first one uses Maven Tags defined in the jelly-tags Maven component. I
called them: <maven:grabClassLoader /> and <maven:unGrabClassLoader />
* The second one is the same code with a defined closing tag.
In a multiproject case, the first one produces the wanted value of the fmt
key and the other one produces ???myKey???.
My godfeeling is that I am not in the right classloader! Is the
MavenJellyContext not handling the same classloader between a defined jelly
tag and a closing tag? Maybe is it an interaction with others plugins?
Thanks a lot for your response!
Cheers,
Vincent
The following lines are from the GrabClassLoaderTag:
/*
* @see
org.apache.commons.jelly.Tag#doTag(org.apache.commons.jelly.XMLOutput)
*/
public void doTag(XMLOutput arg0) throws MissingAttributeException,
JellyTagException {
if (getMavenContext() == null) {
throw new JellyTagException("The current MavenContext is
null!");
}
checkAttribute(this.resource, "include");
ForeheadClassLoader currentClassLoader = null;
try {
currentClassLoader = (ForeheadClassLoader)
getMavenContext().getClassLoader();
} catch (ClassCastException e) {
throw new JellyTagException("The current classloader in the
MavenContext is not an instance of ForeheadClassLoader");
}
if (currentClassLoader == null) {
throw new JellyTagException("No classloader found in the current
MavenContext");
}
try {
File f = new File(this.resource);
currentClassLoader.addURL(f.toURL());
} catch (MalformedURLException e) {
throw new JellyTagException("The directory to include specified
by " + getResource() + " is malformed");
}
ForeheadClassLoader newClassLoader = new
ForeheadClassLoader(currentClassLoader, currentClassLoader.getName() +
"_tmp");
getMavenContext().setClassLoader(newClassLoader);
}
> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: Sunday, May 01, 2005 8:32 AM
> To: Maven Developers List
> Cc: 'Brett Porter'; 'Arnaud HERITIER'
> Subject: Re: I18n site
>
> Ah, I see. It was working inside the reactor for me, but not when you
> run a few projects. Because the classloader accumulates, you gather up
> other stuff, so the result never changes.
>
> You can develop a tag that does the following:
> - grab the existing classloader
> - create a new classloader that inherits the current one
> - add URL to the classloader
>
> and another tag that returns the old classloader. You'll see some of the
> java plugins (Eg hibernate) do something similar.
>
> If you need a hand, let me know... I can do it pretty easily.
>
> You mentioned your work was backwards compatible too... if so, I'm all
> for dropping it straight into the xdoc plugin as is and releasing it as
> 1.9
>
> - Brett
>
> Vincent Siveton wrote:
>
> >Hi Brett,
> >
> >
> >
> >>Sorry for the really long time it took to respond.
> >>
> >>
> >
> >
> >No problem :o)
> >
> >
> >
> >
> >>I didn't feel confident about copying files into the plugin cache
> >>directory, so I investigated it more. What I suggest is placing the
> >>bundles under the project directory somewhere - perhaps xdocs, or
> >>perhaps a new directory?
> >>
> >>
> >
> >
> >Me too! But it is the only solution that I found to solve the
> multiproject
> >limitation.
> >
> >
> >
> >
> >>Anyway, if it were xdocs, the following will work:
> >>
> >> <u:file var="f" name="${basedir}/xdocs" />
> >> <j:set
> >>var="dummy">${context.getClassLoader().addURL(f.toURL())}</j:set>
> >>
> >>
> >
> >
> >Already tried in the past: it seems that it doesn't work with a
> multiproject
> >goal... In this case, fmt always produces this following result:
> >???myKey???
> >But works fine for a single project. Any clues?
> >It is a known issue for maven:reactor?
> >
> >Regards,
> >
> >Vincent
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
Re: I18n site
Posted by Brett Porter <br...@apache.org>.
Ah, I see. It was working inside the reactor for me, but not when you
run a few projects. Because the classloader accumulates, you gather up
other stuff, so the result never changes.
You can develop a tag that does the following:
- grab the existing classloader
- create a new classloader that inherits the current one
- add URL to the classloader
and another tag that returns the old classloader. You'll see some of the
java plugins (Eg hibernate) do something similar.
If you need a hand, let me know... I can do it pretty easily.
You mentioned your work was backwards compatible too... if so, I'm all
for dropping it straight into the xdoc plugin as is and releasing it as 1.9
- Brett
Vincent Siveton wrote:
>Hi Brett,
>
>
>
>>Sorry for the really long time it took to respond.
>>
>>
>
>
>No problem :o)
>
>
>
>
>>I didn't feel confident about copying files into the plugin cache
>>directory, so I investigated it more. What I suggest is placing the
>>bundles under the project directory somewhere - perhaps xdocs, or
>>perhaps a new directory?
>>
>>
>
>
>Me too! But it is the only solution that I found to solve the multiproject
>limitation.
>
>
>
>
>>Anyway, if it were xdocs, the following will work:
>>
>> <u:file var="f" name="${basedir}/xdocs" />
>> <j:set
>>var="dummy">${context.getClassLoader().addURL(f.toURL())}</j:set>
>>
>>
>
>
>Already tried in the past: it seems that it doesn't work with a multiproject
>goal... In this case, fmt always produces this following result:
>???myKey???
>But works fine for a single project. Any clues?
>It is a known issue for maven:reactor?
>
>Regards,
>
>Vincent
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: I18n site
Posted by Vincent Siveton <vi...@gmail.com>.
Hi Brett,
> Sorry for the really long time it took to respond.
No problem :o)
> I didn't feel confident about copying files into the plugin cache
> directory, so I investigated it more. What I suggest is placing the
> bundles under the project directory somewhere - perhaps xdocs, or
> perhaps a new directory?
Me too! But it is the only solution that I found to solve the multiproject
limitation.
> Anyway, if it were xdocs, the following will work:
>
> <u:file var="f" name="${basedir}/xdocs" />
> <j:set
> var="dummy">${context.getClassLoader().addURL(f.toURL())}</j:set>
Already tried in the past: it seems that it doesn't work with a multiproject
goal... In this case, fmt always produces this following result:
???myKey???
But works fine for a single project. Any clues?
It is a known issue for maven:reactor?
Regards,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: I18n site
Posted by Brett Porter <br...@gmail.com>.
Hi Vincent,
Sorry for the really long time it took to respond.
I didn't feel confident about copying files into the plugin cache
directory, so I investigated it more. What I suggest is placing the
bundles under the project directory somewhere - perhaps xdocs, or
perhaps a new directory?
Anyway, if it were xdocs, the following will work:
<u:file var="f" name="${basedir}/xdocs" />
<j:set var="dummy">${context.getClassLoader().addURL(f.toURL())}</j:set>
This will add ${basedir}/xdocs to the current classloader, making any
properties files under "xdocs" available to the fmt: tags.
Is this enough for you to continue now?
I suggest we add a tag to maven-jelly-tags for 1.1 that does this to
keep it portable.
Cheers,
Brett
On 2/14/05, Siveton Vincent <vi...@gmail.com> wrote:
> Hi Brett,
>
> Well, according my experience, we also have these problems: there is
> classpath for bundles and another one for multiproject (maven reactor).
> Please check this mail:
> http://www.mail-archive.com/dev@maven.apache.org/msg21646.html
> Actually, I have no clue about it, what about you?
>
> Another problem is the translation of the report generated.
> In fact, I think that the language (default one and supported language)
> should become a standalone part of the POM definition (sourceforge.net
> provides translation support as project definition).
> Thus, all plugins should provide integrated solutions for i18n.
>
> Cheers,
>
> Vincent
>
> -----Message d'origine-----
> De : Brett Porter [mailto:brett.porter@gmail.com]
> Envoyé : 14 février 2005 07:06
> À : Maven Users List; Arnaud HERITIER
> Objet : Re: I18n site
>
> Hi,
>
> Is any work being undertaken on this?
>
> I'm not actively doing anything to xdoc at the moment, and it should be safe
> to apply the changes to HEAD. Currently the only known problems is that
> anything inside <![CDATA[ ... ]]> is being lost in translation (ie most
> <source/> fragments).
>
> - Brett
>
> On Thu, 3 Feb 2005 11:47:15 +0100, Arnaud HERITIER <ah...@gmail.com>
> wrote:
> > > I used it, I just add to set the required version of the maven yo
> > > 1.1-SNAPSHOT instead od 1.1.
> > >
> > > It works fine for a single project but I had some problems with the
> > > multiproject:site. I think that the children projects are overiding
> > > the parent project's bundle.
> > >
> > > An improvement could be the plugin not to 'escape' the properties,
> > > so we could add bigger blocks in the properties files. Actually if
> > > you need to insert a link, you must use three properties.
> > >
> > > Could I retrieve the sources of the patch ?
> >
> > Vincent gave us the full project but not a diff.
> > Actually Brett is working on the xdoc plugin so you must be careful
> > you must merge changes done in the plugin done since Vincent's
> > checkout.
> >
> > A good think was :
> > 1) checkout the plugin at the date Vincent provided its release.
> > 2) override the plugin with Vincent's one
> > 3) Generate a diff (+ new files) for Vincent's changes (attach this
> > patch to the issue)
> > 4) Update the plugin from SVN
> > 5) apply the patch generated in 3
> > 6) Make your changes
> > 7) Generate a new patch
> >
> > >
> > > Should I add this comments in jira or follow the thread in maven-dev ?
> >
> > We can talk about functionalities on the users list to share it with
> > everybody but for technical things we can use Jira.
> >
> > Arnaud
> >
> > > --
> > > Thomas Recloux
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: I18n site
Posted by Arnaud HERITIER <ah...@gmail.com>.
Waiting for a POM modification, these informations (default and
supported langages) can be defined as properties (It's what you're
doing actually).
I don't know if we will be able to change the POM in 1.1 ?
Arnaud
On Mon, 14 Feb 2005 07:36:33 -0500, Siveton Vincent
<vi...@gmail.com> wrote:
> Hi Brett,
>
> Well, according my experience, we also have these problems: there is
> classpath for bundles and another one for multiproject (maven reactor).
> Please check this mail:
> http://www.mail-archive.com/dev@maven.apache.org/msg21646.html
> Actually, I have no clue about it, what about you?
>
> Another problem is the translation of the report generated.
> In fact, I think that the language (default one and supported language)
> should become a standalone part of the POM definition (sourceforge.net
> provides translation support as project definition).
> Thus, all plugins should provide integrated solutions for i18n.
>
> Cheers,
>
> Vincent
>
> -----Message d'origine-----
> De : Brett Porter [mailto:brett.porter@gmail.com]
> Envoyé : 14 février 2005 07:06
> À : Maven Users List; Arnaud HERITIER
> Objet : Re: I18n site
>
> Hi,
>
> Is any work being undertaken on this?
>
> I'm not actively doing anything to xdoc at the moment, and it should be safe
> to apply the changes to HEAD. Currently the only known problems is that
> anything inside <![CDATA[ ... ]]> is being lost in translation (ie most
> <source/> fragments).
>
> - Brett
>
> On Thu, 3 Feb 2005 11:47:15 +0100, Arnaud HERITIER <ah...@gmail.com>
> wrote:
> > > I used it, I just add to set the required version of the maven yo
> > > 1.1-SNAPSHOT instead od 1.1.
> > >
> > > It works fine for a single project but I had some problems with the
> > > multiproject:site. I think that the children projects are overiding
> > > the parent project's bundle.
> > >
> > > An improvement could be the plugin not to 'escape' the properties,
> > > so we could add bigger blocks in the properties files. Actually if
> > > you need to insert a link, you must use three properties.
> > >
> > > Could I retrieve the sources of the patch ?
> >
> > Vincent gave us the full project but not a diff.
> > Actually Brett is working on the xdoc plugin so you must be careful
> > you must merge changes done in the plugin done since Vincent's
> > checkout.
> >
> > A good think was :
> > 1) checkout the plugin at the date Vincent provided its release.
> > 2) override the plugin with Vincent's one
> > 3) Generate a diff (+ new files) for Vincent's changes (attach this
> > patch to the issue)
> > 4) Update the plugin from SVN
> > 5) apply the patch generated in 3
> > 6) Make your changes
> > 7) Generate a new patch
> >
> > >
> > > Should I add this comments in jira or follow the thread in maven-dev ?
> >
> > We can talk about functionalities on the users list to share it with
> > everybody but for technical things we can use Jira.
> >
> > Arnaud
> >
> > > --
> > > Thomas Recloux
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: I18n site
Posted by Siveton Vincent <vi...@gmail.com>.
Hi Brett,
Well, according my experience, we also have these problems: there is
classpath for bundles and another one for multiproject (maven reactor).
Please check this mail:
http://www.mail-archive.com/dev@maven.apache.org/msg21646.html
Actually, I have no clue about it, what about you?
Another problem is the translation of the report generated.
In fact, I think that the language (default one and supported language)
should become a standalone part of the POM definition (sourceforge.net
provides translation support as project definition).
Thus, all plugins should provide integrated solutions for i18n.
Cheers,
Vincent
-----Message d'origine-----
De : Brett Porter [mailto:brett.porter@gmail.com]
Envoyé : 14 février 2005 07:06
À : Maven Users List; Arnaud HERITIER
Objet : Re: I18n site
Hi,
Is any work being undertaken on this?
I'm not actively doing anything to xdoc at the moment, and it should be safe
to apply the changes to HEAD. Currently the only known problems is that
anything inside <![CDATA[ ... ]]> is being lost in translation (ie most
<source/> fragments).
- Brett
On Thu, 3 Feb 2005 11:47:15 +0100, Arnaud HERITIER <ah...@gmail.com>
wrote:
> > I used it, I just add to set the required version of the maven yo
> > 1.1-SNAPSHOT instead od 1.1.
> >
> > It works fine for a single project but I had some problems with the
> > multiproject:site. I think that the children projects are overiding
> > the parent project's bundle.
> >
> > An improvement could be the plugin not to 'escape' the properties,
> > so we could add bigger blocks in the properties files. Actually if
> > you need to insert a link, you must use three properties.
> >
> > Could I retrieve the sources of the patch ?
>
> Vincent gave us the full project but not a diff.
> Actually Brett is working on the xdoc plugin so you must be careful
> you must merge changes done in the plugin done since Vincent's
> checkout.
>
> A good think was :
> 1) checkout the plugin at the date Vincent provided its release.
> 2) override the plugin with Vincent's one
> 3) Generate a diff (+ new files) for Vincent's changes (attach this
> patch to the issue)
> 4) Update the plugin from SVN
> 5) apply the patch generated in 3
> 6) Make your changes
> 7) Generate a new patch
>
> >
> > Should I add this comments in jira or follow the thread in maven-dev ?
>
> We can talk about functionalities on the users list to share it with
> everybody but for technical things we can use Jira.
>
> Arnaud
>
> > --
> > Thomas Recloux
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: I18n site
Posted by Brett Porter <br...@gmail.com>.
Hi,
Is any work being undertaken on this?
I'm not actively doing anything to xdoc at the moment, and it should
be safe to apply the changes to HEAD. Currently the only known
problems is that anything inside <![CDATA[ ... ]]> is being lost in
translation (ie most <source/> fragments).
- Brett
On Thu, 3 Feb 2005 11:47:15 +0100, Arnaud HERITIER <ah...@gmail.com> wrote:
> > I used it, I just add to set the required version of the maven yo
> > 1.1-SNAPSHOT instead od 1.1.
> >
> > It works fine for a single project but I had some problems with the
> > multiproject:site. I think that the children projects are overiding
> > the parent project's bundle.
> >
> > An improvement could be the plugin not to 'escape' the properties, so
> > we could add bigger blocks in the properties files. Actually if you
> > need to insert a link, you must use three properties.
> >
> > Could I retrieve the sources of the patch ?
>
> Vincent gave us the full project but not a diff.
> Actually Brett is working on the xdoc plugin so you must be careful
> you must merge changes done in the plugin done since Vincent's
> checkout.
>
> A good think was :
> 1) checkout the plugin at the date Vincent provided its release.
> 2) override the plugin with Vincent's one
> 3) Generate a diff (+ new files) for Vincent's changes (attach this
> patch to the issue)
> 4) Update the plugin from SVN
> 5) apply the patch generated in 3
> 6) Make your changes
> 7) Generate a new patch
>
> >
> > Should I add this comments in jira or follow the thread in maven-dev ?
>
> We can talk about functionalities on the users list to share it with
> everybody but for technical things we can use Jira.
>
> Arnaud
>
> > --
> > Thomas Recloux
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: I18n site
Posted by Arnaud HERITIER <ah...@gmail.com>.
> I used it, I just add to set the required version of the maven yo
> 1.1-SNAPSHOT instead od 1.1.
>
> It works fine for a single project but I had some problems with the
> multiproject:site. I think that the children projects are overiding
> the parent project's bundle.
>
> An improvement could be the plugin not to 'escape' the properties, so
> we could add bigger blocks in the properties files. Actually if you
> need to insert a link, you must use three properties.
>
> Could I retrieve the sources of the patch ?
Vincent gave us the full project but not a diff.
Actually Brett is working on the xdoc plugin so you must be careful
you must merge changes done in the plugin done since Vincent's
checkout.
A good think was :
1) checkout the plugin at the date Vincent provided its release.
2) override the plugin with Vincent's one
3) Generate a diff (+ new files) for Vincent's changes (attach this
patch to the issue)
4) Update the plugin from SVN
5) apply the patch generated in 3
6) Make your changes
7) Generate a new patch
>
> Should I add this comments in jira or follow the thread in maven-dev ?
We can talk about functionalities on the users list to share it with
everybody but for technical things we can use Jira.
Arnaud
> --
> Thomas Recloux
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org