Re: Problems with MAVEN's-ANT on OpenVMS
Thank you Wayne for this excellent Analysis. If a routine belonging to the file system returns something badly, there is a little chance to influence by a logical JAVA$FILENAME_CONTROL which can be set to so many values used to control filename encodings, particular how to deal with dot's in file names. I found some related comments that may be helpful to you... All this talk of OpenVMS brings me back to days at Uni on VAX/VMS boxen. ;-) http://h30499.www3.hp.com/t5/Languages-and-Scripting/Lucene-Solr-and-filepaths/td-p/4601881 and http://www.mediawiki.org/wiki/Extension_talk:Lucene-search/archive/2010#Lucene-search_on_OpenVMS It seems you will need to use some configuration along these lines: $ set proc/parse=extended $ @SYS$COMMON:[JAVA$150.COM]JAVA$150_SETUP.COM $ define DECC$ARGV_PARSE_STYLE ENABLE $ define DECC$EFS_CASE_PRESERVE ENABLE $ define DECC$POSIX_SEEK_STREAM_FILE ENABLE $ define DECC$EFS_CHARSET ENABLE $ define DECC$ENABLE_GETENV_CACHE ENABLE $ define DECC$FILE_PERMISSION_UNIX ENABLE $ define DECC$FIXED_LENGTH_SEEK_TO_EOF ENABLE $ define DECC$RENAME_NO_INHERIT ENABLE $ define DECC$ENABLE_TO_VMS_LOGNAME_CACHE ENABLE $ FILE_MASK = %x0008 + %x0004 $ DEFINE JAVA$FILENAME_CONTROLS 'file_mask' Wayne - 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
Wow Wayne, brilliant response!
On 20 October 2011 22:51, Wayne Fay wrote:
With knowing the details about our environment
would you expect that Lucene written in clean Java
is not operating on such a platform?
Without a comprehensive analysis of the source code for Lucene (and
potentially, some or all of its dependencies) it is impossible to say
anything conclusive about how well it may operate on OpenVMS or any
other operating system except for those explicitly supported (and
tested) by the dev team. Java isn't truly write-once run-anywhere,
despite such claims ~10-15 years back.
I looked at your stacktrace and the problem seemed to be related to a
NumberFormatException thrown by java.lang.Long.parseLong() that is not
being caught and handled by Lucene:
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)
I found a Lucene JIRA issue that is loosely related:
https://issues.apache.org/jira/browse/LUCENE-3008
Looks like line 211 in trunk is the issue (was line 199 in the stacktrace):
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/SegmentInfos.java?view=markup
The source code is:
return
Long.parseLong(fileName.substring(1+IndexFileNames.SEGMENTS.length()),
Character.MAX_RADIX);
A quick look at the Java API shows:
http://download.oracle.com/javase/1,5.0/docs/api/java/lang/Long.html#parseLong(java.lang.String,%20int)
An exception of type NumberFormatException is thrown if any of the
following situations occurs:
* Any character of the string is not a digit of the specified
radix, except that the first character may be a minus sign '-'
('\u002d') provided that the string is longer than length 1.
The decimal character in the string 1. is not valid in the radix
defined by Character.MAX_RADIX. So, you'll need to figure out where
that filename of 1. is coming from -- either OpenVMS or Lucene --
and somehow get rid of the decimal in the filename. Or just rename
that file from 1. to simply 1 in your filesystem.
Without access to an OpenVMS system and having no real understanding
of Lucene's internals, I can't really look into it any more at this
point. You probably need to email the Lucene Users list and ask if
anyone has successfully gotten it to run on OpenVMS (I'm guessing not)
and get things patched up before you can make more progress with
getting Nexus running on it. Or take the more reasonable approach and
simply install Nexus on a Windows box in your office. ;-)
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Tim Pizey - http://pizey.net/~timp
Centre for Genomics and Global Health - http://cggh.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
Um, unsure about OS versions, but by googling I found this: http://vouters.dyndns.org/tima/OpenVMS-CRTL-Java-C-Illegal_seek-lucene-Problem_with_running_any_lucene_based_Java_code.html Looks like Java on openVMS makes some software -- lucene among them -- 0xdeadbeef. Thanks, ~t~ On Thu, Oct 13, 2011 at 2:58 PM, Benson Margulies bimargul...@gmail.com wrote: Just to put the cork in this, the backtrace at the end proves that Apache Lucene doesn't work in your OpenVMS environment. Words cannot express my lack of surprise. - 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
With knowing the details about our environment
would you expect that Lucene written in clean Java
is not operating on such a platform?
Without a comprehensive analysis of the source code for Lucene (and
potentially, some or all of its dependencies) it is impossible to say
anything conclusive about how well it may operate on OpenVMS or any
other operating system except for those explicitly supported (and
tested) by the dev team. Java isn't truly write-once run-anywhere,
despite such claims ~10-15 years back.
I looked at your stacktrace and the problem seemed to be related to a
NumberFormatException thrown by java.lang.Long.parseLong() that is not
being caught and handled by Lucene:
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)
I found a Lucene JIRA issue that is loosely related:
https://issues.apache.org/jira/browse/LUCENE-3008
Looks like line 211 in trunk is the issue (was line 199 in the stacktrace):
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/SegmentInfos.java?view=markup
The source code is:
return Long.parseLong(fileName.substring(1+IndexFileNames.SEGMENTS.length()),
Character.MAX_RADIX);
A quick look at the Java API shows:
http://download.oracle.com/javase/1,5.0/docs/api/java/lang/Long.html#parseLong(java.lang.String,%20int)
An exception of type NumberFormatException is thrown if any of the
following situations occurs:
* Any character of the string is not a digit of the specified
radix, except that the first character may be a minus sign '-'
('\u002d') provided that the string is longer than length 1.
The decimal character in the string 1. is not valid in the radix
defined by Character.MAX_RADIX. So, you'll need to figure out where
that filename of 1. is coming from -- either OpenVMS or Lucene --
and somehow get rid of the decimal in the filename. Or just rename
that file from 1. to simply 1 in your filesystem.
Without access to an OpenVMS system and having no real understanding
of Lucene's internals, I can't really look into it any more at this
point. You probably need to email the Lucene Users list and ask if
anyone has successfully gotten it to run on OpenVMS (I'm guessing not)
and get things patched up before you can make more progress with
getting Nexus running on it. Or take the more reasonable approach and
simply install Nexus on a Windows box in your office. ;-)
Wayne
-
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
Putting on my pointy hat with the stars on it, I'm predicting that
various APIs of the File object return strings ending in . on
OpenVMS whether you want them to or not. Lucene creates a file that it
thinks is named '1', (or something ending with '1') and OpenVMS
helpfully decides that it's name is actually '1.', and that's what
comes out of the File APIs that list files in a directory. And it's
all downhill from there. Given OpenVMs's rather antediluvian file
system architecture, nothing about this should surprise anyone.
On Thu, Oct 20, 2011 at 5:51 PM, Wayne Fay wayne...@gmail.com wrote:
With knowing the details about our environment
would you expect that Lucene written in clean Java
is not operating on such a platform?
Without a comprehensive analysis of the source code for Lucene (and
potentially, some or all of its dependencies) it is impossible to say
anything conclusive about how well it may operate on OpenVMS or any
other operating system except for those explicitly supported (and
tested) by the dev team. Java isn't truly write-once run-anywhere,
despite such claims ~10-15 years back.
I looked at your stacktrace and the problem seemed to be related to a
NumberFormatException thrown by java.lang.Long.parseLong() that is not
being caught and handled by Lucene:
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)
I found a Lucene JIRA issue that is loosely related:
https://issues.apache.org/jira/browse/LUCENE-3008
Looks like line 211 in trunk is the issue (was line 199 in the stacktrace):
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/SegmentInfos.java?view=markup
The source code is:
return
Long.parseLong(fileName.substring(1+IndexFileNames.SEGMENTS.length()),
Character.MAX_RADIX);
A quick look at the Java API shows:
http://download.oracle.com/javase/1,5.0/docs/api/java/lang/Long.html#parseLong(java.lang.String,%20int)
An exception of type NumberFormatException is thrown if any of the
following situations occurs:
* Any character of the string is not a digit of the specified
radix, except that the first character may be a minus sign '-'
('\u002d') provided that the string is longer than length 1.
The decimal character in the string 1. is not valid in the radix
defined by Character.MAX_RADIX. So, you'll need to figure out where
that filename of 1. is coming from -- either OpenVMS or Lucene --
and somehow get rid of the decimal in the filename. Or just rename
that file from 1. to simply 1 in your filesystem.
Without access to an OpenVMS system and having no real understanding
of Lucene's internals, I can't really look into it any more at this
point. You probably need to email the Lucene Users list and ask if
anyone has successfully gotten it to run on OpenVMS (I'm guessing not)
and get things patched up before you can make more progress with
getting Nexus running on it. Or take the more reasonable approach and
simply install Nexus on a Windows box in your office. ;-)
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
Re: Problems with MAVEN's-ANT on OpenVMS
Just to put the cork in this, the backtrace at the end proves that Apache Lucene doesn't work in your OpenVMS environment. Words cannot express my lack of surprise. - 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
++ sometimes inside an ant target maven gets called by a mvn . . . task/macro ; in this context, ANT already knows about the proxy info. But how is this information passed to maven now? If maven retrieves proxy setting from MAVEN_OPTS environment variable under any circumstances, then fine, if not, how is this passed to maven from a ant section in a pom? So the question may be allowed: does maven pick-up MAVEN_OPTS proxy information when called from within a ANT task? This seems to be more of a question for the Ant folks or something you could determine by looking at their source code. You're asking what does Ant do when I have a mvn task in my build.xml file which I simply can't answer. Wayne - 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
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 josef.stadelm...@axa-winterthur.ch 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 get task 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 wayne...@gmail.com 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
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: Problems with MAVEN's-ANT on OpenVMS
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: Decide on a version string that you will use for your version of this Ant build (if 1.7.1 is the base, I might call yours 1.7.1-AXA). Make your own version of Ant's binaries (supposedly you've already done this). Install those binaries into Maven's cache using the mvn install command with proper parameters. Note: this install step will need to be performed on every system and across every user account that utilizes these modified Ant binaries since you are not using a Maven Repo Manager. Change you pom files to refer to this specific version of Ant using version[your.version.here]/version. Execute your build and watch Maven use those Ant binaries instead of the default. It really is that simple. can we make maven use our ant by changing pom.xml or better have a more global approach/setup such as in a settings.xml? The global approach involves a parent (corporate) pom that specifies the Ant version and which you inherit in all your children poms. And ideally you'd have Nexus installed and your various Maven instances pointing to Nexus for artifacts so you didn't need to manually install them everywhere. Wayne - 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
On Wed, Oct 5, 2011 at 3:43 AM, Wayne Fay wayne...@gmail.com 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 write the documentation into the Ant plugin and provide a patch. - 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
I was never expecting that maven is using it's own ANT ! Its not using its own Ant. It simply does not use the Ant that you previously installed but rather uses the Ant jars directly from its cache. Now with maven it just did not work and the reason why is: Maven uses it's own ANT lib files !!! I was not expecting that maven reinvents the wheel. It doesn't. This is a failure of your understanding of how Maven works. So then - be it as it is --- how can we enforce maven to use a particular installed ANT version and not use the maven-internal ANT ? You simply need to release your own version of Ant using a specific version eg 1.8-JOSEPH and then specifically depend on that version in your Maven pom. You probably want to lock down the version with version[1.8-JOSEPH]/version to prevent Maven from helpfully using a different version. You could use a real version like 1.8.2 but realize that **will** cause problems in the future if/when Ant releases their own version 1.8.2 jars. Deploy your Ant version to your Repo Manager (assuming you are using Nexus et al) and you should be all set. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
