From: Cyrus H. <ch...@bo...> - 2014-02-26 17:44:42
|
It’s probably operator error, but I’m having trouble building javadocs in the new source tree. I get the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:aggregate (default-cli) on project cdk: An error has occurred in JavaDocs report generation: Unable to resolve artifact:groupId = 'org.openscience.cdk' [ERROR] artifactId = 'cdk-build-utils' [ERROR] version = '1.0': Missing: [ERROR] ---------- [ERROR] 1) jdk.tools:jdk.tools:jar:1.6.0_65 [ERROR] [ERROR] Try downloading the file manually from the project website. [ERROR] [ERROR] Then, install it using the command: [ERROR] mvn install:install-file -DgroupId=jdk.tools -DartifactId=jdk.tools -Dversion=1.6.0_65 -Dpackaging=jar -Dfile=/path/to/file [ERROR] [ERROR] Alternatively, if you host your own repository you can deploy the file there: [ERROR] mvn deploy:deploy-file -DgroupId=jdk.tools -DartifactId=jdk.tools -Dversion=1.6.0_65 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] [ERROR] [ERROR] Path to dependency: [ERROR] 1) org.openscience.cdk:cdk-build-utils:jar:1.0 [ERROR] 2) jdk.tools:jdk.tools:jar:1.6.0_65 [ERROR] [ERROR] ---------- [ERROR] 1 required artifact is missing. [ERROR] [ERROR] for artifact: [ERROR] org.openscience.cdk:cdk-build-utils:jar:1.0 [ERROR] [ERROR] from the specified remote repositories: [ERROR] ebi-repo (http://www.ebi.ac.uk/intact/maven/nexus/content/repositories/ebi-repo, releases=true, snapshots=true), [ERROR] ebi-repo-snapshots (http://www.ebi.ac.uk/intact/maven/nexus/content/repositories/ebi-repo-snapshots, releases=true, snapshots=true), [ERROR] central (http://repo.maven.apache.org/maven2, releases=true, snapshots=false), [ERROR] ebi-repo-3rd (http://www.ebi.ac.uk/~maven/m2repo, releases=true, snapshots=true), [ERROR] jni-inchi (http://jni-inchi.sourceforge.net/m2repo, releases=true, snapshots=false) [ERROR] -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:aggregate (default-cli) on project cdk: An error has occurred in JavaDocs report generation: Unable to resolve artifact:groupId = 'org.openscience.cdk' artifactId = 'cdk-build-utils' version = '1.0' at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: org.apache.maven.plugin.MojoExecutionException: An error has occurred in JavaDocs report generation: Unable to resolve artifact:groupId = 'org.openscience.cdk' artifactId = 'cdk-build-utils' version = '1.0' at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.failOnError(AbstractJavadocMojo.java:5826) at org.apache.maven.plugin.javadoc.JavadocReport.execute(JavadocReport.java:319) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 19 more Caused by: org.apache.maven.reporting.MavenReportException: Unable to resolve artifact:groupId = 'org.openscience.cdk' artifactId = 'cdk-build-utils' version = '1.0' at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.getArtifactsAbsolutePath(AbstractJavadocMojo.java:3302) at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.getTagletPath(AbstractJavadocMojo.java:2854) at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.addStandardDocletOptions(AbstractJavadocMojo.java:4706) at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1945) at org.apache.maven.plugin.javadoc.JavadocReport.generate(JavadocReport.java:130) at org.apache.maven.plugin.javadoc.JavadocReport.execute(JavadocReport.java:315) ... 21 more Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: ---------- 1) jdk.tools:jdk.tools:jar:1.6.0_65 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=jdk.tools -DartifactId=jdk.tools -Dversion=1.6.0_65 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=jdk.tools -DartifactId=jdk.tools -Dversion=1.6.0_65 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.openscience.cdk:cdk-build-utils:jar:1.0 2) jdk.tools:jdk.tools:jar:1.6.0_65 ---------- 1 required artifact is missing. for artifact: org.openscience.cdk:cdk-build-utils:jar:1.0 from the specified remote repositories: ebi-repo (http://www.ebi.ac.uk/intact/maven/nexus/content/repositories/ebi-repo, releases=true, snapshots=true), ebi-repo-snapshots (http://www.ebi.ac.uk/intact/maven/nexus/content/repositories/ebi-repo-snapshots, releases=true, snapshots=true), central (http://repo.maven.apache.org/maven2, releases=true, snapshots=false), ebi-repo-3rd (http://www.ebi.ac.uk/~maven/m2repo, releases=true, snapshots=true), jni-inchi (http://jni-inchi.sourceforge.net/m2repo, releases=true, snapshots=false) at org.apache.maven.artifact.resolver.DefaultResolutionErrorHandler.throwErrors(DefaultResolutionErrorHandler.java:71) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:355) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:343) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:318) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:287) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:266) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:297) at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.getArtifactsAbsolutePath(AbstractJavadocMojo.java:3283) ... 26 more [ERROR] [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 Oh, did I mention that I hate maven? :) thanks, Cyrus |
From: John M. <joh...@gm...> - 2014-02-26 20:52:35
|
It’s looking for the JDK tools dependency - this is a system dependency. If java is installed correctly it is located - ${java.home}/../lib/tools.jar try this from the command line, what do you get? ls $JAVA_HOME/lib |
From: Cyrus H. <ch...@bo...> - 2014-02-26 20:56:24
|
d’oh! forgot about JAVA_HOME yet again… thanks! On Feb 26, 2014, at 12:52 PM, John May <joh...@gm...> wrote: > ls $JAVA_HOME/lib |
From: John M. <joh...@gm...> - 2014-02-26 20:56:47
|
Which JDK are you using? According to docs this is correct for the default location. http://maven.apache.org/general.html#tools-jar-dependency J On 26 Feb 2014, at 20:52, John May <joh...@gm...> wrote: > It’s looking for the JDK tools dependency - this is a system dependency. If java is installed correctly it is located - > > ${java.home}/../lib/tools.jar > > try this from the command line, what do you get? > > ls $JAVA_HOME/lib |
From: Cyrus H. <ch...@bo...> - 2014-03-13 21:00:36
|
Following up on this from long ago, it turns out JAVA_HOME wasn’t properly set. I think that fixed things. But now on to my next issue with the new source tree… I’ve been installing a build from the new version which gets installed as 1.5.6-SNAPSHOT. This is fine until some time passes and I have some other maven-equipped software that triggers a resolution (is this the right term?) of the maven dependencies and it goes and looks at EBI for a newer version of the snapshot. Not necessarily what i want. How do others deal with this problem? Just using the version from EBI? I suppose I should figure out how to make the other maven-equipped piece of software work in offline mode, but that isn’t necessarily the best solution. One option I’ve considered is renaming the version to something like 1.5.6-LOCAL, but that brings me to my next problem, which is that it seems that the version is hardcoded in each of the pom.xml files. find . -name pom.xml | xargs grep -i 1.5.6-snapshot | wc -l tells me that there are 70 files with the version hardcoded. Do we fire off some sort of sed/perl script to change this automatically when a new release is called for? Surely there must be a way to store this information once and refer to that rather than sprinkling it throughout pom files scattered across the tree. thanks, Cyrus On Feb 26, 2014, at 12:56 PM, John May <joh...@gm...> wrote: > Which JDK are you using? According to docs this is correct for the default location. > > http://maven.apache.org/general.html#tools-jar-dependency > > J > > On 26 Feb 2014, at 20:52, John May <joh...@gm...> wrote: > >> It’s looking for the JDK tools dependency - this is a system dependency. If java is installed correctly it is located - >> >> ${java.home}/../lib/tools.jar >> >> try this from the command line, what do you get? >> >> ls $JAVA_HOME/lib > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel |
From: John M. <joh...@gm...> - 2014-03-13 21:17:39
|
Hi Cyrus, To ensure the local version is used, don’t include the ebi snapshot repository in the configuration of downstream project. Repositories should be defined on a per-project database. To change the version in the XML you can use - http://mojo.codehaus.org/versions-maven-plugin/, no additional configuration needed. I would recommend just removing the repository though as it keeps things cleanr. > mvn versions:set -DnewVersion=1.5.6-LOCAL The versions are stored separately as some project increment the module versions independently. This is a lot more work, and makes things very confusing but basically if there are no changes to a module since the last release the existing version can be used. You can do this locally, if for example I made a change to fix the fingerprints, I could change just that version and use that in the downstream project. > mvn versions:set -DnewVersion=1.5.6-withfpfix -DartifactId=cdk-version J On 13 Mar 2014, at 21:00, Cyrus Harmon <ch...@bo...> wrote: > > Following up on this from long ago, it turns out JAVA_HOME wasn’t properly set. I think that fixed things. > > But now on to my next issue with the new source tree… I’ve been installing a build from the new version which gets installed as 1.5.6-SNAPSHOT. This is fine until some time passes and I have some other maven-equipped software that triggers a resolution (is this the right term?) of the maven dependencies and it goes and looks at EBI for a newer version of the snapshot. Not necessarily what i want. How do others deal with this problem? Just using the version from EBI? I suppose I should figure out how to make the other maven-equipped piece of software work in offline mode, but that isn’t necessarily the best solution. > > One option I’ve considered is renaming the version to something like 1.5.6-LOCAL, but that brings me to my next problem, which is that it seems that the version is hardcoded in each of the pom.xml files. find . -name pom.xml | xargs grep -i 1.5.6-snapshot | wc -l tells me that there are 70 files with the version hardcoded. Do we fire off some sort of sed/perl script to change this automatically when a new release is called for? Surely there must be a way to store this information once and refer to that rather than sprinkling it throughout pom files scattered across the tree. > > thanks, > > Cyrus > > On Feb 26, 2014, at 12:56 PM, John May <joh...@gm...> wrote: > >> Which JDK are you using? According to docs this is correct for the default location. >> >> http://maven.apache.org/general.html#tools-jar-dependency >> >> J >> >> On 26 Feb 2014, at 20:52, John May <joh...@gm...> wrote: >> >>> It’s looking for the JDK tools dependency - this is a system dependency. If java is installed correctly it is located - >>> >>> ${java.home}/../lib/tools.jar >>> >>> try this from the command line, what do you get? >>> >>> ls $JAVA_HOME/lib >> >> ------------------------------------------------------------------------------ >> Flow-based real-time traffic analytics software. Cisco certified tool. >> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer >> Customize your own dashboards, set traffic alerts and generate reports. >> Network behavioral analysis & security monitoring. All-in-one tool. >> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________ >> Cdk-devel mailing list >> Cdk...@li... >> https://lists.sourceforge.net/lists/listinfo/cdk-devel > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech_______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel |
From: John M. <joh...@gm...> - 2014-03-13 21:27:04
|
Ergh, cluttered thoughts: > To ensure the local version is used, don’t include the ebi snapshot repository in the configuration of downstream project. Repositories should be defined on a per-project basis. > > To change the version in the XML you can use - http://mojo.codehaus.org/versions-maven-plugin/, no additional configuration needed. I would recommend just removing the repository though as it keeps things cleaner. > >> mvn versions:set -DnewVersion=1.5.6-LOCAL > > The versions are stored separately as some projects increment the modules independently. This is a lot more work, and makes things very confusing but basically if there are no changes to a module since the last release the existing version can be used. You can also do this locally, if for example I made a change to fix the fingerprints, I could change just that version and use that in the downstream project. > >> mvn versions:set -DnewVersion=1.5.6-withfpfix -DartifactId=cdk-fingerprint > > > J On 13 Mar 2014, at 21:17, John May <joh...@gm...> wrote: > Hi Cyrus, > > To ensure the local version is used, don’t include the ebi snapshot repository in the configuration of downstream project. Repositories should be defined on a per-project database. > > To change the version in the XML you can use - http://mojo.codehaus.org/versions-maven-plugin/, no additional configuration needed. I would recommend just removing the repository though as it keeps things cleanr. > >> mvn versions:set -DnewVersion=1.5.6-LOCAL > > The versions are stored separately as some project increment the module versions independently. This is a lot more work, and makes things very confusing but basically if there are no changes to a module since the last release the existing version can be used. You can do this locally, if for example I made a change to fix the fingerprints, I could change just that version and use that in the downstream project. > >> mvn versions:set -DnewVersion=1.5.6-withfpfix -DartifactId=cdk-version > > > J > > On 13 Mar 2014, at 21:00, Cyrus Harmon <ch...@bo...> wrote: > >> >> Following up on this from long ago, it turns out JAVA_HOME wasn’t properly set. I think that fixed things. >> >> But now on to my next issue with the new source tree… I’ve been installing a build from the new version which gets installed as 1.5.6-SNAPSHOT. This is fine until some time passes and I have some other maven-equipped software that triggers a resolution (is this the right term?) of the maven dependencies and it goes and looks at EBI for a newer version of the snapshot. Not necessarily what i want. How do others deal with this problem? Just using the version from EBI? I suppose I should figure out how to make the other maven-equipped piece of software work in offline mode, but that isn’t necessarily the best solution. >> >> One option I’ve considered is renaming the version to something like 1.5.6-LOCAL, but that brings me to my next problem, which is that it seems that the version is hardcoded in each of the pom.xml files. find . -name pom.xml | xargs grep -i 1.5.6-snapshot | wc -l tells me that there are 70 files with the version hardcoded. Do we fire off some sort of sed/perl script to change this automatically when a new release is called for? Surely there must be a way to store this information once and refer to that rather than sprinkling it throughout pom files scattered across the tree. >> >> thanks, >> >> Cyrus >> >> On Feb 26, 2014, at 12:56 PM, John May <joh...@gm...> wrote: >> >>> Which JDK are you using? According to docs this is correct for the default location. >>> >>> http://maven.apache.org/general.html#tools-jar-dependency >>> >>> J >>> >>> On 26 Feb 2014, at 20:52, John May <joh...@gm...> wrote: >>> >>>> It’s looking for the JDK tools dependency - this is a system dependency. If java is installed correctly it is located - >>>> >>>> ${java.home}/../lib/tools.jar >>>> >>>> try this from the command line, what do you get? >>>> >>>> ls $JAVA_HOME/lib >>> >>> ------------------------------------------------------------------------------ >>> Flow-based real-time traffic analytics software. Cisco certified tool. >>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer >>> Customize your own dashboards, set traffic alerts and generate reports. >>> Network behavioral analysis & security monitoring. All-in-one tool. >>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________ >>> Cdk-devel mailing list >>> Cdk...@li... >>> https://lists.sourceforge.net/lists/listinfo/cdk-devel >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech_______________________________________________ >> Cdk-devel mailing list >> Cdk...@li... >> https://lists.sourceforge.net/lists/listinfo/cdk-devel > |
From: Cyrus H. <ch...@bo...> - 2014-03-13 21:30:14
|
On Mar 13, 2014, at 2:26 PM, John May <joh...@gm...> wrote: > Ergh, cluttered thoughts: > >> To ensure the local version is used, don’t include the ebi snapshot repository in the configuration of downstream project. Repositories should be defined on a per-project basis. Ok, I see. This makes sense… >> >> To change the version in the XML you can use - http://mojo.codehaus.org/versions-maven-plugin/, no additional configuration needed. I would recommend just removing the repository though as it keeps things cleaner. >> >>> mvn versions:set -DnewVersion=1.5.6-LOCAL >> >> The versions are stored separately as some projects increment the modules independently. This is a lot more work, and makes things very confusing but basically if there are no changes to a module since the last release the existing version can be used. You can also do this locally, if for example I made a change to fix the fingerprints, I could change just that version and use that in the downstream project. >> >>> mvn versions:set -DnewVersion=1.5.6-withfpfix -DartifactId=cdk-fingerprint Ok, thanks again! Cyrus |
From: John M. <joh...@gm...> - 2014-03-13 21:50:35
|
No problem, Always happy to help, I've encountered these problems myself :-). Thanks, J On 13 Mar 2014, at 21:00, Cyrus Harmon <ch...@bo...> wrote: > > Following up on this from long ago, it turns out JAVA_HOME wasn’t properly set. I think that fixed things. > > But now on to my next issue with the new source tree… I’ve been installing a build from the new version which gets installed as 1.5.6-SNAPSHOT. This is fine until some time passes and I have some other maven-equipped software that triggers a resolution (is this the right term?) of the maven dependencies and it goes and looks at EBI for a newer version of the snapshot. Not necessarily what i want. How do others deal with this problem? Just using the version from EBI? I suppose I should figure out how to make the other maven-equipped piece of software work in offline mode, but that isn’t necessarily the best solution. > > One option I’ve considered is renaming the version to something like 1.5.6-LOCAL, but that brings me to my next problem, which is that it seems that the version is hardcoded in each of the pom.xml files. find . -name pom.xml | xargs grep -i 1.5.6-snapshot | wc -l tells me that there are 70 files with the version hardcoded. Do we fire off some sort of sed/perl script to change this automatically when a new release is called for? Surely there must be a way to store this information once and refer to that rather than sprinkling it throughout pom files scattered across the tree. > > thanks, > > Cyrus > > On Feb 26, 2014, at 12:56 PM, John May <joh...@gm...> wrote: > >> Which JDK are you using? According to docs this is correct for the default location. >> >> http://maven.apache.org/general.html#tools-jar-dependency >> >> J >> >> On 26 Feb 2014, at 20:52, John May <joh...@gm...> wrote: >> >>> It’s looking for the JDK tools dependency - this is a system dependency. If java is installed correctly it is located - >>> >>> ${java.home}/../lib/tools.jar >>> >>> try this from the command line, what do you get? >>> >>> ls $JAVA_HOME/lib >> >> ------------------------------------------------------------------------------ >> Flow-based real-time traffic analytics software. Cisco certified tool. >> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer >> Customize your own dashboards, set traffic alerts and generate reports. >> Network behavioral analysis & security monitoring. All-in-one tool. >> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________ >> Cdk-devel mailing list >> Cdk...@li... >> https://lists.sourceforge.net/lists/listinfo/cdk-devel > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech_______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel |
From: Nina J. <jel...@gm...> - 2014-03-14 05:10:56
|
Just my 2 cents ;) On 13 March 2014 23:50, John May <joh...@gm...> wrote: > No problem, > > Always happy to help, I've encountered these problems myself :-). > > Thanks, > J > > On 13 Mar 2014, at 21:00, Cyrus Harmon <ch...@bo...> wrote: > > > Following up on this from long ago, it turns out JAVA_HOME wasn’t properly > set. I think that fixed things. > > But now on to my next issue with the new source tree… I’ve been installing > a build from the new version which gets installed as 1.5.6-SNAPSHOT. This > is fine until some time passes and I have some other maven-equipped > software that triggers a resolution (is this the right term?) of the maven > dependencies and it goes and looks at EBI for a newer version of the > snapshot. Not necessarily what i want. How do others deal with this > problem? Just using the version from EBI? I suppose I should figure out how > to make the other maven-equipped piece of software work in offline mode, > but that isn’t necessarily the best solution. > > The idea of the SNAPSHOTs is that they are not final and the best practice is to synchronise them with a repository (which is supposed to host the most recent ones). If one doesn't need the very latest dependencies, the best practice is to use not SNAPSHOTS in your own project, but stable releases. They are downloaded once and not supposed to be changed. > > One option I’ve considered is renaming the version to something like > 1.5.6-LOCAL, but that brings me to my next problem, which is that it seems > that the version is hardcoded in each of the pom.xml files. find . -name > pom.xml | xargs grep -i 1.5.6-snapshot | wc -l tells me that there are 70 > files with the version hardcoded. > > This is the normal practice for multimodule projects. You may also notice the dependencies versions are not hard coed, but use the variable ${project.parent.version} Do we fire off some sort of sed/perl script to change this automatically > when a new release is called for? Surely there must be a way to store this > information once and refer to that rather than sprinkling it throughout pom > files scattered across the tree. > > Not sed/perl scripts, but Maven release plugin. It not only automatically changes versions, but verifies coupld of things, tags the release, commits to the code repository, you name it http://maven.apache.org/maven-release/maven-release-plugin/ Hope this helps, Nina [1] http://books.sonatype.com/mvnref-book/reference/ > > thanks, > > Cyrus > > On Feb 26, 2014, at 12:56 PM, John May <joh...@gm...> > wrote: > > Which JDK are you using? According to docs this is correct for the default > location. > > http://maven.apache.org/general.html#tools-jar-dependency > > J > > On 26 Feb 2014, at 20:52, John May <joh...@gm...> wrote: > > It’s looking for the JDK tools dependency - this is a system dependency. > If java is installed correctly it is located - > > ${java.home}/../lib/tools.jar > > try this from the command line, what do you get? > > ls $JAVA_HOME/lib > > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > > http://p.sf.net/sfu/13534_NeoTech_______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > > |
From: Cyrus H. <ch...@bo...> - 2014-03-14 05:16:10
|
On Mar 13, 2014, at 10:10 PM, Nina Jeliazkova <jel...@gm...> wrote: > > The idea of the SNAPSHOTs is that they are not final and the best practice is to synchronise them with a repository (which is supposed to host the most recent ones). > > If one doesn't need the very latest dependencies, the best practice is to use not SNAPSHOTS in your own project, but stable releases. They are downloaded once and not supposed to be changed. I usually like to work with the latest HEAD plus my local patches. To each their own... > One option I’ve considered is renaming the version to something like 1.5.6-LOCAL, but that brings me to my next problem, which is that it seems that the version is hardcoded in each of the pom.xml files. find . -name pom.xml | xargs grep -i 1.5.6-snapshot | wc -l tells me that there are 70 files with the version hardcoded. > > This is the normal practice for multimodule projects. You may also notice the dependencies versions are not hard coed, but use the variable ${project.parent.version} I see the versions in each of the pom.xml files. Are these machine generated? >> Do we fire off some sort of sed/perl script to change this automatically when a new release is called for? Surely there must be a way to store this information once and refer to that rather than sprinkling it throughout pom files scattered across the tree. > > > Not sed/perl scripts, but Maven release plugin. It not only automatically changes versions, but verifies coupld of things, tags the release, commits to the code repository, you name it > > http://maven.apache.org/maven-release/maven-release-plugin/ Ah, OK. Thanks, Cyrus |
From: Nina J. <jel...@gm...> - 2014-03-14 05:23:33
|
On 14 March 2014 07:15, Cyrus Harmon <ch...@bo...> wrote: > > On Mar 13, 2014, at 10:10 PM, Nina Jeliazkova <jel...@gm...> > wrote: > > > The idea of the SNAPSHOTs is that they are not final and the best practice > is to synchronise them with a repository (which is supposed to host the > most recent ones). > > If one doesn't need the very latest dependencies, the best practice is to > use not SNAPSHOTS in your own project, but stable releases. They are > downloaded once and not supposed to be changed. > > > I usually like to work with the latest HEAD plus my local patches. To each > their own... > Then SNAPSHOTS / LOCAL are for you. I used to do the same ... may be in the first couple of years working with the CDK. > > One option I’ve considered is renaming the version to something like > 1.5.6-LOCAL, but that brings me to my next problem, which is that it seems > that the version is hardcoded in each of the pom.xml files. find . -name > pom.xml | xargs grep -i 1.5.6-snapshot | wc -l tells me that there are 70 > files with the version hardcoded. > > This is the normal practice for multimodule projects. You may also notice > the dependencies versions are not hard coed, but use the variable > ${project.parent.version} > > > I see the versions in each of the pom.xml files. Are these machine > generated? > > No, the modules versions are specified manually. If modules are used in another module , then ${project.parent.version} is specified. Regards, Nina > Do we fire off some sort of sed/perl script to change this automatically >> when a new release is called for? Surely there must be a way to store this >> information once and refer to that rather than sprinkling it throughout pom >> files scattered across the tree. >> >> > Not sed/perl scripts, but Maven release plugin. It not only automatically > changes versions, but verifies coupld of things, tags the release, commits > to the code repository, you name it > > http://maven.apache.org/maven-release/maven-release-plugin/ > > > Ah, OK. > > > Thanks, > > Cyrus > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > > |