You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Vincent Siveton <vi...@gmail.com> on 2005/05/01 13:00:51 UTC
RE: I18n site
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...@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