Re: How to tell EAR packager to use the exact names created by addClasspathtrue/addClasspath?
Well, the bug is that the generated classpath does not match the actual library file names. I haven't looked at the code, but very possibly the bug might not be in the plugin's code but some library used to calculate the classpath (which expects unique snapshot file name). In any case, file the bug report on the plugin and include a test project that will reproduce the problem. Also clearly state what environment (exact Maven version etc.) you're using. /Anders On Sat, Mar 17, 2012 at 15:35, Markus KARG mar...@headcrashing.eu wrote: Maven is 3.0.4 What exactly do you think is the bug: The fact that Class-Path is replacing -SNAPSHOT by version, or the fact that EAR plugin is NOT doing so? Thanks! Markus -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Montag, 12. März 2012 11:21 To: Maven Users List Subject: Re: How to tell EAR packager to use the exact names created by addClasspathtrue/addClasspath? Sounds like a bug when building a multi-module project. File a JIRA ticket with a test project to recreate the issue. Also, if you're not using Maven 3, try to build with that as well to see if that solves the problem. /Anders On Mon, Mar 12, 2012 at 10:06, Markus Karg k...@quipsy.de wrote: I am using the ear and acr plugins to build an ear that contains an app-client. It all works well but one thing is always wrong: The car must use addClasspathtrue/addClasspath so the client will find the needed libraries. When those libraries are SNAPSHOTs, the created manifest entry contains not SNAPSHOT but the latest date (as usual with SNAPSHOTs). But the ear plugin doesn't care for this. It always uses SNAPSHOT (the word, not the latest version). As a result, at runtime the client will not find the needed libraries, as it looks for it by date, but it actually is named SNAPSHOT. For me this looks like a bug in the conception of the EAR plugin: It must not statically build the name from the version string, but it certainly needs to use the actual name of the artifact (here: the date of the snapshot). Is that really a bug or am I too dumb to see the light? ;-) Regards Markus - 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: useing profiles to control properties to drive version numbers in poms
Chad path of least resistance is to set the version of the project in pom.xml
(at top) and then reference project.version e.g.
version${project.version}/version HTH
Martin
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
From: chad.da...@emc.com
To: users@maven.apache.org
Date: Fri, 16 Mar 2012 12:51:03 -0400
Subject: useing profiles to control properties to drive version numbers in
poms
Does anyone have any experience using a property to control the version
numbers in poms? Like, version${myVersion}/version and the myVersion
property can be set in profiles. . .
Thoughts?
Re: Exposing EJB3.1 bean as webservice and use from servlet!?
Hello, can please someone help me. I am at a loss how I can expose an EJB3.1 as a Webservice in a maven project and access this from a Servlet. You will have better luck with this question at the Java Ranch or perhaps StackOverflow. Take out one reference to a Maven plugin (which is not even published/supported by Apache but rather org.jvnet) and this is not a Maven question at all. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, Yes, profiles are evil. If you use them for changing / defining _what_ gets built and/or how, yes. If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. Regards Thorsten
Re: Re: useing profiles to control properties to drive version numbers in poms
If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. I see this as a completely different task where you're simply using Maven as a utility tool. When using Maven as a build tool, you will be deploying the artifacts to a repository. What you then do with the artifacts after that (like e.g. publish to an app server) is outside of the build story, and should be handled as a separate task. You could use Maven to do that, and then you could have any number of profiles to alter the behavior. But I want to stress that that's not a build job. This is my repository-focused view of things. /Anders - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to include librabries when compile with Maven?
Hi All, As you can see from the subject, I am new to Maven. I used to develope, compile and build project using Eclipse, but recently I got some problem with Eclipse with Metro generated code. Someone suggested me that I should compile project using Maven instead Eclipse. So, hear I am. My project relies on many third party libraries, but I am not sure how do I make Maven aware of them? By adding all libraries in the class path might work, but I am looking into reference lib directory name somewhere in my pom.xml. Any suggestions? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion groupIdcom.sdl.airline.metro.clients/groupId artifactIdsoapclient/artifactId version1.0-SNAPSHOT/version packagingjar/packaging namesoapclient/name urlhttp://maven.apache.org/url properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.6/source target1.6/target /configuration /plugin /plugins /build /project Thanks. Gina -- View this message in context: http://maven.40175.n5.nabble.com/How-to-include-librabries-when-compile-with-Maven-tp5572109p5572109.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
exclude dependency from war file during packaging
Hi, My application uses grails 1.3.7. it is using grails-gorm artifact as a dependency. from this artifact, jta.jar is also being added as transitive dependency in my WEB-INF/lib folder. I want to exclude this jar from my war file, but this jar is required during build of the project. The reason behind excluding this jar file is , when i am deploying the war including this jar file on jboss 6.1 I am getting following exception: Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) previously initiated loading for a different type with name javax/transaction/xa/XAResource Please help me in resolving this issue. Thanks in advance. -- View this message in context: http://maven.40175.n5.nabble.com/exclude-dependency-from-war-file-during-packaging-tp5573472p5573472.html Sent from the Maven - Users mailing list archive at Nabble.com.
DependencyResolutionRequiredException with maven-artifact 3.0.4 and maven-archiver 2.5?
Hello, I'm trying to write a maven plugin with a custom packaging format, but having trouble with using the Maven 3 plugins with Maven-Archiver 2.5. I have this in my plugin's pom.xml for dependencies dependency groupIdorg.apache.maven/groupId artifactIdmaven-plugin-api/artifactId version3.0.4/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-artifact/artifactId version3.0.4/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-archiver/artifactId version2.5/version /dependency dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-utils/artifactId version3.0/version /dependency And in my plugin method I have this code to set the archive MavenArchiver archiver = new MavenArchiver(); archiver.setArchiver(jarArchiver); archiver.setOutputFile(artifact); archiver.createArchive(session, project, archive); project.getArtifact().setFile(artifact); But I'm getting an error The type org.apache.maven.artifact.DependencyResolutionRequiredException cannot be resolved. this exception was previously defined in the 2.x series of maven-artifact, but it's not there anymore. I was able to get things to compile using the 2.x series of maven-artifact and maven-plugin-api, but then I had issues using it with maven 3. How do I use maven-archiver 2.5 to implement custom packaging compatible with Maven 3? Jon Marston
Re: exclude dependency from war file during packaging
Greetings, On Sat, Mar 17, 2012 at 7:47 AM, satya1234567 satyaprak...@tataelxsi.co.in wrote: I want to exclude this jar from my war file, but this jar is required during build of the project. scopeprovided/scope -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
Re: How to include librabries when compile with Maven?
Greetings, On Fri, Mar 16, 2012 at 2:30 PM, gchoi gc...@sdl.com wrote: My project relies on many third party libraries, but I am not sure how do I make Maven aware of them? http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html -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
[ANN] Apache Maven Shade Plugin 1.6 Released
The Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 1.6 Hello, This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. http://maven.apache.org/plugins/maven-shade-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version1.6/version /plugin Release Notes - Apache Maven Shade Plugin - Version 1.6 ** Bug * [MSHADE-92] - Annotated Method Parameters Not Shaded * [MSHADE-94] - NullPointerException on empty relocation pattern (default package) * [MSHADE-104] - Cannot shade aspectj library * [MSHADE-105] - Classes processed by the relocator still have references to the original classes in their constant pools ** Improvement * [MSHADE-111] - minimizeJar should not remove classes specifically included by filters ** New Feature * [MSHADE-91] - Allow using external Shader implementation, Have Fun, -- The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: useing profiles to control properties to drive version numbers in poms
On 18/03/2012 5:41 PM, Thorsten Heit wrote: Hi, Yes, profiles are evil. If you use them for changing / defining _what_ gets built and/or how, yes. If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. Not clear that profiles are the right approach for that. You will probably be unhappy going down this road. I might be off-base but it does not sound like the right way to solve that problem. In any event, good luck. I hope that you are able to prove me wrong. Ron Regards Thorsten -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: useing profiles to control properties to drive version numbers in poms
On 18/03/2012 5:53 PM, Anders Hammar wrote: If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. I see this as a completely different task where you're simply using Maven as a utility tool. When using Maven as a build tool, you will be deploying the artifacts to a repository. What you then do with the artifacts after that (like e.g. publish to an app server) is outside of the build story, and should be handled as a separate task. You could use Maven to do that, and then you could have any number of profiles to alter the behavior. But I want to stress that that's not a build job. This is my repository-focused view of things. And a very sensible view at that! /Anders - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to include librabries when compile with Maven?
You might also want to switch from Eclipse to Eclipse STS from the Spring guys. This gives you Eclipse and Maven in the IDE all from a single download. We have used it for a few years now and it is much better than Eclipse on its own. We do no command line Maven. It is all done inside Eclipse STS. Ron On 18/03/2012 7:27 PM, Jesse Farinacci wrote: Greetings, On Fri, Mar 16, 2012 at 2:30 PM, gchoigc...@sdl.com wrote: My project relies on many third party libraries, but I am not sure how do I make Maven aware of them? http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html -Jesse -- 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
