On OpenVMS, with JDK 1.5, and maven 3.0 I can download now perfectly forcing basic authentication toward our proxy server.
But as downloading artefacts from repositories works now perfect, I want to do bigger steps. i.e. building the svnkit so here we go IA64>mvn "-Dhttp.auth.preference=Basic --version" Apache Maven 3.0 (r1036088; 2010-11-23 18:19:59+0100) Java version: 1.5.0 Java home: /dkb3/java$150/jre Default locale: en, platform encoding: ISO8859-1 OS name: "openvms" version: "v8.3-1h1" arch: "ia64" Family: "openvms" IA64> IA64> set default dkb3:[sw-projekte.asf.svnkit.tags.1_3_3] IA64> IA64>mvn "-Dhttp.auth.preference=Basic clean install" [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building SVNKit 1.3.3 [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ svnkit --- [INFO] [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ svnkit --- [WARNING] Using platform encoding (ISO8859-1 actually) to copy filtered resources, i.e. build is platform dependent! [INFO] skip non existing resourceDirectory /dkb3/sw-projekte/asf/svnkit/tags/1_3_3/src/main/resources [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ svnkit --- [INFO] No sources to compile [INFO] [INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ svnkit --- [WARNING] Using platform encoding (ISO8859-1 actually) to copy filtered resources, i.e. build is platform dependent! [INFO] skip non existing resourceDirectory /dkb3/sw-projekte/asf/svnkit/tags/1_3_3/src/test/resources [INFO] [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ svnkit --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.5:test (default-test) @ svnkit --- [INFO] No tests to run. [INFO] [INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ svnkit --- [WARNING] JAR will be empty - no content was marked for inclusion! [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 6.099s [INFO] Finished at: Thu Jan 13 14:05:34 CET 2011 [INFO] Final Memory: 4M/62M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:2.3.1:jar (default-jar) on project svnkit: Error assembling JAR: Failed to read filesystem attributes for: /dkb3/sw-projekte/asf/svnkit/tags/1_3_3/pom.xml: Failed to retrieve numeric file attributes using: '/bin/sh -c ls -1nlad /dkb3/sw-projekte/asf/svnkit/tags/1_3_3/pom.xml': Error while executing process. Child creation error: no such file or directory -> [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 IA64>dir :-( How can java catch file system attributes better? Why do we use a Unix shell command to create a child prozess (sub-process in openvms) by Java just to catch a file system attribute? Creating child processes is an overkill and slows down maven and other SW when used. This claim is placed - because not every operating system has by default - a Unix command shell - to create a child process - to execute a directory command - just to get a file system attribute! But it seems that on my OpenVMS with default DCL command language, the maven version 3 under java and a JVM attempts to place a command which should create a child process just to execute a ls command used to retrieve a file attribute. I call it a style break, we should not do it from Java and not assume Unix or the like shells avail, or we are at risk that over time fewer system will support what maven attempts to do. Josef.Stadelmann @axa-winterthur.ch
