Re: releasing a multi-modult project
assuming that the project that succeeds is the aggregator root, everything is fine. prepare runs on the aggregator root and tags from that root. just run perform and it will check out all the modules and release them. if it is not the aggregator root, you may have to release each scm root separately. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 11 Jan 2012 00:02, Greg Babcock greg.babc...@testadvantagesoftware.com wrote: I inherited a multi-module project from someone that is no-longer with the company. I have Maven experience, but not with multi-module projects. Release prepare is succeeding for the first module, and is skipping the remainder of the modules. How do I get release prepare to prepare all modules? NFO] [INFO] Reactor Summary: [INFO] [INFO] Production . SUCCESS [13.131s] [INFO] Hibernate Service .. SKIPPED [INFO] Production Commons . SKIPPED [INFO] Host Adapter ... SKIPPED [INFO] Web Service Host .. SKIPPED [INFO] Web Service Client SKIPPED [INFO] File Host Adapter Service .. SKIPPED [INFO] HostAdapterService SKIPPED [INFO] Socket Host Adapter Service SKIPPED [INFO] Engineering Client Service SKIPPED [INFO] Standard Service ... SKIPPED [INFO] High Availability Service .. SKIPPED [INFO] Production Web Application . SKIPPED [INFO] Step One ... SKIPPED [INFO] Production Utilities ... SKIPPED [INFO] Production License Creator . SKIPPED [INFO] Configuration Service .. SKIPPED [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 13.917s [INFO] Finished at: Tue Jan 10 17:51:03 EST 2012 [INFO] Final Memory: 5M/15M Thanks, GB
Re: How to run a maven goal when there is tests failures?
you may have to override the default phases, disable surefire (as you cannot unbind from lifecycle), and change the includes pattern for failsafe to the surefire one. if you do the above, should have no side effects other than your intended as they both use the same back end - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 11 Jan 2012 07:32, Xavier S. xavier.seign...@gmail.com wrote: :) Sorry, I missed your answer in the noise! I'll give it a try and let you know. (I hope it won't have side effects using failsafe rather than surefire). Regards, Xavier 2012/1/10 Stephen Connolly stephen.alan.conno...@gmail.com given that nobody else bothered to read the original question, it does not surprise me that nobody bothered to read my original answer of using failsafe ;-) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 10 Jan 2012 18:16, Stephen Connolly stephen.alan.conno...@gmail.com wrote: use failsafe. parse the failsafe results yourself... if they show a test failure, do your special thing then let failsafe verify stop the build - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 10 Jan 2012 16:58, Xavier S. xavier.seign...@gmail.com wrote: Thanks Guillaume! That's exactly what I want to do. So people, any idea? Regards, Xavier 2012/1/10 Guillaume Polet guillaume.po...@gmail.com Tell me if I am wrong Xavier, but I think that what he would like to do is perform something special when the tests fail, not just skip them or not fail the build. My guess would be that he is expecting some kind of on failure/on tests failure phase where he could attach other maven plugins to perform alternate behaviour. Unfortunately I have no idea on how this could be done. Probably using Ant or by writing your own plugin, but I find both solutions quite poor. Maybe Maven is not the tool to be used to perform this. Although you can do a lot of things with Maven, sometimes bending its original objectives too far away is just cumbersome and counter-productive /(not sure this english, btw). /Cheers, Guillaume Le 10/01/2012 17:22, Jeff MAURY a écrit : what about http://maven.apache.org/**plugins/maven-surefire-plugin/**test-mojo.html# **testFailureIgnore http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#testFailureIgnore Jeff MAURY On Tue, Jan 10, 2012 at 4:55 PM, Xavier S. xavier.seign...@gmail.com ** wrote: Thanks for all your answers, but I think I should re explain my need. I don't want to skip the tests. The default fail fast mode of maven suits me (section 6.1.8 http://www.sonatype.com/books/**mvnref-book/reference/running-** sect-options.html http://www.sonatype.com/books/mvnref-book/reference/running-sect-options.html ). I just want to run my custom mojo just after my tests failures and just before the end of the maven execution (if there is build failures, maven do not even finishes the current test phase). Regards, Xavier
Re: How to run a maven goal when there is tests failures?
Although I did see your answer, I did not understand how failsafe was resolving the problem, I do now. Cheers, Guillaume Le 10/01/2012 19:19, Stephen Connolly a écrit : given that nobody else bothered to read the original question, it does not surprise me that nobody bothered to read my original answer of using failsafe ;-) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 10 Jan 2012 18:16, Stephen Connollystephen.alan.conno...@gmail.com wrote: use failsafe. parse the failsafe results yourself... if they show a test failure, do your special thing then let failsafe verify stop the build - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 10 Jan 2012 16:58, Xavier S.xavier.seign...@gmail.com wrote: Thanks Guillaume! That's exactly what I want to do. So people, any idea? Regards, Xavier 2012/1/10 Guillaume Poletguillaume.po...@gmail.com Tell me if I am wrong Xavier, but I think that what he would like to do is perform something special when the tests fail, not just skip them or not fail the build. My guess would be that he is expecting some kind of on failure/on tests failure phase where he could attach other maven plugins to perform alternate behaviour. Unfortunately I have no idea on how this could be done. Probably using Ant or by writing your own plugin, but I find both solutions quite poor. Maybe Maven is not the tool to be used to perform this. Although you can do a lot of things with Maven, sometimes bending its original objectives too far away is just cumbersome and counter-productive /(not sure this english, btw). /Cheers, Guillaume Le 10/01/2012 17:22, Jeff MAURY a écrit : what about http://maven.apache.org/**plugins/maven-surefire-plugin/**test-mojo.html# **testFailureIgnore http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#testFailureIgnore Jeff MAURY On Tue, Jan 10, 2012 at 4:55 PM, Xavier S.xavier.seign...@gmail.com ** wrote: Thanks for all your answers, but I think I should re explain my need. I don't want to skip the tests. The default fail fast mode of maven suits me (section 6.1.8 http://www.sonatype.com/books/**mvnref-book/reference/running-** sect-options.html http://www.sonatype.com/books/mvnref-book/reference/running-sect-options.html ). I just want to run my custom mojo just after my tests failures and just before the end of the maven execution (if there is build failures, maven do not even finishes the current test phase). Regards, Xavier - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Minimize an Uber Jar correctly, Using Shade-Plugin
Moving to Users list as this is a question for people developing WITH maven not a question for people developing maven. At present there is no solution, other than having those classes referenced from a referenced class. Shade has no way of knowing that you use properties files to pull in classes via dynamic class loading, as there are sooo sooo many ways you could set that up. While we are on dev@m.a.o A fix would be to allow you to specify classes that should be retained in the minimized jar as a plugin parameter. Would you like to try and write a patch to shade for such a feature? If you are willing to take a shot, please open a JIRA, attach the patch (with tests if you want to stand a chance of getting the patch applied) and give me or the dev@m.a.o list a ping and somebody will apply the patch (assuming you have written tests and used the Maven formatting, but once you have a patch written we can help you get that stuff sorted) It would be relatively easy to do, just not an itch that any of the current committers has needed to scratch. -Stephen On 11 January 2012 09:46, Blitz, Shmuel sbl...@nds.com wrote: Dear fellows, I am using the Maven-Shade-Plugin to create a runnable Uber-jar. According to the last frame on maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html, the size of the jar can be minimized by using: configuration minimizeJartrue/minimizeJar /configuration But this feature does not take into consideration the classes that are declared in the log4j.properties file. Hence, e.g. org.apache.log4j.appender.TimeAndSizeRollingAppender is not included in the Uber-jar, even though it's declared in the log4j.properties file. I believe I will face the same problem with Spring. If my code only refers to interface A and my Spring file contains an instantiation of class B that implements A, then B might not be added to the jar, since it's not in the code. How can I solve this problem? You input will be highly appreciated. Thanks in advance, Shmuel Blitz This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. An NDS Group Limited company. www.nds.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Webminifier Maven Plugin 1.0.0 Released
Hi Cristopher, What is the difference between this plugin and http://alchim.sourceforge.net/yuicompressor-maven-plugin/index.html Best regards / Met vriendelijke groet, Kees van Dieren Squins | IT, Honestly Oranjestraat 23 2983 HL Ridderkerk The Netherlands Phone: +31 (0)180 415559 Mobile: +31 (0)6 30413841 www.squins.com http://twitter.com/keesvandieren Chamber of commerce Rotterdam: 24435130 Boeken voor school en werk bestel je op studieboekencenter.nl 2012/1/9 Christopher Hunt hu...@internode.on.net Hi, The Mojo team is pleased to announce the release of the Webminifier Maven Plugin version 1.0.0. This plugin provides JavaScript minification for Maven projects. It produces a minified version of JavaScript resources which can be used to construct a minified final artefact. It is designed to be flexible in the way it operates to allow for easy minified resource re-use across a project. Under the hood, Webminifier currently uses the YUI Compressor and Closure Compiler but has a layer of abstraction around these tools which allows for other tools to be used. http://mojo.codehaus.org/webminifier-maven-plugin/ We recommend the use of this plugin in the context of the forthcoming Javascript Maven Tools project (1). Alternatively to get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdwebminifier-maven-plugin/artifactId version1.0.0/version /plugin The plugin is being heavily used by at least two large corporations. Enjoy, The Mojo team. Christopher Hunt (1) http://mojo.codehaus.org/javascript-maven-tools/
maven-jar-plugin:2.3.1:jar (default-jar)
Hi , I am getting following error ,plz help INFO] [INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ ReferentialDataWS --- Jan 11, 2012 4:06:31 PM org.sonatype.guice.bean.reflect.LoadedClass WARNING: Error injecting: org.apache.maven.plugin.jar.JarMojo java.lang.NoClassDefFoundError: Lorg/codehaus/plexus/archiver/jar/JarArchiver; at java.lang.Class.getDeclaredFields0(Native Method) at java.lang.Class.privateGetDeclaredFields(Class.java:2291) at java.lang.Class.getDeclaredFields(Class.java:1743) at com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:649) at com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPoint.java:356) at com.google.inject.internal.ConstructorBindingImpl.getInternalDependencies(ConstructorBindingImpl.java:151) at com.google.inject.internal.InjectorImpl.getInternalDependencies(InjectorImpl.java:584) at com.google.inject.internal.InjectorImpl.cleanup(InjectorImpl.java:542) at com.google.inject.internal.InjectorImpl.initializeJitBinding(InjectorImpl.java:528) at com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:837) at com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:769) at com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:254) at com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:205) at com.google.inject.internal.InjectorImpl.getInternalFactory(InjectorImpl.java:843) at com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:957) at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:990) at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:951) at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1003) at org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:47) at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) at com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:968) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1014) at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:964) at com.google.inject.Scopes$1$1.get(Scopes.java:59) at org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:79) at org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:53) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:243) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:235) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:455) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:92) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) 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:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 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:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: java.lang.ClassNotFoundException: org.codehaus.plexus.archiver.jar.JarArchiver at
RE: Could we delete old version jar in local repository by mvn ?
Hi! I think you should even in this case use a different directory on your local filesystem to deploy your proprietary artifacts to. Isn't that best practise? Think of making backups of your deployed artifacts and not of the whole cached artifacts from the internet. Mixing things in the same type of repositories leads to more confusion and is not reproducable. Best Alex It's not a cache for another reason... mvn install:install-file where you install proprietary artifacts into your local repo when working on proprietary code and you don't have a proper repository manager to host them on. So you really have to know why each artifact is there and where it came from before you can just delete it at random. - Bruker Daltonik GmbH Fahrenheitstrasse 4 Gesch?ftsf?hrer Sitz der Gesellschaft 28359 BremenFrank Laukien, Ph. D. Bremen Germany Gerd H?lso Sebastian Meyer-Plath Bruker Daltonik GmbHStefan Ruge Handelsregister Zweigniederlassung Leipzig Dr.Ian Sanders, Ph. D. Amtsgericht Bremen Dr. Michael Schubert HRB 8150 Permoserstrasse 15 Dr. Michael Schubert www.bdal.de 04318 Leipzig Germany Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich f?r die ordnungsgem??e, vollst?ndige und verz?gerungsfreie ?bertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend best?tigt wird. Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Could we delete old version jar in local repository by mvn ?
actually, no, in that case I would recommend downloading a repository manager and running it locally. Running Maven without a repository manager is like driving a car with a 24inch spike pointing out of the middle of the steering wheel On 11 January 2012 12:31, Rueegg Alexander a...@bdal.de wrote: Hi! I think you should even in this case use a different directory on your local filesystem to deploy your proprietary artifacts to. Isn't that best practise? Think of making backups of your deployed artifacts and not of the whole cached artifacts from the internet. Mixing things in the same type of repositories leads to more confusion and is not reproducable. Best Alex It's not a cache for another reason... mvn install:install-file where you install proprietary artifacts into your local repo when working on proprietary code and you don't have a proper repository manager to host them on. So you really have to know why each artifact is there and where it came from before you can just delete it at random. - Bruker Daltonik GmbH Fahrenheitstrasse 4 Gesch?ftsf?hrer Sitz der Gesellschaft 28359 Bremen Frank Laukien, Ph. D. Bremen Germany Gerd H?lso Sebastian Meyer-Plath Bruker Daltonik GmbH Stefan Ruge Handelsregister Zweigniederlassung Leipzig Dr.Ian Sanders, Ph. D. Amtsgericht Bremen Dr. Michael Schubert HRB 8150 Permoserstrasse 15 Dr. Michael Schubert www.bdal.de 04318 Leipzig Germany Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich f?r die ordnungsgem??e, vollst?ndige und verz?gerungsfreie ?bertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend best?tigt wird. Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax. - - 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: Could we delete old version jar in local repository by mvn ?
On 11/01/2012 8:33 AM, Stephen Connolly wrote: actually, no, in that case I would recommend downloading a repository manager and running it locally. Running Maven without a repository manager is like driving a car with a 24inch spike pointing out of the middle of the steering wheel And a cactus on the driver's seat. Not going to kill you until you hit the breaks but an ongoing source of pain. On 11 January 2012 12:31, Rueegg Alexandera...@bdal.de wrote: Hi! I think you should even in this case use a different directory on your local filesystem to deploy your proprietary artifacts to. Isn't that best practise? Think of making backups of your deployed artifacts and not of the whole cached artifacts from the internet. Mixing things in the same type of repositories leads to more confusion and is not reproducable. Best Alex It's not a cache for another reason... mvn install:install-file where you install proprietary artifacts into your local repo when working on proprietary code and you don't have a proper repository manager to host them on. So you really have to know why each artifact is there and where it came from before you can just delete it at random. - Bruker Daltonik GmbH Fahrenheitstrasse 4 Gesch?ftsf?hrer Sitz der Gesellschaft 28359 BremenFrank Laukien, Ph. D. Bremen Germany Gerd H?lso Sebastian Meyer-Plath Bruker Daltonik GmbHStefan Ruge Handelsregister Zweigniederlassung Leipzig Dr.Ian Sanders, Ph. D. Amtsgericht Bremen Dr. Michael Schubert HRB 8150 Permoserstrasse 15 Dr. Michael Schubert www.bdal.de 04318 Leipzig Germany Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich f?r die ordnungsgem??e, vollst?ndige und verz?gerungsfreie ?bertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend best?tigt wird. Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax. - - 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 -- 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
Howto access project version programmatically within application
A solution to this question appears to have been offered here, in 2007. http://maven.40175.n5.nabble.com/HowTo-access-project-version-programmatically-in-application-td82542.html It references a page explaining how to do it. That page is now gone: http://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/main/java/org/apache/maven/execution/DefaultRuntimeInformation.java Does this page or another more advanced way to do this now exist? Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Howto access project version programmatically within application
Just google org/apache/maven/execution/DefaultRuntimeInformation.java . http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven/maven-core/2.0.5/org/apache/maven/execution/DefaultRuntimeInformation.java?av=h Cheers, Guillaume Le 11/01/2012 15:03, Steve Cohen a écrit : A solution to this question appears to have been offered here, in 2007. http://maven.40175.n5.nabble.com/HowTo-access-project-version-programmatically-in-application-td82542.html It references a page explaining how to do it. That page is now gone: http://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/main/java/org/apache/maven/execution/DefaultRuntimeInformation.java Does this page or another more advanced way to do this now exist? Thanks. - 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: Could we delete old version jar in local repository by mvn ?
Sorry, but I was confused that you suggested to run mvn install:install-file to deploy proprietary artifacts when you don't have a proper repository manager installed. For sure best is to use a repo manager! -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Mittwoch, 11. Januar 2012 14:33 To: Maven Users List Subject: Re: Could we delete old version jar in local repository by mvn ? actually, no, in that case I would recommend downloading a repository manager and running it locally. Running Maven without a repository manager is like driving a car with a 24inch spike pointing out of the middle of the steering wheel On 11 January 2012 12:31, Rueegg Alexander a...@bdal.de wrote: Hi! I think you should even in this case use a different directory on your local filesystem to deploy your proprietary artifacts to. Isn't that best practise? Think of making backups of your deployed artifacts and not of the whole cached artifacts from the internet. Mixing things in the same type of repositories leads to more confusion and is not reproducable. Best Alex It's not a cache for another reason... mvn install:install-file where you install proprietary artifacts into your local repo when working on proprietary code and you don't have a proper repository manager to host them on. So you really have to know why each artifact is there and where it came from before you can just delete it at random. - Bruker Daltonik GmbH Fahrenheitstrasse 4 Gesch?ftsf?hrer Sitz der Gesellschaft 28359 Bremen Frank Laukien, Ph. D. Bremen Germany Gerd H?lso Sebastian Meyer-Plath Bruker Daltonik GmbH Stefan Ruge Handelsregister Zweigniederlassung Leipzig Dr.Ian Sanders, Ph. D. Amtsgericht Bremen Dr. Michael Schubert HRB 8150 Permoserstrasse 15 Dr. Michael Schubert www.bdal.de 04318 Leipzig Germany Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich f?r die ordnungsgem??e, vollst?ndige und verz?gerungsfreie ?bertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend best?tigt wird. Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax. - - 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: Could we delete old version jar in local repository by mvn ?
I was only pointing out that silly users can do silly things, like installing manually, so saying it is just a cache is incorrect On 11 January 2012 14:34, Rueegg Alexander a...@bdal.de wrote: Sorry, but I was confused that you suggested to run mvn install:install-file to deploy proprietary artifacts when you don't have a proper repository manager installed. For sure best is to use a repo manager! -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Mittwoch, 11. Januar 2012 14:33 To: Maven Users List Subject: Re: Could we delete old version jar in local repository by mvn ? actually, no, in that case I would recommend downloading a repository manager and running it locally. Running Maven without a repository manager is like driving a car with a 24inch spike pointing out of the middle of the steering wheel On 11 January 2012 12:31, Rueegg Alexander a...@bdal.de wrote: Hi! I think you should even in this case use a different directory on your local filesystem to deploy your proprietary artifacts to. Isn't that best practise? Think of making backups of your deployed artifacts and not of the whole cached artifacts from the internet. Mixing things in the same type of repositories leads to more confusion and is not reproducable. Best Alex It's not a cache for another reason... mvn install:install-file where you install proprietary artifacts into your local repo when working on proprietary code and you don't have a proper repository manager to host them on. So you really have to know why each artifact is there and where it came from before you can just delete it at random. - Bruker Daltonik GmbH Fahrenheitstrasse 4 Gesch?ftsf?hrer Sitz der Gesellschaft 28359 Bremen Frank Laukien, Ph. D. Bremen Germany Gerd H?lso Sebastian Meyer-Plath Bruker Daltonik GmbH Stefan Ruge Handelsregister Zweigniederlassung Leipzig Dr.Ian Sanders, Ph. D. Amtsgericht Bremen Dr. Michael Schubert HRB 8150 Permoserstrasse 15 Dr. Michael Schubert www.bdal.de 04318 Leipzig Germany Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich f?r die ordnungsgem??e, vollst?ndige und verz?gerungsfreie ?bertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend best?tigt wird. Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax. - - 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
Re: Howto access project version programmatically within application
Thanks. But according to this: http://maven.apache.org/ref/3.0.4-SNAPSHOT/apidocs/org/apache/maven/execution/DefaultRuntimeInformation.html the getApplicationVersion() method has been deprecated, with no indication as to what I should use instead. Also, it seems that this introduces a dependency on Maven itself within the application. What jar would this be? Thanks again. On 01/11/2012 08:12 AM, Guillaume Polet wrote: Just google org/apache/maven/execution/DefaultRuntimeInformation.java . http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven/maven-core/2.0.5/org/apache/maven/execution/DefaultRuntimeInformation.java?av=h Cheers, Guillaume Le 11/01/2012 15:03, Steve Cohen a écrit : A solution to this question appears to have been offered here, in 2007. http://maven.40175.n5.nabble.com/HowTo-access-project-version-programmatically-in-application-td82542.html It references a page explaining how to do it. That page is now gone: http://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/main/java/org/apache/maven/execution/DefaultRuntimeInformation.java Does this page or another more advanced way to do this now exist? Thanks. - 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: Howto access project version programmatically within application
It appears that this entire class and the interface it is based on are deprecated, in favor of org.apache.maven.rtinfo.RuntimeInformation and org.apache.maven.rtinfo.internal.DefaultRuntimeInformation. But this non-deprecated version of the interface/impl REMOVE the getApplicationVersion() method. What's going on here and what is the approved method for getting the application version now? On 01/11/2012 08:59 AM, Steve Cohen wrote: Thanks. But according to this: http://maven.apache.org/ref/3.0.4-SNAPSHOT/apidocs/org/apache/maven/execution/DefaultRuntimeInformation.html the getApplicationVersion() method has been deprecated, with no indication as to what I should use instead. Also, it seems that this introduces a dependency on Maven itself within the application. What jar would this be? Thanks again. On 01/11/2012 08:12 AM, Guillaume Polet wrote: Just google org/apache/maven/execution/DefaultRuntimeInformation.java . http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven/maven-core/2.0.5/org/apache/maven/execution/DefaultRuntimeInformation.java?av=h Cheers, Guillaume Le 11/01/2012 15:03, Steve Cohen a écrit : A solution to this question appears to have been offered here, in 2007. http://maven.40175.n5.nabble.com/HowTo-access-project-version-programmatically-in-application-td82542.html It references a page explaining how to do it. That page is now gone: http://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/main/java/org/apache/maven/execution/DefaultRuntimeInformation.java Does this page or another more advanced way to do this now exist? Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Howto access project version programmatically within application
Hm, is this really heading into the direction you intended with your question originally? The api your are looking at is more for maven internal use (or for dealing with maven world (poms, etc.). If your application is into this direction you might find interesting hints with maven plugin development. If you have in mind some kind of application that just happens to use maven as a build platform, then the solution is not in the first place maven specific. (The version of the maven project needs not necessarily be the version of the application, but providing such info to your application is application specif in the first place.) You need to consider in what form said information is to be bundled with your application. (e.g. readable from jar manifest or other resource, read from pom included with jar, provided by a dedicated class to name a few) Second step would be how you access it from there. So, probably you can drop a word or more on the use case involved. Rainer On 11.01.2012 16:07, Steve Cohen wrote: It appears that this entire class and the interface it is based on are deprecated, in favor of org.apache.maven.rtinfo.RuntimeInformation and org.apache.maven.rtinfo.internal.DefaultRuntimeInformation. But this non-deprecated version of the interface/impl REMOVE the getApplicationVersion() method. What's going on here and what is the approved method for getting the application version now? On 01/11/2012 08:59 AM, Steve Cohen wrote: Thanks. But according to this: http://maven.apache.org/ref/3.0.4-SNAPSHOT/apidocs/org/apache/maven/execution/DefaultRuntimeInformation.html the getApplicationVersion() method has been deprecated, with no indication as to what I should use instead. Also, it seems that this introduces a dependency on Maven itself within the application. What jar would this be? Thanks again. On 01/11/2012 08:12 AM, Guillaume Polet wrote: Just google org/apache/maven/execution/DefaultRuntimeInformation.java . http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven/maven-core/2.0.5/org/apache/maven/execution/DefaultRuntimeInformation.java?av=h Cheers, Guillaume Le 11/01/2012 15:03, Steve Cohen a écrit : A solution to this question appears to have been offered here, in 2007. http://maven.40175.n5.nabble.com/HowTo-access-project-version-programmatically-in-application-td82542.html It references a page explaining how to do it. That page is now gone: http://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/main/java/org/apache/maven/execution/DefaultRuntimeInformation.java Does this page or another more advanced way to do this now exist? Thanks. - 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: Howto access project version programmatically within application
On Wed, Jan 11, 2012 at 09:07:29AM -0600, Steve Cohen wrote:
It appears that this entire class and the interface it is based on are
deprecated, in favor of org.apache.maven.rtinfo.RuntimeInformation and
org.apache.maven.rtinfo.internal.DefaultRuntimeInformation.
But this non-deprecated version of the interface/impl REMOVE the
getApplicationVersion() method.
What's going on here and what is the approved method for getting the
application version now?
What he said.
Dunno about *approved*, but in a JAR (or WAR?) in
META-INF/maven/${groupId}/${artifactId} you'll find pom.properties
which contains a 'version' property:
$ cat pom.properties
#Generated by Maven
#Mon Aug 29 13:19:24 EDT 2011
version=1.0-SNAPSHOT
groupId=edu.iupui.ulib.dspace
artifactId=casAuthn
I know that at least one product deserializes this file to discover
its own version number.
One could use resource filtering to produce a customized
allAboutMe.properties explicitly, containing anything Maven knows and
is willing to provide to a filter.
But I too would like to know what the supported method is, and where
that is documented.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Asking whether markets are efficient is like asking whether people are smart.
pgpCrDz1zpYUq.pgp
Description: PGP signature
Re: Howto access project version programmatically within application
Agreed.
I filter-copy a properties file with the following:
project.name=${project.name}
project.version=${project.version}
build.date=${build.date}
...
Then I can load this file and have at it.
matt
On Jan 11, 2012, at 7:48 AM, Mark H. Wood wrote:
On Wed, Jan 11, 2012 at 09:07:29AM -0600, Steve Cohen wrote:
It appears that this entire class and the interface it is based on are
deprecated, in favor of org.apache.maven.rtinfo.RuntimeInformation and
org.apache.maven.rtinfo.internal.DefaultRuntimeInformation.
But this non-deprecated version of the interface/impl REMOVE the
getApplicationVersion() method.
What's going on here and what is the approved method for getting the
application version now?
What he said.
Dunno about *approved*, but in a JAR (or WAR?) in
META-INF/maven/${groupId}/${artifactId} you'll find pom.properties
which contains a 'version' property:
$ cat pom.properties
#Generated by Maven
#Mon Aug 29 13:19:24 EDT 2011
version=1.0-SNAPSHOT
groupId=edu.iupui.ulib.dspace
artifactId=casAuthn
I know that at least one product deserializes this file to discover
its own version number.
One could use resource filtering to produce a customized
allAboutMe.properties explicitly, containing anything Maven knows and
is willing to provide to a filter.
But I too would like to know what the supported method is, and where
that is documented.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Asking whether markets are efficient is like asking whether people are smart.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Fwd: Re: Howto access project version programmatically within application
Hm, is this really heading into the direction you intended with your question originally? No, it isn't! Thanks. The original link I posted talked about reading the manifest with a dead link explaining this in more detail. Another poster set me off on this blind alley. I think I need to roll my own manifest reader, since I AM encoding the version there, or perhaps read the maven.properties. Original Message Subject: Re: Howto access project version programmatically within application Date: Wed, 11 Jan 2012 16:41:49 +0100 From: Rainer Pruy rainer.p...@acrys.com Reply-To: Maven Users List users@maven.apache.org Organization: Acrys Consult GmbH Co. KG To: users@maven.apache.org Hm, is this really heading into the direction you intended with your question originally? The api your are looking at is more for maven internal use (or for dealing with maven world (poms, etc.). If your application is into this direction you might find interesting hints with maven plugin development. If you have in mind some kind of application that just happens to use maven as a build platform, then the solution is not in the first place maven specific. (The version of the maven project needs not necessarily be the version of the application, but providing such info to your application is application specif in the first place.) You need to consider in what form said information is to be bundled with your application. (e.g. readable from jar manifest or other resource, read from pom included with jar, provided by a dedicated class to name a few) Second step would be how you access it from there. So, probably you can drop a word or more on the use case involved. Rainer On 11.01.2012 16:07, Steve Cohen wrote: It appears that this entire class and the interface it is based on are deprecated, in favor of org.apache.maven.rtinfo.RuntimeInformation and org.apache.maven.rtinfo.internal.DefaultRuntimeInformation. But this non-deprecated version of the interface/impl REMOVE the getApplicationVersion() method. What's going on here and what is the approved method for getting the application version now? On 01/11/2012 08:59 AM, Steve Cohen wrote: Thanks. But according to this: http://maven.apache.org/ref/3.0.4-SNAPSHOT/apidocs/org/apache/maven/execution/DefaultRuntimeInformation.html the getApplicationVersion() method has been deprecated, with no indication as to what I should use instead. Also, it seems that this introduces a dependency on Maven itself within the application. What jar would this be? Thanks again. On 01/11/2012 08:12 AM, Guillaume Polet wrote: Just google org/apache/maven/execution/DefaultRuntimeInformation.java . http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven/maven-core/2.0.5/org/apache/maven/execution/DefaultRuntimeInformation.java?av=h Cheers, Guillaume Le 11/01/2012 15:03, Steve Cohen a écrit : A solution to this question appears to have been offered here, in 2007. http://maven.40175.n5.nabble.com/HowTo-access-project-version-programmatically-in-application-td82542.html It references a page explaining how to do it. That page is now gone: http://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/main/java/org/apache/maven/execution/DefaultRuntimeInformation.java Does this page or another more advanced way to do this now exist? Thanks. - 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: Re: Howto access project version programmatically within application
getClass().getClassLoader().getPackage().getImplementationVersion() On 11 January 2012 16:44, Steve Cohen sco...@javactivity.org wrote: Hm, is this really heading into the direction you intended with your question originally? No, it isn't! Thanks. The original link I posted talked about reading the manifest with a dead link explaining this in more detail. Another poster set me off on this blind alley. I think I need to roll my own manifest reader, since I AM encoding the version there, or perhaps read the maven.properties. Original Message Subject: Re: Howto access project version programmatically within application Date: Wed, 11 Jan 2012 16:41:49 +0100 From: Rainer Pruy rainer.p...@acrys.com Reply-To: Maven Users List users@maven.apache.org Organization: Acrys Consult GmbH Co. KG To: users@maven.apache.org Hm, is this really heading into the direction you intended with your question originally? The api your are looking at is more for maven internal use (or for dealing with maven world (poms, etc.). If your application is into this direction you might find interesting hints with maven plugin development. If you have in mind some kind of application that just happens to use maven as a build platform, then the solution is not in the first place maven specific. (The version of the maven project needs not necessarily be the version of the application, but providing such info to your application is application specif in the first place.) You need to consider in what form said information is to be bundled with your application. (e.g. readable from jar manifest or other resource, read from pom included with jar, provided by a dedicated class to name a few) Second step would be how you access it from there. So, probably you can drop a word or more on the use case involved. Rainer On 11.01.2012 16:07, Steve Cohen wrote: It appears that this entire class and the interface it is based on are deprecated, in favor of org.apache.maven.rtinfo.RuntimeInformation and org.apache.maven.rtinfo.internal.DefaultRuntimeInformation. But this non-deprecated version of the interface/impl REMOVE the getApplicationVersion() method. What's going on here and what is the approved method for getting the application version now? On 01/11/2012 08:59 AM, Steve Cohen wrote: Thanks. But according to this: http://maven.apache.org/ref/3.0.4-SNAPSHOT/apidocs/org/apache/maven/execution/DefaultRuntimeInformation.html the getApplicationVersion() method has been deprecated, with no indication as to what I should use instead. Also, it seems that this introduces a dependency on Maven itself within the application. What jar would this be? Thanks again. On 01/11/2012 08:12 AM, Guillaume Polet wrote: Just google org/apache/maven/execution/DefaultRuntimeInformation.java . http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven/maven-core/2.0.5/org/apache/maven/execution/DefaultRuntimeInformation.java?av=h Cheers, Guillaume Le 11/01/2012 15:03, Steve Cohen a écrit : A solution to this question appears to have been offered here, in 2007. http://maven.40175.n5.nabble.com/HowTo-access-project-version-programmatically-in-application-td82542.html It references a page explaining how to do it. That page is now gone: http://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/main/java/org/apache/maven/execution/DefaultRuntimeInformation.java Does this page or another more advanced way to do this now exist? Thanks. - 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
Re: Howto access project version programmatically within application
On 01/11/2012 10:50 AM, Stephen Connolly wrote: getClass().getClassLoader().getPackage().getImplementationVersion() I really liked the simplicity of this idea. Alas, ClassLoader.getPackage(String) is a protected method, so this won't help. Accessible to me is: Package.getPackage().getImplementationVersion(), which according to Javadocs sounds like it would do the same thing, but this throws a NullPointerException. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Howto access project version programmatically within application
This is referenced from the maven-buildnumber-plugin documentation. http://apollo.ucalgary.ca/tlcprojectswiki/index.php/Public/Project_Versi oning_-_Best_Practices#Build_Versioning Where they do the following (assuming, of course, you've placed the info in your manifest file): String appServerHome = getServletContext().getRealPath(/); File manifestFile = new File(appServerHome, META-INF/MANIFEST.MF); Manifest mf = new Manifest(); mf.read(new FileInputStream(manifestFile)); Attributes atts = mf.getMainAttributes(); System.out.println(Version: + atts.getValue(Implementation-Version)); System.out.println(Build: + atts.getValue(Implementation-Build)); -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: Wednesday, January 11, 2012 10:29 AM To: users@maven.apache.org Subject: Re: Howto access project version programmatically within application On 01/11/2012 10:50 AM, Stephen Connolly wrote: getClass().getClassLoader().getPackage().getImplementationVersion() I really liked the simplicity of this idea. Alas, ClassLoader.getPackage(String) is a protected method, so this won't help. Accessible to me is: Package.getPackage().getImplementationVersion(), which according to Javadocs sounds like it would do the same thing, but this throws a NullPointerException. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org __ This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: releasing a multi-modult project
Thank you Stephen, The aggregator root is the project being that succeeds. I was suspicious about release:prepare because release:perform is failing with an error message that it can't find the pom for the aggregator root in target directory. The target directory is not getting created by release:perform which made me suspicious that it wasn't really passing. Does anyone have any sugestions for resolving the issue with the missing pom file. -Greg -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Wednesday, January 11, 2012 3:27 AM To: Maven Users List Subject: Re: releasing a multi-modult project assuming that the project that succeeds is the aggregator root, everything is fine. prepare runs on the aggregator root and tags from that root. just run perform and it will check out all the modules and release them. if it is not the aggregator root, you may have to release each scm root separately. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 11 Jan 2012 00:02, Greg Babcock greg.babc...@testadvantagesoftware.com wrote: I inherited a multi-module project from someone that is no-longer with the company. I have Maven experience, but not with multi-module projects. Release prepare is succeeding for the first module, and is skipping the remainder of the modules. How do I get release prepare to prepare all modules? NFO] -- -- [INFO] Reactor Summary: [INFO] [INFO] Production . SUCCESS [13.131s] [INFO] Hibernate Service .. SKIPPED [INFO] Production Commons . SKIPPED [INFO] Host Adapter ... SKIPPED [INFO] Web Service Host .. SKIPPED [INFO] Web Service Client SKIPPED [INFO] File Host Adapter Service .. SKIPPED [INFO] HostAdapterService SKIPPED [INFO] Socket Host Adapter Service SKIPPED [INFO] Engineering Client Service SKIPPED [INFO] Standard Service ... SKIPPED [INFO] High Availability Service .. SKIPPED [INFO] Production Web Application . SKIPPED [INFO] Step One ... SKIPPED [INFO] Production Utilities ... SKIPPED [INFO] Production License Creator . SKIPPED [INFO] Configuration Service .. SKIPPED [INFO] -- -- [INFO] BUILD SUCCESS [INFO] -- -- [INFO] Total time: 13.917s [INFO] Finished at: Tue Jan 10 17:51:03 EST 2012 [INFO] Final Memory: 5M/15M Thanks, GB - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Howto access project version programmatically within application
Hmm, intriguing but not working in my case which is a jar, not a war or ear. This is standalone java app. I've tried getResourceAsStream(META_INF/MANIFEST.MF) and getResourceAsStream(/META_INF/MANIFEST.MF) without success even though I've verified that the file exists in the jar, How does one read the manifest from an executable jar? On 01/11/2012 11:35 AM, Matt Walsh wrote: This is referenced from the maven-buildnumber-plugin documentation. http://apollo.ucalgary.ca/tlcprojectswiki/index.php/Public/Project_Versi oning_-_Best_Practices#Build_Versioning Where they do the following (assuming, of course, you've placed the info in your manifest file): String appServerHome = getServletContext().getRealPath(/); File manifestFile = new File(appServerHome, META-INF/MANIFEST.MF); Manifest mf = new Manifest(); mf.read(new FileInputStream(manifestFile)); Attributes atts = mf.getMainAttributes(); System.out.println(Version: + atts.getValue(Implementation-Version)); System.out.println(Build: + atts.getValue(Implementation-Build)); -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: Wednesday, January 11, 2012 10:29 AM To: users@maven.apache.org Subject: Re: Howto access project version programmatically within application On 01/11/2012 10:50 AM, Stephen Connolly wrote: getClass().getClassLoader().getPackage().getImplementationVersion() I really liked the simplicity of this idea. Alas, ClassLoader.getPackage(String) is a protected method, so this won't help. Accessible to me is: Package.getPackage().getImplementationVersion(), which according to Javadocs sounds like it would do the same thing, but this throws a NullPointerException. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org __ This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy. - 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: Howto access project version programmatically within application
getResourceAsStream(META_INF/MANIFEST.MF) and getResourceAsStream(/META_INF/MANIFEST.MF) without success even though I've verified that the file exists in the jar, Uhh that should be META-INF, right? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Howto access project version programmatically within application
Can't help much.
I don't have an elegant way either.
Here is what I did use for long time to get a value from a manifest file
inside a jar:
(it is still poor, but served the purpose.)
(stripped all error handling and specific clutter from application)
final String path = jar:
+
SomeWellKnownClassFromYourApplicationJar.class.getProtectionDomain().getCodeSource().getLocation().toString()
+ !/META-INF/MANIFEST.MF;
final InputStream in = new URL(path).openStream();
if (in != null) {
mf = new Manifest(in);
if (mf != null) {
if (mf.getMainAttributes().getValue(VERSION_TAG) !=
null) {
return
mf.getMainAttributes().getValue(VERSION_TAG);
}
}
}
But I remember you said something about you could not use protected
methods
so this might not work for you
Sorry
Rainer
On 11.01.2012 19:10, Steve Cohen wrote:
Hmm, intriguing but not working in my case which is a jar, not a war
or ear. This is standalone java app.
I've tried
getResourceAsStream(META_INF/MANIFEST.MF) and
getResourceAsStream(/META_INF/MANIFEST.MF) without success even
though I've verified that the file exists in the jar,
How does one read the manifest from an executable jar?
On 01/11/2012 11:35 AM, Matt Walsh wrote:
This is referenced from the maven-buildnumber-plugin documentation.
http://apollo.ucalgary.ca/tlcprojectswiki/index.php/Public/Project_Versi
oning_-_Best_Practices#Build_Versioning
Where they do the following (assuming, of course, you've placed the info
in your manifest file):
String appServerHome = getServletContext().getRealPath(/);
File manifestFile = new File(appServerHome, META-INF/MANIFEST.MF);
Manifest mf = new Manifest();
mf.read(new FileInputStream(manifestFile));
Attributes atts = mf.getMainAttributes();
System.out.println(Version: +
atts.getValue(Implementation-Version));
System.out.println(Build: + atts.getValue(Implementation-Build));
-Original Message-
From: Steve Cohen [mailto:sco...@javactivity.org]
Sent: Wednesday, January 11, 2012 10:29 AM
To: users@maven.apache.org
Subject: Re: Howto access project version programmatically within
application
On 01/11/2012 10:50 AM, Stephen Connolly wrote:
getClass().getClassLoader().getPackage().getImplementationVersion()
I really liked the simplicity of this idea. Alas,
ClassLoader.getPackage(String) is a protected method, so this won't
help.
Accessible to me is:
Package.getPackage().getImplementationVersion(), which according to
Javadocs sounds like it would do the same thing, but this throws a
NullPointerException.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
__
This message, including any attachments, is confidential and contains
information intended only for the person(s) named above. Any other
distribution, copying or disclosure is strictly prohibited. If you
are not the intended recipient or have received this message in
error, please notify us immediately by reply email and permanently
delete the original transmission from all of your systems and hard
drives, including any attachments, without making a copy.
-
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: Howto access project version programmatically within application
This is supposed to work, though I haven't tried it personally: InputStream is = this.getClass().getResourceAsStream(/META-INF/MANIFEST.MF) -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: Wednesday, January 11, 2012 11:10 AM To: users@maven.apache.org Subject: Re: Howto access project version programmatically within application Hmm, intriguing but not working in my case which is a jar, not a war or ear. This is standalone java app. I've tried getResourceAsStream(META_INF/MANIFEST.MF) and getResourceAsStream(/META_INF/MANIFEST.MF) without success even though I've verified that the file exists in the jar, How does one read the manifest from an executable jar? On 01/11/2012 11:35 AM, Matt Walsh wrote: This is referenced from the maven-buildnumber-plugin documentation. http://apollo.ucalgary.ca/tlcprojectswiki/index.php/Public/Project_Vers i oning_-_Best_Practices#Build_Versioning Where they do the following (assuming, of course, you've placed the info in your manifest file): String appServerHome = getServletContext().getRealPath(/); File manifestFile = new File(appServerHome, META-INF/MANIFEST.MF); Manifest mf = new Manifest(); mf.read(new FileInputStream(manifestFile)); Attributes atts = mf.getMainAttributes(); System.out.println(Version: + atts.getValue(Implementation-Version)); System.out.println(Build: + atts.getValue(Implementation- Build)); -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: Wednesday, January 11, 2012 10:29 AM To: users@maven.apache.org Subject: Re: Howto access project version programmatically within application On 01/11/2012 10:50 AM, Stephen Connolly wrote: getClass().getClassLoader().getPackage().getImplementationVersion() I really liked the simplicity of this idea. Alas, ClassLoader.getPackage(String) is a protected method, so this won't help. Accessible to me is: Package.getPackage().getImplementationVersion(), which according to Javadocs sounds like it would do the same thing, but this throws a NullPointerException. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org __ This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy. - 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 __ This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Howto access project version programmatically within application
On 01/11/2012 12:14 PM, Wayne Fay wrote: getResourceAsStream(META_INF/MANIFEST.MF) and getResourceAsStream(/META_INF/MANIFEST.MF) without success even though I've verified that the file exists in the jar, Uhh that should be META-INF, right? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Duh - that's it. However -- fixing that the code now sees the manifest. However, the manifest it sees is not the one that I see when looking at the file in the jar with WinZip. Here is META-INF/MANIFEST.MF in the jar: Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Build-Jdk: 1.6.0_23 Built-By: Steve Implementation-Title: MyApp Implementation-Version: 0.6.1-SNAPSHOT Implementation-Vendor-Id: com.whatever Main-Class: com.whatever.Main SplashScreen-Image: SplashScreen.jpg Yet when my app reads the manifest ( getResourceAsStream(META_INF/MANIFEST.MF ) and then iterates through the manifest attributes, it sees this: Manifest-Version : 1.0 Created-By : 1.4.2 (IBM Corporation) If I specify instead getResourceAsStream(/META_INF/MANIFEST.MF) then the file is not found. I can't make any sense of these symptoms. Manifests are just too weird, it seems. Unless someone can explain this weirdness, I'll try the approach with maven.properties. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Howto access project version programmatically within application
Looks like there are other jar (or classes directories) in classpath. getRessourceAsStream() will access the first entry (according to current classloader logic) and this need not be the one from the jar you are interested in. You might use getRessources() to get all candidates enumerated. (This was what lead me to get an URL from a class that resides with the same jar and explicitly read that file as outlined in my previous reply) Rainer On 11.01.2012 20:41, Steve Cohen wrote: On 01/11/2012 12:14 PM, Wayne Fay wrote: getResourceAsStream(META_INF/MANIFEST.MF) and getResourceAsStream(/META_INF/MANIFEST.MF) without success even though I've verified that the file exists in the jar, Uhh that should be META-INF, right? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Duh - that's it. However -- fixing that the code now sees the manifest. However, the manifest it sees is not the one that I see when looking at the file in the jar with WinZip. Here is META-INF/MANIFEST.MF in the jar: Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Build-Jdk: 1.6.0_23 Built-By: Steve Implementation-Title: MyApp Implementation-Version: 0.6.1-SNAPSHOT Implementation-Vendor-Id: com.whatever Main-Class: com.whatever.Main SplashScreen-Image: SplashScreen.jpg Yet when my app reads the manifest ( getResourceAsStream(META_INF/MANIFEST.MF ) and then iterates through the manifest attributes, it sees this: Manifest-Version : 1.0 Created-By : 1.4.2 (IBM Corporation) If I specify instead getResourceAsStream(/META_INF/MANIFEST.MF) then the file is not found. I can't make any sense of these symptoms. Manifests are just too weird, it seems. Unless someone can explain this weirdness, I'll try the approach with maven.properties. - 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: Howto access project version programatically within application
Thanks for explaining this mysterious result. I have found that using the pom.properties that Maven creates is a more straightforward approach and also can be made to work when the program is not run from the jar (i.e., from Eclipse). Thanks. On 01/11/2012 02:30 PM, Rainer Pruy wrote: Looks like there are other jar (or classes directories) in classpath. getRessourceAsStream() will access the first entry (according to current classloader logic) and this need not be the one from the jar you are interested in. You might use getRessources() to get all candidates enumerated. (This was what lead me to get an URL from a class that resides with the same jar and explicitly read that file as outlined in my previous reply) Rainer On 11.01.2012 20:41, Steve Cohen wrote: On 01/11/2012 12:14 PM, Wayne Fay wrote: getResourceAsStream(META_INF/MANIFEST.MF) and getResourceAsStream(/META_INF/MANIFEST.MF) without success even though I've verified that the file exists in the jar, Uhh that should be META-INF, right? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Duh - that's it. However -- fixing that the code now sees the manifest. However, the manifest it sees is not the one that I see when looking at the file in the jar with WinZip. Here is META-INF/MANIFEST.MF in the jar: Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Build-Jdk: 1.6.0_23 Built-By: Steve Implementation-Title: MyApp Implementation-Version: 0.6.1-SNAPSHOT Implementation-Vendor-Id: com.whatever Main-Class: com.whatever.Main SplashScreen-Image: SplashScreen.jpg Yet when my app reads the manifest ( getResourceAsStream(META_INF/MANIFEST.MF ) and then iterates through the manifest attributes, it sees this: Manifest-Version : 1.0 Created-By : 1.4.2 (IBM Corporation) If I specify instead getResourceAsStream(/META_INF/MANIFEST.MF) then the file is not found. I can't make any sense of these symptoms. Manifests are just too weird, it seems. Unless someone can explain this weirdness, I'll try the approach with maven.properties. - 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: Howto access project version programatically within application
But beware that reading pom.properties might expose similar problem as soon as there is a second jar (or some classes directory) with such file (name). This is intrinsic to anything that uses getResource*() family of methods (at least under the hood) A dirty hack for avoiding that trouble would be to use a file name that likely is unique to your application. Rainer On 11.01.2012 22:13, Steve Cohen wrote: Thanks for explaining this mysterious result. I have found that using the pom.properties that Maven creates is a more straightforward approach and also can be made to work when the program is not run from the jar (i.e., from Eclipse). Thanks. On 01/11/2012 02:30 PM, Rainer Pruy wrote: Looks like there are other jar (or classes directories) in classpath. getRessourceAsStream() will access the first entry (according to current classloader logic) and this need not be the one from the jar you are interested in. You might use getRessources() to get all candidates enumerated. (This was what lead me to get an URL from a class that resides with the same jar and explicitly read that file as outlined in my previous reply) Rainer On 11.01.2012 20:41, Steve Cohen wrote: On 01/11/2012 12:14 PM, Wayne Fay wrote: getResourceAsStream(META_INF/MANIFEST.MF) and getResourceAsStream(/META_INF/MANIFEST.MF) without success even though I've verified that the file exists in the jar, Uhh that should be META-INF, right? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Duh - that's it. However -- fixing that the code now sees the manifest. However, the manifest it sees is not the one that I see when looking at the file in the jar with WinZip. Here is META-INF/MANIFEST.MF in the jar: Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Build-Jdk: 1.6.0_23 Built-By: Steve Implementation-Title: MyApp Implementation-Version: 0.6.1-SNAPSHOT Implementation-Vendor-Id: com.whatever Main-Class: com.whatever.Main SplashScreen-Image: SplashScreen.jpg Yet when my app reads the manifest ( getResourceAsStream(META_INF/MANIFEST.MF ) and then iterates through the manifest attributes, it sees this: Manifest-Version : 1.0 Created-By : 1.4.2 (IBM Corporation) If I specify instead getResourceAsStream(/META_INF/MANIFEST.MF) then the file is not found. I can't make any sense of these symptoms. Manifests are just too weird, it seems. Unless someone can explain this weirdness, I'll try the approach with maven.properties. - 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
Re: Howto access project version programmatically within application
Here's what I made quite awhile ago, in case it helps. http://sidaof.svn.sourceforge.net/viewvc/sidaof/trunk/sidaof-domain/src/main/java/net/sf/sidaof/domain/PomProperties.java?revision=328view=markup On Wed, Jan 11, 2012 at 12:27 PM, Matt Walsh mwa...@chartwelltechnology.com wrote: This is supposed to work, though I haven't tried it personally: InputStream is = this.getClass().getResourceAsStream(/META-INF/MANIFEST.MF) -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: Wednesday, January 11, 2012 11:10 AM To: users@maven.apache.org Subject: Re: Howto access project version programmatically within application Hmm, intriguing but not working in my case which is a jar, not a war or ear. This is standalone java app. I've tried getResourceAsStream(META_INF/MANIFEST.MF) and getResourceAsStream(/META_INF/MANIFEST.MF) without success even though I've verified that the file exists in the jar, How does one read the manifest from an executable jar? On 01/11/2012 11:35 AM, Matt Walsh wrote: This is referenced from the maven-buildnumber-plugin documentation. http://apollo.ucalgary.ca/tlcprojectswiki/index.php/Public/Project_Vers i oning_-_Best_Practices#Build_Versioning Where they do the following (assuming, of course, you've placed the info in your manifest file): String appServerHome = getServletContext().getRealPath(/); File manifestFile = new File(appServerHome, META-INF/MANIFEST.MF); Manifest mf = new Manifest(); mf.read(new FileInputStream(manifestFile)); Attributes atts = mf.getMainAttributes(); System.out.println(Version: + atts.getValue(Implementation-Version)); System.out.println(Build: + atts.getValue(Implementation- Build)); -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: Wednesday, January 11, 2012 10:29 AM To: users@maven.apache.org Subject: Re: Howto access project version programmatically within application On 01/11/2012 10:50 AM, Stephen Connolly wrote: getClass().getClassLoader().getPackage().getImplementationVersion() I really liked the simplicity of this idea. Alas, ClassLoader.getPackage(String) is a protected method, so this won't help. Accessible to me is: Package.getPackage().getImplementationVersion(), which according to Javadocs sounds like it would do the same thing, but this throws a NullPointerException. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org __ This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy. - 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 __ This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy. - 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
help on shade plugin
I am new to maven and am stuck in what might be a very simple issue and need help ... I am trying to create an uber jar using shade and am trying to remove some txt, license files from the final jar, but some how it does not seem to work. Here is the relevant section from my pom.xml when the jar is created and I try to look into the jar, i see the files above in jar. Tried playing around with the configuration options, but nothing seems to be working. I ran maven in -X (debug) mode and can see statements like - However, when I look into the jar, here is what I see: All files that I want removed are still there. Additionally the target folder has two jars sc-1.0.jar which is the uber jar and original-sc-1.0.jar which is the much smaller original jar. What is it that I am doing wrong here? Thanks, V -- View this message in context: http://maven-users.828.n2.nabble.com/help-on-shade-plugin-tp7177360p7177360.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: help on shade plugin
just to add, i tried adding this section to the pom as well, but it just doesnt work: -- View this message in context: http://maven-users.828.n2.nabble.com/help-on-shade-plugin-tp7177360p7177513.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
help on shade plugin
I am new to maven and am stuck in what might be a very simple issue and need help ... I am trying to create an uber jar using shade and am trying to remove some txt, license files from the final jar, but some how it does not seem to work. Here is the relevant section from my pom.xml when the jar is created and I try to look into the jar, i see the files above in jar. Tried playing around with the configuration options, but nothing seems to be working. I ran maven in -X (debug) mode and can see statements like - and However, when I look into the jar, here is what I see: All files that I want removed are still there. Additionally the target folder has two jars sc-1.0.jar which is the uber jar and original-sc-1.0.jar which is the much smaller original jar. What is it that I am doing wrong here? Thanks, Vivek -- View this message in context: http://maven-users.828.n2.nabble.com/help-on-shade-plugin-tp7177703p7177703.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: Howto access project version programatically within application
On 01/11/2012 03:22 PM, Rainer Pruy wrote: But beware that reading pom.properties might expose similar problem as soon as there is a second jar (or some classes directory) with such file (name). This is intrinsic to anything that uses getResource*() family of methods (at least under the hood) A dirty hack for avoiding that trouble would be to use a file name that likely is unique to your application. Rainer On 11.01.2012 22:13, Steve Cohen wrote: Thanks for explaining this mysterious result. I have found that using the pom.properties that Maven creates is a more straightforward approach and also can be made to work when the program is not run from the jar (i.e., from Eclipse). Thanks. Hmm. See my reply to your original post. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Howto access project version programatically within application
On 01/11/2012 03:22 PM, Rainer Pruy wrote: But beware that reading pom.properties might expose similar problem as soon as there is a second jar (or some classes directory) with such file (name). This is intrinsic to anything that uses getResource*() family of methods (at least under the hood) A dirty hack for avoiding that trouble would be to use a file name that likely is unique to your application. Rainer Actually, this is not a problem. The pom.properties is accessed by an URL such as META-INF/maven/com.whatever/MyApp/pom.properties, which should be unique. This is not the case with META-INF/MANIFEST.MF. Steve - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Gaah! I just managed to waste an hour hunting down an issue with a suddenly failing release after a parent of a parent was changed to use version 2.2.2 of the release plugin. The worst is that I now recall I saw this thread a week ago. Kalle On Tue, Jan 3, 2012 at 1:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: that is because you are using maven-release-plugin 2.2.1 switch to 2.2.2 and see how you feel - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 3 Jan 2012 20:58, Jesse Farinacci jie...@gmail.com wrote: Greetings, On Tue, Jan 3, 2012 at 3:45 PM, Mark Derricutt m...@talios.com wrote: Surely something as egregious as allowing releases to break should block 3.0.4 from being released tho. As someone who uses GPG in that manner for some of his releases I'd certainly want 3.0.4 to be able to release... It didn't stop the 3.0.3 release, what's the difference with 3.0.4? It's getting rather frustrating at seeing all these relatively solitary or edge-case problems derail the entire release process. I have performed many releases with 3.0.3 and 3.0.4-rcX both, so this is not a problem for me, and I dare say it's a very large majority of users that it is also not a problem for. Stop stopping the presses, please!! It's just a stupid point release! It doesn't have to solve every existing MNG-* out there! This kind of localized Chicken Little behavior is making it harder and harder to get small releases out the door. You're making it worse for all users. *sigh* (the same goes for all the bike shedding whiners about the dependency fetch timeout - you know who you are) -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
