Re: Managing Different Java Versions
> I believe Stephen answered (1) for me quite elegantly. It would help > tremendously if his explanation were documented on the introduction page. > I'm not sure if sniffer solves (2) which really was my original intent > because I had already solved (1) by other means. Eric, if you file a ticket supplying exactly what text you want added (and specify to what page and where on that page) I will make sure it will get committed. You don't have to provide a patch (as you say you don't know how to do that), but you could just type the text in the ticket itself. The key here is to file a jira ticket. Nothing will happen from a mail thread. /Anders > > - Eric >> >> Wayne >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Tomcat Plugin] WebAppSourceDirectory Configuration?
Hello,
Why not simply put your resources in src/main/resources and load it
with Thread.currentThread().getContextClassLoader().getResourceAsStream(
path in classloader ) ?
2011/10/11 Ole Ersoy :
> Maybe if i explain what I'm trying to do, it will make more sense. I have a
> maven webapp project. I'm running it with:
>
> mvn tomcat:run
>
> When I run the webapp I would like to load resources from
> "WEB-INF/resources/...". When running a webapp in a standalone container
> "WEB-INF" is located in the "root" folder. However because I'm using maven
> to run the webapp, the "WEB-INF" folder is located under "src/main/webapp".
> Therefore if I want to test resource loading I need to add
> "src/main/webapp" to the path of the resource when running with:
> mvn tomcat:run.
>
> So for example running with "mvn tomcat:run" I have to load myresource.xml
> like this:
> application.load("src/main/webapp/WEB-INF/resources/myresource.xml");
>
> However when deploying in a standalone container the same resource would be
> loaded like this:
> application.load("WEB-INF/resources/theresource.xml");
>
> I'm trying to avoid having to change my application configuration for
> testing in a standalone container and testing with:
> mvn tomcat:run
>
> Does that make sense?
>
> Thanks,
> - Ole
>
>
> On 10/10/2011 04:26 PM, Olivier Lamy wrote:
>>
>> 2011/10/10 Ole Ersoy:
>>>
>>> I'm running the tomcat plugin configured as follows:
>>>
>
> org.codehaus.mojo
> tomcat-maven-plugin
>
>
> ${basedir}/src/main/webapp
>
>
>>>
>>> If I run the following line from a servlet the application is running:
>>> logger.trace("The current root directory is: {} ", new
>>> File("").getAbsolutePath());
>>>
>>> I would expect to see "The current root directory is:
>>> ${basedir}/src/main/webapp". However the result is:
>>> "The current root directory is: ${basedir}". In other words it seems the
>>> configuration has not taken effect.
>>
>> you should read current root webapp directory in the servlet container.
>>
>> this means if you go with your browser to http://localhost:${port}/
>> you will see files from this directory.
>>
>>>
>>> Thoughts? TIA,
>>> - Ole
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
--
Olivier Lamy
Talend : http://talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
AW: Problems with MAVEN's-ANT on OpenVMS
Thank you Barrie, thank you Wayne for your excellent articles. Now there is hope to get maven and ant build axis2 and maven and our own stuff on OpenVMS. The issues we are faced with are so many fold: And to complicate things even more. We sit behind firewalls and maven and ant with a to build i.e.Axis2, needs to be set with proper proxy info including http.auth.preference=Basic, not supported straight by Ant or maven but needs to go as a hint to our Microsoft proxy server to not start negotiating authentication schemas unable to be handled by the client calling. We have a working ant version of Ant, that is to say, by a bash shell script we launch our own AntClassLoader which creates an Authenticator to pass username and password and then calls the real AntLoader;;; BTW: Username and Password for the proxy server is never picked up by default from JAVA args as said in documents at various places. We have investigated Ant code for that. It is picked up by ant code only if you pass the --diagnostics switch to Ant and makes people think that all is fine, but in reality for a get task Ant does not pick proxy info under normal operation. This circumstance alone has made us work for some days. Also to be honest to Ant, it might be a Java JVM or java.net problem. Which org has to deal with such issues? Which org should fix it once for ever? Or who has to deal with such issues? The Ant-, or Maven-, or Java- or any of the mayn thousand jar-developers. We like to setup JAVA Arguments like -Dhttp.proxy.User=name -Dhttp.proxy.Password=xxx. So all is fine if we pass this as Ant arguments from inside a build.xml. BUT we do not like to change the ant build.xml files for each product like axis2 or maven. And we do not like to modify each maven pom for the same reason. We prefer a more central place. This is the case for maven with its settings.xml (except http.auth.preference=Basic is not foreseen by maven). It is always the same: what is used where and when and under which circumstances ?! Question: Given mavens settings.xml has the proxy info's does maven tell ant about this proxy information? If yes, where in code and how? Question: how does maven get best informed about the preferred authentication schemas to be used by the proxy server i.e. -Dhttp.auth.preference=Basic as described by the ORACLE documentation for JAVA and at many other places. Question: If ant is first and picks up and works would you expect for maven that ant tells maven about proxy info to be used? BTW: thanks for the pointers to the books. BTW: I took the latest sources of nexus down to my Vista PC. Tried to build it as I do with maven and axis2 and it failed! BTW: Then I took the latest binary version of a nexus-webapp.war down to my OpenVMS, I untared it on OpenVMS as we do with Axis2 or maven. It fails during startup on Tomcat and Java 6.0. Many things get up as one can see in tomcat logs attached as text file; but it fails. I did so because Wayne Fay said to work with nexus simplifies much of this repository and cache management. And I beleave you. And I like the idea very much and was reading a lot about nexus and repositories immediately. But in reality we have now one more product on OpenVMS which we need to make work first; where ever the problem is. Is it JAVA from HP? or any of the jar files issuing a shell script? or the use of exported environment variable of which bash under OpenVMS does not know anything by default? It is a tedious process to make such complex environments work; Josef -Ursprüngliche Nachricht- Von: Barrie Treloar [mailto:baerr...@gmail.com] Gesendet: Mittwoch, 5. Oktober 2011 00:45 An: Maven Users List Betreff: Re: Problems with MAVEN's-ANT on OpenVMS On Wed, Oct 5, 2011 at 3:43 AM, Wayne Fay wrote: >> May I ask you a favor and lead me to a document describing how we can make >> maven using our own ant 1.7.1, >> as we had changes in ANT 1.7.1 specifically for OpenVMS, those catching >> logical, and generating a temporary >> file where all the many hundred arguments being passed today to JAVA / JVM >> are stored in. > > I already told you what to do but here are the complete steps: Plus, did you try google? http://www.google.com/search?q=maven+ant+plugin+change+version+of+ant Some of the steps that Wayne has kindly outlined are not particular to your problem. They are the knowledge you need to run Maven effectively at your company. I highly recommend that you read the freely available books at http://maven.apache.org/articles.html We can't wave a magic wand for you to grasp some of the more important and complicated concepts. Your going to have to help us by helping yourself first. Additionally, if you think these steps are important and not well documented, I invite you to document them for the benefit of others. As a user you should have access to http://docs.codehaus.org/display/MAVENUSER/Home But I think the best option would be to
Antwort: UTF-8 Test Mystery
Hi Erik, > I am having trouble understanding a mystery. > > I have code that checks my .properties file to make sure that it has not > been corrupted after being edited by a non UTF-8 editor. In particular I > have a property called lambda = λ and I check to see that it actually > does resolve to the correct character. > > If I run my code from main (my manual unit test) it works. If I run my > test from JUnit in Eclipse, it works. But when the same test runs under > Maven it fails because lambda = ? I can understand your use case, and we have had similar problems in our department: Code was (is) built and tested locally on Windows PCs, but in production runs under AIX. From time to time we had problems with German umlauts because some guys hardcoded them in their Java code... The only solution that works cross-platform not only from within Java files, but also from property files is to replace non-ASCII-characters by their Unicode value. Example: before: String str = "Schließen"; // ^= "close" after: String str = ""Schlie\u00DFen"; Doesn't look as nice as before, right, and isn't directly readable, but prevents you from such troubles as you have. As I wrote, this also works for properties. HTH Thorsten
Re: Re: UTF-8 Test Mystery
Hi Erik,
> once
>
> Doesn't help.
>
> I have some new insight on the problem. I changed my code to
>
> if (lambda.length() == 1)
> {
> char λ = lambda.charAt(0);
> if (λ != 'λ')
> //if (!lambda.equals("λ"))
> {
> // UTF-8 sanity check failed!
> println(System.err, "lambda = '" + lambda + "'");
> String message = "UTF-8 encoding problem for " +
> propertiesResource;
> println(System.err, message);
> throw new PropertiesError(message);
> }
> }
>
> This code works when built in Eclipse, but fails to compile from the
> command line with
*snip*
Can't you just use plain ASCII characters in your source code? This will
prevent you from such mysterious behaviour. And, as I wrote in an earlier
mail, replace non-ASCII-characters in strings by their Unicode value. In
that case, if I have seen right, replace the lambda char by \u03BB
(Unicode value of the Greek small letter lambda). Saves you a lot of
time
Regards
Thorsten
Re: Problems with MAVEN's-ANT on OpenVMS
Could you have a non-OpenVMS machine running behind your firewall to host Nexus? All you really want to use nexus as is a service to front the proxy servers that you are working with. It seems like overkill to port your entire toolchain to running on OpenVMS just because you need to build some things on OpneVMS... take the things which are pure services (e.g. nexus) and run them on systems where they are supported but within your firewall -Stephen On 11 October 2011 10:25, Stadelmann Josef wrote: > Thank you Barrie, thank you Wayne for your excellent articles. > > Now there is hope to get maven and ant build axis2 and maven and our own > stuff on OpenVMS. > > The issues we are faced with are so many fold: And to complicate things even > more. We sit behind firewalls and maven and ant with a to build > i.e.Axis2, needs to be set with proper proxy info including > http.auth.preference=Basic, not supported straight by Ant or maven but needs > to go as a hint to our Microsoft proxy server to not start negotiating > authentication schemas unable to be handled by the client calling. > > We have a working ant version of Ant, that is to say, by a bash shell script > we launch our own AntClassLoader which creates an Authenticator to pass > username and password and then calls the real AntLoader;;; BTW: Username and > Password for the proxy server is never picked up by default from JAVA args as > said in documents at various places. We have investigated Ant code for that. > It is picked up by ant code only if you pass the --diagnostics switch to Ant > and makes people think that all is fine, but in reality for a get task Ant > does not pick proxy info under normal operation. This circumstance alone has > made us work for some days. Also to be honest to Ant, it might be a Java JVM > or java.net problem. > > Which org has to deal with such issues? Which org should fix it once for ever? > Or who has to deal with such issues? > The Ant-, or Maven-, or Java- or any of the mayn thousand jar-developers. > > > We like to setup JAVA Arguments like -Dhttp.proxy.User=name > -Dhttp.proxy.Password=xxx. So all is fine if we pass this as Ant arguments > from inside a build.xml. BUT we do not like to change the ant build.xml files > for each product like axis2 or maven. And we do not like to modify each maven > pom for the same reason. We prefer a more central place. This is the case for > maven with its settings.xml (except http.auth.preference=Basic is not > foreseen by maven). > > It is always the same: what is used where and when and under which > circumstances ?! > > Question: Given mavens settings.xml has the proxy info's does maven tell ant > about this proxy information? If yes, where in code and how? > Question: how does maven get best informed about the preferred authentication > schemas to be used by the proxy server > i.e. -Dhttp.auth.preference=Basic as described by the ORACLE documentation > for JAVA and at many other places. > Question: If ant is first and picks up and works would you expect for maven > that ant tells maven about proxy info to be used? > > BTW: thanks for the pointers to the books. > > BTW: I took the latest sources of nexus down to my Vista PC. Tried to build > it as I do with maven and axis2 and it failed! > BTW: Then I took the latest binary version of a nexus-webapp.war down to my > OpenVMS, I untared it on OpenVMS as we do with Axis2 or maven. > It fails during startup on Tomcat and Java 6.0. Many things get up as one > can see in tomcat logs attached as text file; but it fails. > > I did so because Wayne Fay said to work with nexus simplifies much of this > repository and cache management. And I beleave you. And I like the idea very > much and was reading a lot about nexus and repositories immediately. But in > reality we have now one more product on OpenVMS which we need to make work > first; where ever the problem is. Is it JAVA from HP? or any of the jar files > issuing a shell script? or the use of exported environment variable of which > bash under OpenVMS does not know anything by default? It is a tedious process > to make such complex environments work; > > Josef > > > > > > > -Ursprüngliche Nachricht- > Von: Barrie Treloar [mailto:baerr...@gmail.com] > Gesendet: Mittwoch, 5. Oktober 2011 00:45 > An: Maven Users List > Betreff: Re: Problems with MAVEN's-ANT on OpenVMS > > On Wed, Oct 5, 2011 at 3:43 AM, Wayne Fay wrote: >>> May I ask you a favor and lead me to a document describing how we can make >>> maven using our own ant 1.7.1, >>> as we had changes in ANT 1.7.1 specifically for OpenVMS, those catching >>> logical, and generating a temporary >>> file where all the many hundred arguments being passed today to JAVA / JVM >>> are stored in. >> >> I already told you what to do but here are the complete steps: > > Plus, did you try google? > > http://www.google.com/search?q=maven+ant+plugin+change+version+of+ant > > Some of the step
Disable CPD and Enable PMD check for teh same set of classes
--Need to disable CPD and enable PMD for the same set of classes. --Having the 'configuration' tag within an 'execution' tag does not work. --The 'configuration' tag needs to be put outside the 'executions' tag. Therefore, whatever has been configured will apply to both CPD and PMD. --Also tried to have 2 'plugin' tags - one for CPD and other for PMD. But, the last 'plugin' tag is considered. Please help me with this. Thanks -- View this message in context: http://maven.40175.n5.nabble.com/Disable-CPD-and-Enable-PMD-check-for-teh-same-set-of-classes-tp4891455p4891455.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: UTF-8 Test Mystery
suggest the extra step of set encoding="UTF-8" at top of applicable config
files:
yesterday i was able to find the cause of CXF WSDL2Java failure for ApacheCXF
Wsdl2Java with JaxB mappinghttps://issues.apache.org/jira/browse/CXF-1463
$ApacheCXF_HOME\bin\wsdl2java BensonMarguiles.wsdl
NullPointerException
if i change complexType name to all lowercase wsdl2java produces correct code
Axis-2.1.5+ ignores camelcase and creates packagenames with all lowercase e.g.
benson_marguiles.Benson.java
benson_marguiles.Marguiles.java Thanks,Martin Gainty
__ All the smart people get off at
Kendall Square..personal quote
> Date: Mon, 10 Oct 2011 21:40:41 -0400
> Subject: Re: UTF-8 Test Mystery
> From: bimargul...@gmail.com
> To: users@maven.apache.org
>
> Eric,
>
> A couple of points:
>
> 1: Javac has an option to control the input encoding of java source
> files. There's a corresponding configuration option for the
> maven-compiler-plugin.
>
> 2: Adding -Dfile.encoding=utf-8 to MAVEN_OPTS will cause maven, and
> any other piece of java it launches, to use UTF-8 as the default
> encoding. If surefire is forking you'll have to add this to the
> systemPropertyValues.
>
>
> 2011/10/10 Eric Kolotyluk :
> > once
> >
> > Doesn't help.
> >
> > I have some new insight on the problem. I changed my code to
> >
> >if (lambda.length() == 1)
> >{
> >char λ = lambda.charAt(0);
> >if (λ != 'λ')
> >//if (!lambda.equals("λ"))
> >{
> >// UTF-8 sanity check failed!
> >println(System.err, "lambda = '" + lambda + "'");
> >String message = "UTF-8 encoding problem for " +
> > propertiesResource;
> >println(System.err, message);
> >throw new PropertiesError(message);
> >}
> >}
> >
> > This code works when built in Eclipse, but fails to compile from the command
> > line with
> >
> > [INFO] Compiling 30 source files to
> > P:\Intersystem\main\platform.Java\intersystem-common\target\classes
> > [INFO] -
> > [ERROR] COMPILATION ERROR :
> > [INFO] -
> > [ERROR]
> > /Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[354,38]
> > illegal character: \187
> > [ERROR]
> > /Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[355,37]
> > illegal character: \187
> > [ERROR]
> > /Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[355,42]
> > unclosed character literal
> > [ERROR]
> > /Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[355,44]
> > illegal character: \187
> > [ERROR]
> > /Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[355,45]
> > unclosed character literal
> > [ERROR]
> > /Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[364,24]
> > illegal start of expression
> > [INFO] 6 errors
> > [INFO] -
> > [INFO]
> >
> > [INFO] BUILD FAILURE
> >
> > I can't figure out why the compiler is failing because I can clearly see
> >
> > [DEBUG] (f) encoding = UTF-8
> >
> > in the Maven output just before the errors.
> >
> > Anyone have any ideas? Is there some other compiler option I am missing?
> >
> > Cheers, Eric
> >
> > On 2011-10-10 5:23 PM, Kalle Korhonen wrote:
> >>
> >> Different forkMode perhaps?
> >>
> >> http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#forkMode,
> >> e.g:
> >> once
> >>
> >> Just send the whole keg while you are at it :)
> >>
> >> Kalle
> >>
> >>
> >> 2011/10/10 Eric Kolotyluk:
> >>>
> >>> Actually - that helped - but it's not a stable solution. For some reason
> >>> the
> >>> tests pass when run from m2e, but fail when run from the command line.
> >>> I'm
> >>> still trying to figure out what the difference is.
> >>>
> >>> Cheers, Eric
> >>>
> >>> On 2011-10-10 4:41 PM, Kalle Korhonen wrote:
>
> A whole case? I *love* inflation.
>
> Kalle
>
>
> 2011/10/10 Eric Kolotyluk:
> >
> > Awesome Kalle - thanks.
> >
> > Where should I send the case of beer?
> >
> > Cheers, Eric
> >
> > On 2011-10-10 4:00 PM, Kalle Korhonen wrote:
> >>
> >> How are you reading in your properties files? By default, latin-1 is
> >> assumed. Configure your surefire JVM to read files as UTF-8 with:
> >> -Xms256m -Xmx512m -XX:MaxPermSize=128m -ea
>
Re: UTF-8 Test Mystery
OK, I got things working with
UTF-8
UTF-8
UTF-8
org.apache.maven.plugins
maven-compiler-plugin
2.3.2
P:\ValueInPrint\Main\jdk\jdk1.5.0_11\bin\javac
I could not figure out how to get it to work with the true
setting, even after setting MAVEN_OPTS=-Dfile.encoding=utf-8
I removed
-->
org.apache.maven.plugins
maven-surefire-plugin
2.9
junit:junit
UTF-8
UTF-8
UTF-8
-Xms256m -Xmx512m -XX:MaxPermSize=128m -ea
-Dfile.encoding=UTF-8
and things still seem to work correctly, but I should probably leave it
in anyway to be sure in the future.
To summarize, this whole problem was caused by the compiler not
compiling the literal "λ" correctly so my original code
if (!lambda.equals("λ"))
was failing - javac was substituting some other string literal - I did
not figure this out until stepping through the code with the debugger.
Somehow in the Eclipse and JUnit environment it was working correctly
sometimes and not others, but always failing from the command line, so I
assumed it was surefire. I do not think there was any problem with
surefire, as using the default settings seems to work.
In short my code and unit test were doing exactly what they were
supposed to do to make sure UTF-8 was being handled properly, in
particular my unit test caught the compiler doing the wrong thing in
certain situations - it was just hard for me to believe the compiler was
compiling the wrong code and easier to assume it was surefire or something.
Maybe in the 22nd century we will not have so many problems with UTF-8 :-)
Thanks everyone for your help and insight.
Cheers, Eric
On 2011-10-10 6:40 PM, Benson Margulies wrote:
Eric,
A couple of points:
1: Javac has an option to control the input encoding of java source
files. There's a corresponding configuration option for the
maven-compiler-plugin.
2: Adding -Dfile.encoding=utf-8 to MAVEN_OPTS will cause maven, and
any other piece of java it launches, to use UTF-8 as the default
encoding. If surefire is forking you'll have to add this to the
systemPropertyValues.
2011/10/10 Eric Kolotyluk:
once
Doesn't help.
I have some new insight on the problem. I changed my code to
if (lambda.length() == 1)
{
char λ = lambda.charAt(0);
if (λ != 'λ')
//if (!lambda.equals("λ"))
{
// UTF-8 sanity check failed!
println(System.err, "lambda = '" + lambda + "'");
String message = "UTF-8 encoding problem for " +
propertiesResource;
println(System.err, message);
throw new PropertiesError(message);
}
}
This code works when built in Eclipse, but fails to compile from the command
line with
[INFO] Compiling 30 source files to
P:\Intersystem\main\platform.Java\intersystem-common\target\classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[354,38]
illegal character: \187
[ERROR]
/Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[355,37]
illegal character: \187
[ERROR]
/Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[355,42]
unclosed character literal
[ERROR]
/Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[355,44]
illegal character: \187
[ERROR]
/Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[355,45]
unclosed character literal
[ERROR]
/Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[364,24]
illegal start of expression
[INFO] 6 errors
[INFO] -
[INFO]
[INFO] BUILD FAILURE
I can't figure out why the compiler is failing because I can clearly see
[DEBUG] (f) encoding = UTF-8
in the Maven output just before the errors.
Anyone have any ideas? Is there some other compiler option I am missing?
Cheers, Eric
On 2011-10-10 5:23 PM, Kalle Korhonen wrote:
Different forkMode perhaps?
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#forkMode,
e.g:
once
Just send the whole keg while you are at it :)
Kalle
2011/10/10 Eric Kolotyluk:
Actually - that helped - but it's not a stable solution. For some reason
the
tests pass when run from m2e, but fail when run from the command line.
I'm
still trying to figure out what the difference is.
Cheers, Eric
On 2011-10-10 4:41 PM, Kalle Korhonen wrote:
A whole case? I *love* inflation.
Kalle
2011/10/10 Eric Kolotyluk:
Awesome K
Re: UTF-8 Test Mystery
Eric,
http://maven.apache.org/plugins/maven-surefire-plugin/examples/system-properties.html
Add file.encoding that way for fork mode.
On Tue, Oct 11, 2011 at 8:27 AM, Eric Kolotyluk
wrote:
> OK, I got things working with
>
>
> UTF-8
> UTF-8
> UTF-8
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.3.2
>
>
> P:\ValueInPrint\Main\jdk\jdk1.5.0_11\bin\javac
>
>
>
> I could not figure out how to get it to work with the true
> setting, even after setting MAVEN_OPTS=-Dfile.encoding=utf-8
>
> I removed
>
> -->
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.9
>
> junit:junit
> UTF-8
> UTF-8
> UTF-8
> -Xms256m -Xmx512m -XX:MaxPermSize=128m -ea
> -Dfile.encoding=UTF-8
>
>
>
> and things still seem to work correctly, but I should probably leave it in
> anyway to be sure in the future.
>
> To summarize, this whole problem was caused by the compiler not compiling
> the literal "λ" correctly so my original code
>
> if (!lambda.equals("λ"))
>
> was failing - javac was substituting some other string literal - I did not
> figure this out until stepping through the code with the debugger. Somehow
> in the Eclipse and JUnit environment it was working correctly sometimes and
> not others, but always failing from the command line, so I assumed it was
> surefire. I do not think there was any problem with surefire, as using the
> default settings seems to work.
>
> In short my code and unit test were doing exactly what they were supposed to
> do to make sure UTF-8 was being handled properly, in particular my unit test
> caught the compiler doing the wrong thing in certain situations - it was
> just hard for me to believe the compiler was compiling the wrong code and
> easier to assume it was surefire or something.
>
> Maybe in the 22nd century we will not have so many problems with UTF-8 :-)
>
> Thanks everyone for your help and insight.
>
> Cheers, Eric
>
> On 2011-10-10 6:40 PM, Benson Margulies wrote:
>>
>> Eric,
>>
>> A couple of points:
>>
>> 1: Javac has an option to control the input encoding of java source
>> files. There's a corresponding configuration option for the
>> maven-compiler-plugin.
>>
>> 2: Adding -Dfile.encoding=utf-8 to MAVEN_OPTS will cause maven, and
>> any other piece of java it launches, to use UTF-8 as the default
>> encoding. If surefire is forking you'll have to add this to the
>> systemPropertyValues.
>>
>>
>> 2011/10/10 Eric Kolotyluk:
>>>
>>> once
>>>
>>> Doesn't help.
>>>
>>> I have some new insight on the problem. I changed my code to
>>>
>>> if (lambda.length() == 1)
>>> {
>>> char λ = lambda.charAt(0);
>>> if (λ != 'λ')
>>> //if (!lambda.equals("λ"))
>>> {
>>> // UTF-8 sanity check failed!
>>> println(System.err, "lambda = '" + lambda + "'");
>>> String message = "UTF-8 encoding problem for " +
>>> propertiesResource;
>>> println(System.err, message);
>>> throw new PropertiesError(message);
>>> }
>>> }
>>>
>>> This code works when built in Eclipse, but fails to compile from the
>>> command
>>> line with
>>>
>>> [INFO] Compiling 30 source files to
>>> P:\Intersystem\main\platform.Java\intersystem-common\target\classes
>>> [INFO] -
>>> [ERROR] COMPILATION ERROR :
>>> [INFO] -
>>> [ERROR]
>>>
>>> /Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[354,38]
>>> illegal character: \187
>>> [ERROR]
>>>
>>> /Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[355,37]
>>> illegal character: \187
>>> [ERROR]
>>>
>>> /Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[355,42]
>>> unclosed character literal
>>> [ERROR]
>>>
>>> /Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[355,44]
>>> illegal character: \187
>>> [ERROR]
>>>
>>> /Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[355,45]
>>> unclosed character literal
>>> [ERROR]
>>>
>>> /Intersystem/main/platform.Java/intersystem-common/src/main/java/com/kodak/intersystem/common/Properties.java:[364,24]
>>> illegal start of expression
>>> [INFO] 6 errors
>>> [INFO] -
>>> [INFO]
>>>
>>> [INFO] BUILD FAILURE
>>>
>>> I can't figure out why the compiler is failing because I can clearly see
>>>
>>> [DEBUG] (f) encoding = UTF-8
>>>
>>> in the Maven output just before the errors.
>>>
>>> Anyone have any ideas? Is there some other compiler option I am missing?
>>>
>>> Cheers, Eric
>>>
>
Re: Managing Different Java Versions
So, if what I want is to avoid calling any Java 6 methods I would use org.codehaus.mojo animal-sniffer-maven-plugin 1.3 check-java16 test check org.codehaus.mojo.signature java16 1.0 When I run this I gets tons of error messages that gives me the impression something is not configured right - what am I still missing? [INFO] [INFO] --- animal-sniffer-maven-plugin:1.3:check (check-java16) @ intersystem-common --- [INFO] Checking unresolved references to org.codehaus.mojo.signature:java16:1.0 com/kodak/intersystem/common/Application$1 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$1.val$exitResult#Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Object com/kodak/intersystem/common/Application$1 com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exit(Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult;)I in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Thread java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.getName()Ljava/lang/String; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setName(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setDaemon(Z)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.access$000()Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder org/slf4j/Logger [ERROR] Undefined reference: org/slf4j/Logger.debug(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/Object com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.logger#Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Properties [ERROR] Undefined reference: com/kodak/intersystem/common/Properties.getLogger(Ljava/lang/Class;)Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exitListenerManager#Lcom/kodak/intersystem/common/ExitListenerManager; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.addExitListener(Lcom/kodak/intersystem/common/ExitListener;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.removeExitListener(Lcom/kodak/intersystem/common/ExitListener;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.isExiting#Z in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.stopping#Z in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersy
Re: Managing Different Java Versions
Well first off, try upgrading the version of animal-sniffer-maven-plugin to latest... The signatures (and their site) were generated when 1.3 was the latest... 1.7 has a number of important fixes, but without regenerating the signatures it is hard to get the site updated to say the version of animal-sniffer should be 1.7 On 11 October 2011 13:49, Eric Kolotyluk wrote: > So, if what I want is to avoid calling any Java 6 methods I would use > > > org.codehaus.mojo > animal-sniffer-maven-plugin > 1.3 > > > check-java16 > test > > check > > > > org.codehaus.mojo.signature > java16 > 1.0 > > > > > > > When I run this I gets tons of error messages that gives me the impression > something is not configured right - what am I still missing? > > [INFO] > [INFO] --- animal-sniffer-maven-plugin:1.3:check (check-java16) @ > intersystem-common --- > [INFO] Checking unresolved references to > org.codehaus.mojo.signature:java16:1.0 > com/kodak/intersystem/common/Application$1 > [ERROR] Undefined reference: > com/kodak/intersystem/common/Application$1.val$exitResult#Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult; > in > P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class > java/lang/Object > com/kodak/intersystem/common/Application$1 > com/kodak/intersystem/common/Application > [ERROR] Undefined reference: > com/kodak/intersystem/common/Application.exit(Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult;)I > in > P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class > java/lang/Thread > java/lang/StringBuilder > java/lang/StringBuilder > com/kodak/intersystem/common/Application$2 > [ERROR] Undefined reference: > com/kodak/intersystem/common/Application$2.getName()Ljava/lang/String; in > P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class > java/lang/StringBuilder > java/lang/StringBuilder > java/lang/StringBuilder > com/kodak/intersystem/common/Application$2 > [ERROR] Undefined reference: > com/kodak/intersystem/common/Application$2.setName(Ljava/lang/String;)V in > P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class > com/kodak/intersystem/common/Application$2 > [ERROR] Undefined reference: > com/kodak/intersystem/common/Application$2.setDaemon(Z)V in > P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class > com/kodak/intersystem/common/Application > [ERROR] Undefined reference: > com/kodak/intersystem/common/Application.access$000()Lorg/slf4j/Logger; in > P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class > java/lang/StringBuilder > java/lang/StringBuilder > com/kodak/intersystem/common/Application$2 > java/lang/StringBuilder > java/lang/StringBuilder > java/lang/StringBuilder > org/slf4j/Logger > [ERROR] Undefined reference: org/slf4j/Logger.debug(Ljava/lang/String;)V in > P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class > java/lang/Object > com/kodak/intersystem/common/Application > [ERROR] Undefined reference: > com/kodak/intersystem/common/Application.logger#Lorg/slf4j/Logger; in > P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class > com/kodak/intersystem/common/Properties > [ERROR] Undefined reference: > com/kodak/intersystem/common/Properties.getLogger(Ljava/lang/Class;)Lorg/slf4j/Logger; > in > P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class > com/kodak/intersystem/common/Application > com/kodak/intersystem/common/Application > com/kodak/intersystem/common/Application > [ERROR] Undefined reference: > com/kodak/intersystem/common/Application.exitListenerManager#Lcom/kodak/intersystem/common/ExitListenerManager; > in > P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class > com/kodak/intersystem/common/ExitListenerManager > [ERROR] Undefined reference: > com/kodak/intersystem/common/ExitListenerManager.addExitListener(Lcom/kodak/intersystem/common/ExitListener;)V > in > P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class > com/kodak/intersystem/common/Application > com/kodak/intersystem/common/ExitListenerManager > [ERROR] Undefined reference: > com/kodak/intersystem/common/ExitListenerManager.removeExitListener(Lcom/kodak/intersystem/common/ExitListener;)V > in > P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class > com/kodak/intersystem/common/Application > com/kodak/intersystem/common/ExitListenerManager > [ERROR] U
Re: Managing Different Java Versions
OK, 1.7 works much better - thanks. Finally now that I have it working I can understand better what it does and how it is useful. Thank you to everyone who helped, and for being patient with me. Cheers, Eric On 2011-10-11 6:25 AM, Stephen Connolly wrote: Well first off, try upgrading the version of animal-sniffer-maven-plugin to latest... The signatures (and their site) were generated when 1.3 was the latest... 1.7 has a number of important fixes, but without regenerating the signatures it is hard to get the site updated to say the version of animal-sniffer should be 1.7 On 11 October 2011 13:49, Eric Kolotyluk wrote: So, if what I want is to avoid calling any Java 6 methods I would use org.codehaus.mojo animal-sniffer-maven-plugin 1.3 check-java16 test check org.codehaus.mojo.signature java16 1.0 When I run this I gets tons of error messages that gives me the impression something is not configured right - what am I still missing? [INFO] [INFO] --- animal-sniffer-maven-plugin:1.3:check (check-java16) @ intersystem-common --- [INFO] Checking unresolved references to org.codehaus.mojo.signature:java16:1.0 com/kodak/intersystem/common/Application$1 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$1.val$exitResult#Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Object com/kodak/intersystem/common/Application$1 com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exit(Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult;)I in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Thread java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.getName()Ljava/lang/String; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setName(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setDaemon(Z)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.access$000()Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder org/slf4j/Logger [ERROR] Undefined reference: org/slf4j/Logger.debug(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/Object com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.logger#Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Properties [ERROR] Undefined reference: com/kodak/intersystem/common/Properties.getLogger(Ljava/lang/Class;)Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exitListenerManager#Lcom/kodak/intersystem/common/ExitListenerManager; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.addExitListener(Lcom/kodak/intersystem/common/ExitListener;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.removeExitListener(Lcom/kodak/intersystem/common/ExitListener;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com
Re: Managing Different Java Versions
Done! http://jira.codehaus.org/browse/MANIMALSNIFFER-21 If I think of further documentation improvements should I add them to the same ticket, or create separate ones. Cheers, Eric On 2011-10-11 12:31 AM, Anders Hammar wrote: I believe Stephen answered (1) for me quite elegantly. It would help tremendously if his explanation were documented on the introduction page. I'm not sure if sniffer solves (2) which really was my original intent because I had already solved (1) by other means. Eric, if you file a ticket supplying exactly what text you want added (and specify to what page and where on that page) I will make sure it will get committed. You don't have to provide a patch (as you say you don't know how to do that), but you could just type the text in the ticket itself. The key here is to file a jira ticket. Nothing will happen from a mail thread. /Anders - Eric Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Project specific alternate settings.xml
Hello Maven users, Maven has notion of global (M2_HOME/conf/settings.xml), user settings (typically in ~/.m2/settings.xml), and build specific alternate settings (one specified in build command using -s switch). What does community think, should there be a convention automated in Maven logic of using project specific alternate settings? E.g. settings.xml if present in same path as pom.xml from where build is started could be used as alternate settings for that project build. Dunno about community, but lots of my projects use project specific Maven settings and repeating -s switch all the time is not nice, but also merging multiple different project settings into user settings.xml is even less desired - want to make sure that project will build not just for my environment but for other devs and CI too. Such project specific settings file could be used automatically buy CI servers as well, just by checking out source code with settings.xml included, and running Maven build. Regards, Stevo. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Tomcat Plugin] WebAppSourceDirectory Configuration?
Hi,
I believe this forces me to change the location of the web apps data files.
Right now they are located under WEB-INF/data/somedata.xml. So if I use a
ContextClassLoader then I have to change the location of the files when the
webapp is deployed in production right?
Thanks,
- Ole
On 10/11/2011 03:25 AM, Olivier Lamy wrote:
Hello,
Why not simply put your resources in src/main/resources and load it
with Thread.currentThread().getContextClassLoader().getResourceAsStream(
path in classloader ) ?
2011/10/11 Ole Ersoy:
Maybe if i explain what I'm trying to do, it will make more sense. I have a
maven webapp project. I'm running it with:
mvn tomcat:run
When I run the webapp I would like to load resources from
"WEB-INF/resources/...". When running a webapp in a standalone container
"WEB-INF" is located in the "root" folder. However because I'm using maven
to run the webapp, the "WEB-INF" folder is located under "src/main/webapp".
Therefore if I want to test resource loading I need to add
"src/main/webapp" to the path of the resource when running with:
mvn tomcat:run.
So for example running with "mvn tomcat:run" I have to load myresource.xml
like this:
application.load("src/main/webapp/WEB-INF/resources/myresource.xml");
However when deploying in a standalone container the same resource would be
loaded like this:
application.load("WEB-INF/resources/theresource.xml");
I'm trying to avoid having to change my application configuration for
testing in a standalone container and testing with:
mvn tomcat:run
Does that make sense?
Thanks,
- Ole
On 10/10/2011 04:26 PM, Olivier Lamy wrote:
2011/10/10 Ole Ersoy:
I'm running the tomcat plugin configured as follows:
org.codehaus.mojo
tomcat-maven-plugin
${basedir}/src/main/webapp
If I run the following line from a servlet the application is running:
logger.trace("The current root directory is: {} ", new
File("").getAbsolutePath());
I would expect to see "The current root directory is:
${basedir}/src/main/webapp". However the result is:
"The current root directory is: ${basedir}". In other words it seems the
configuration has not taken effect.
you should read current root webapp directory in the servlet container.
this means if you go with your browser to http://localhost:${port}/
you will see files from this directory.
Thoughts? TIA,
- Ole
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: [Tomcat Plugin] WebAppSourceDirectory Configuration?
servletContext.getResourceAsStream("WEB-INF/data/somedata.xml")
?
2011/10/11 Ole Ersoy :
> Hi,
>
> I believe this forces me to change the location of the web apps data files.
> Right now they are located under WEB-INF/data/somedata.xml. So if I use a
> ContextClassLoader then I have to change the location of the files when the
> webapp is deployed in production right?
>
> Thanks,
> - Ole
>
> On 10/11/2011 03:25 AM, Olivier Lamy wrote:
>>
>> Hello,
>> Why not simply put your resources in src/main/resources and load it
>> with Thread.currentThread().getContextClassLoader().getResourceAsStream(
>> path in classloader ) ?
>>
>> 2011/10/11 Ole Ersoy:
>>>
>>> Maybe if i explain what I'm trying to do, it will make more sense. I
>>> have a
>>> maven webapp project. I'm running it with:
>>>
>>> mvn tomcat:run
>>>
>>> When I run the webapp I would like to load resources from
>>> "WEB-INF/resources/...". When running a webapp in a standalone
>>> container
>>> "WEB-INF" is located in the "root" folder. However because I'm using
>>> maven
>>> to run the webapp, the "WEB-INF" folder is located under
>>> "src/main/webapp".
>>> Therefore if I want to test resource loading I need to add
>>> "src/main/webapp" to the path of the resource when running with:
>>> mvn tomcat:run.
>>>
>>> So for example running with "mvn tomcat:run" I have to load
>>> myresource.xml
>>> like this:
>>> application.load("src/main/webapp/WEB-INF/resources/myresource.xml");
>>>
>>> However when deploying in a standalone container the same resource would
>>> be
>>> loaded like this:
>>> application.load("WEB-INF/resources/theresource.xml");
>>>
>>> I'm trying to avoid having to change my application configuration for
>>> testing in a standalone container and testing with:
>>> mvn tomcat:run
>>>
>>> Does that make sense?
>>>
>>> Thanks,
>>> - Ole
>>>
>>>
>>> On 10/10/2011 04:26 PM, Olivier Lamy wrote:
2011/10/10 Ole Ersoy:
>
> I'm running the tomcat plugin configured as follows:
>
>>>
>>> org.codehaus.mojo
>>> tomcat-maven-plugin
>>>
>>>
>>> ${basedir}/src/main/webapp
>>>
>>>
>
> If I run the following line from a servlet the application is running:
> logger.trace("The current root directory is: {} ", new
> File("").getAbsolutePath());
>
> I would expect to see "The current root directory is:
> ${basedir}/src/main/webapp". However the result is:
> "The current root directory is: ${basedir}". In other words it seems
> the
> configuration has not taken effect.
you should read current root webapp directory in the servlet container.
this means if you go with your browser to http://localhost:${port}/
you will see files from this directory.
>
> Thoughts? TIA,
> - Ole
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
--
Olivier Lamy
Talend : http://talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
Wanted to add a "plug" for the versions-maven-plugin org.codehaus.mojo versions-maven-plugin 1.2 the goal "versions:display-plugin-updates" will let you know if any plugins that you are referencing have more recent versions versions:display-dependency-updates and versions:display-property-updates are also helpful in keeping pom references current On 10/11/11 9:25 AM, Stephen Connolly wrote: Well first off, try upgrading the version of animal-sniffer-maven-plugin to latest... The signatures (and their site) were generated when 1.3 was the latest... 1.7 has a number of important fixes, but without regenerating the signatures it is hard to get the site updated to say the version of animal-sniffer should be 1.7 On 11 October 2011 13:49, Eric Kolotyluk wrote: So, if what I want is to avoid calling any Java 6 methods I would use org.codehaus.mojo animal-sniffer-maven-plugin 1.3 check-java16 test check org.codehaus.mojo.signature java16 1.0 When I run this I gets tons of error messages that gives me the impression something is not configured right - what am I still missing? [INFO] [INFO] --- animal-sniffer-maven-plugin:1.3:check (check-java16) @ intersystem-common --- [INFO] Checking unresolved references to org.codehaus.mojo.signature:java16:1.0 com/kodak/intersystem/common/Application$1 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$1.val$exitResult#Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Object com/kodak/intersystem/common/Application$1 com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exit(Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult;)I in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Thread java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.getName()Ljava/lang/String; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setName(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setDaemon(Z)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.access$000()Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder org/slf4j/Logger [ERROR] Undefined reference: org/slf4j/Logger.debug(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/Object com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.logger#Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Properties [ERROR] Undefined reference: com/kodak/intersystem/common/Properties.getLogger(Ljava/lang/Class;)Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exitListenerManager#Lcom/kodak/intersystem/common/ExitListenerManager; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.addExitListener(Lcom/kodak/intersystem/common/ExitListener;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.removeExitListener(Lcom/kodak/intersystem/common/ExitListener;)V in P:\Intersystem
Getting 401 error when trying to use Maven Tomcat plugin
Hi,
I'm using maven 3.0.3 with the Maven-Tomcat (1.1) plugin. I'm having
trouble deploying my WAR file to a running Tomcat (6.0.33) instance using
mvn clean install tomcat:deploy
which spits out the 401 error below. My Tomcat plugin configuration is as
follows ...
org.codehaus.mojo
tomcat-maven-plugin
1.1
http://localhost:8080/manager
tomcat-server
target/${project.artifactId}-${project.version}.${project.packaging}
I have verified that the credentials (corresponding to the tomcat-server)
are correct by using them to login in a web browser. Any thoughts about why
this is failing?
===The error message
===
...
[INFO]
[INFO] --- maven-war-plugin:2.1.1:war (default-war) @ pplus2 ---
[INFO] Packaging webapp
[INFO] Assembling webapp [pplus2] in [C:\Documents and
Settings\E18538\workspace\pplus2\target\pplus2-1.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources [C:\Documents and
Settings\E18538\workspace\pplus2\src\main\webapp]
[INFO] Webapp assembled in [218 msecs]
[INFO] Building war: C:\Documents and
Settings\E18538\workspace\pplus2\target\pplus2-1.0-SNAPSHOT.war
[WARNING] Warning: selected war files include a WEB-INF/web.xml which will
be ignored
(webxml attribute is missing from war task, or ignoreWebxml attribute is
specified as 'true')
[INFO]
[INFO] <<< tomcat-maven-plugin:1.1:deploy (default-cli) @ pplus2 <<<
[INFO]
[INFO] --- tomcat-maven-plugin:1.1:deploy (default-cli) @ pplus2 ---
[INFO] Deploying war to http://localhost:8080/pplus2
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 5.236s
[INFO] Finished at: Tue Oct 11 10:24:32 CDT 2011
[INFO] Final Memory: 14M/36M
[INFO]
[ERROR] Failed to execute goal
org.codehaus.mojo:tomcat-maven-plugin:1.1:deploy (default-cli) on project
pplus2: Cannot invoke Tomcat manager: Server returned HTTP response code:
401 for URL: http://localhost:8080/manager/deploy?path=%2Fpplus2&war= ->
[Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
--
View this message in context:
http://maven.40175.n5.nabble.com/Getting-401-error-when-trying-to-use-Maven-Tomcat-plugin-tp4892167p4892167.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting 401 error when trying to use Maven Tomcat plugin
Hello,
Can you check you have correctly configured your tomcat instance :
http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html#Configuring_Manager_Application_Access
Thanks
2011/10/11 laredotornado-3 :
> Hi,
>
> I'm using maven 3.0.3 with the Maven-Tomcat (1.1) plugin. I'm having
> trouble deploying my WAR file to a running Tomcat (6.0.33) instance using
>
> mvn clean install tomcat:deploy
>
> which spits out the 401 error below. My Tomcat plugin configuration is as
> follows ...
>
>
>
> org.codehaus.mojo
> tomcat-maven-plugin
> 1.1
>
> http://localhost:8080/manager
> tomcat-server
>
> target/${project.artifactId}-${project.version}.${project.packaging}
>
>
>
>
> I have verified that the credentials (corresponding to the tomcat-server)
> are correct by using them to login in a web browser. Any thoughts about why
> this is failing?
>
>
> ===The error message
> ===
> ...
> [INFO]
> [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ pplus2 ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [pplus2] in [C:\Documents and
> Settings\E18538\workspace\pplus2\target\pplus2-1.0-SNAPSHOT]
> [INFO] Processing war project
> [INFO] Copying webapp resources [C:\Documents and
> Settings\E18538\workspace\pplus2\src\main\webapp]
> [INFO] Webapp assembled in [218 msecs]
> [INFO] Building war: C:\Documents and
> Settings\E18538\workspace\pplus2\target\pplus2-1.0-SNAPSHOT.war
> [WARNING] Warning: selected war files include a WEB-INF/web.xml which will
> be ignored
> (webxml attribute is missing from war task, or ignoreWebxml attribute is
> specified as 'true')
> [INFO]
> [INFO] <<< tomcat-maven-plugin:1.1:deploy (default-cli) @ pplus2 <<<
> [INFO]
> [INFO] --- tomcat-maven-plugin:1.1:deploy (default-cli) @ pplus2 ---
> [INFO] Deploying war to http://localhost:8080/pplus2
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 5.236s
> [INFO] Finished at: Tue Oct 11 10:24:32 CDT 2011
> [INFO] Final Memory: 14M/36M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.codehaus.mojo:tomcat-maven-plugin:1.1:deploy (default-cli) on project
> pplus2: Cannot invoke Tomcat manager: Server returned HTTP response code:
> 401 for URL: http://localhost:8080/manager/deploy?path=%2Fpplus2&war= ->
> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Getting-401-error-when-trying-to-use-Maven-Tomcat-plugin-tp4892167p4892167.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
--
Olivier Lamy
Talend : http://talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Project specific alternate settings.xml
What sort of things do you want at the project level that can not be handled by a parent pom? Ron On 11/10/2011 9:56 AM, Stevo Slavić wrote: Hello Maven users, Maven has notion of global (M2_HOME/conf/settings.xml), user settings (typically in ~/.m2/settings.xml), and build specific alternate settings (one specified in build command using -s switch). What does community think, should there be a convention automated in Maven logic of using project specific alternate settings? E.g. settings.xml if present in same path as pom.xml from where build is started could be used as alternate settings for that project build. Dunno about community, but lots of my projects use project specific Maven settings and repeating -s switch all the time is not nice, but also merging multiple different project settings into user settings.xml is even less desired - want to make sure that project will build not just for my environment but for other devs and CI too. Such project specific settings file could be used automatically buy CI servers as well, just by checking out source code with settings.xml included, and running Maven build. Regards, Stevo. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting 401 error when trying to use Maven Tomcat plugin
Hi, I did add each of those roles to the "tomcat" user in the tomcat-users.xml file ... Any other ideas or is there something wrong with the above? - Dave -- View this message in context: http://maven.40175.n5.nabble.com/Getting-401-error-when-trying-to-use-Maven-Tomcat-plugin-tp4892167p4892359.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Project specific alternate settings.xml
Server authentication for example, it can not be specified in pom. Projects use project/client specific repository or repositories - wouldn't like to mix settings of multiple projects in user settings, to minimize chance of accessing repositories and resolving dependencies from them in a project where they're not supposed to be used from. Same project specific settings file used by all developers on project, and CI, with credentials referenced via environment variables - each developer specifies his own credentials, works for CI build jobs. Another one is to be able to specify project specific local repository in project specific settings.xml, to minimize a chance of "it works for me" scenario, just because someone was building another project before build would pass for him but not for others. Regards, Stevo. On Tue, Oct 11, 2011 at 6:32 PM, Ron Wheeler wrote: > What sort of things do you want at the project level that can not be handled > by a parent pom? > > Ron > > On 11/10/2011 9:56 AM, Stevo Slavić wrote: >> >> Hello Maven users, >> >> Maven has notion of global (M2_HOME/conf/settings.xml), user settings >> (typically in ~/.m2/settings.xml), and build specific alternate >> settings (one specified in build command using -s switch). >> >> What does community think, should there be a convention automated in >> Maven logic of using project specific alternate settings? >> >> E.g. settings.xml if present in same path as pom.xml from where build >> is started could be used as alternate settings for that project build. >> >> Dunno about community, but lots of my projects use project specific >> Maven settings and repeating -s switch all the time is not nice, but >> also merging multiple different project settings into user >> settings.xml is even less desired - want to make sure that project >> will build not just for my environment but for other devs and CI too. >> Such project specific settings file could be used automatically buy CI >> servers as well, just by checking out source code with settings.xml >> included, and running Maven build. >> >> Regards, >> Stevo. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problems with MAVEN's-ANT on OpenVMS
> Question: Given mavens settings.xml has the proxy info's does maven tell ant > about this proxy information? If yes, where in code and how? I don't know. I would expect the answer is in the maven-antrun-plugin source code, and having just glanced at it now, I don't see any specific location where such proxy information is handed off to Ant (but it may be happening despite not seeing it obviously stated via system properties or something): http://svn.apache.org/viewvc/maven/plugins/tags/maven-antrun-plugin-1.6/src/main/java/org/apache/maven/plugin/antrun/AntRunMojo.java?view=markup If you determine that proxy information is not being passed to Ant, and you patch this code to pass proxy info to Ant, please contribute it back via JIRA for the benefit of other users. I should also mention the setproxy Ant task which may be an easier route to a solution for you: http://ant.apache.org/manual/Tasks/setproxy.html > Question: how does maven get best informed about the preferred authentication > schemas to be used by the proxy server > i.e. -Dhttp.auth.preference=Basic as described by the ORACLE documentation > for JAVA and at many other places. There appears to be an open JIRA related to this specifically: http://jira.codehaus.org/browse/MNG-3049 > Question: If ant is first and picks up and works would you expect for maven > that ant tells maven about proxy info to be used? I don't understand this question. Can you please try again, and perhaps explain things more? > BTW: I took the latest sources of nexus down to my Vista PC. Tried to build > it as I do with maven and axis2 and it failed! Why do you insist on building everything from sources? The rest of us use the binaries directly with no complaints. As Stephen already stated, you should just pull down the Nexus binary and run it on Windows, then point your OpenVMS Maven at it. > BTW: Then I took the latest binary version of a nexus-webapp.war down to my > OpenVMS, I untared it on OpenVMS as we do with Axis2 or maven. > It fails during startup on Tomcat and Java 6.0. Many things get up as one > can see in tomcat logs attached as text file; but it fails. I am not surprised that Nexus fails to load on OpenVMS. I bet you are the first person (in the world, perhaps) to attempt such a thing. Feel free to communicate that log to Sonatype directly and they may be able to work with you to fix their code so it runs properly -- the Maven Users list is not the right place for such complaints/discussion. I did look at the log and it has a NFE for input string "1." which seems to be the root problem: Caused by: java.lang.NumberFormatException: For input string: "1." at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Long.parseLong(Long.java:419) at org.apache.lucene.index.SegmentInfos.generationFromSegmentsFileName(SegmentInfos.java:199) Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Tomcat Plugin] WebAppSourceDirectory Configuration?
Maybe - But I'm using DWR to invoke methods on my application layer. I'm not going directly through a servlet. So now my code needs to get the servletContext, which is not a big deal, but it means adding code that's only there for the reason of testing the application layer. I'd rather change the resource paths between testing and production, than make the application more complex. Thanks for all the tips and trying though, - Ole - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
> If I think of further documentation improvements should I add them to the
> same ticket, or create separate ones.
IMO it depends if the are related or not. Also, working with several
smaller tickets is easier than one huge one. When it comes to
documentation it's hard to give a good guideline, but for code one
should always ensure that the subject of the ticket clearly describes
the change and that normally makes it obvious what could be added to
it ("fix bugs" is not a good subject). When it comes to docs I think
that a more general level of "improve doc" is ok.
/Anders
>
> Cheers, Eric
>
> On 2011-10-11 12:31 AM, Anders Hammar wrote:
>>>
>>> I believe Stephen answered (1) for me quite elegantly. It would help
>>> tremendously if his explanation were documented on the introduction page.
>>> I'm not sure if sniffer solves (2) which really was my original intent
>>> because I had already solved (1) by other means.
>>
>> Eric, if you file a ticket supplying exactly what text you want added
>> (and specify to what page and where on that page) I will make sure it
>> will get committed. You don't have to provide a patch (as you say you
>> don't know how to do that), but you could just type the text in the
>> ticket itself.
>> The key here is to file a jira ticket. Nothing will happen from a mail
>> thread.
>>
>> /Anders
>>
>>> - Eric
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
