Re: Call a custom plugin from another project
what i want to do is to force to execute my plugin in a specific phase with a specific goal (my plugin will have only one goal) without declare it i mean that i don't want that the user declare the execution tag as for example i use the jar-plugin -- View this message in context: http://maven.40175.n5.nabble.com/Call-a-custom-plugin-from-another-project-tp5758214p5758280.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: Release dependencies keep getting downloaded
Ok. I managed to check. So no, there is no range like in your example from what I see. The dependency tree tells me that com.sun.xml.ws:jaxws-rt:jar:2.1.7 is referencing version 1.2 and that's it. I just realized that the problem occurs when I'm using the -U option. The help is telling that it Forces a check for updated releases and snapshots on remote. It's a bit weird that rekeases are checked but why not. BUT why is staxex maven-metadata.xml file the only one the keeps being downloaded? (with groovy-eclipse-batch that also is)??? Some timestamp issue? On 29 May 2013 15:40, Stephen Connolly stephen.alan.conno...@gmail.comwrote: it would look something like version[1.7.3,)/version but most likely it will be a transitive dependency that some dependency of yours is pulling in. have a look at the output of dependency:tree On 29 May 2013 14:35, Henri Tremblay henri.tremb...@gmail.com wrote: A version range? How can I have a version range in a dependency tree? Aren't dependencies always fixed values? How can I check that? On 29 May 2013 14:34, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I would guess you might have a version range in your dependency tree On 29 May 2013 13:30, Henri Tremblay henri.tremb...@gmail.com wrote: Hi, Some of metadata.xml files are downloaded for every build done from Jenkins. I don't know why. One example is org.jvnet.staxex:stax-ex:1.7.1 -X doesn't tell me anything How can I find out? (including where to put a breakpoint in the maven source code) Thanks Henri
Re: Call a custom plugin from another project
Maven has a couple of default packaging types that have defined lifecycles. e.g. `jar`, `war`, `ear`, etc. If you don't specify `packaging` then Maven assumes that your project is `packagingjar/packaging` by default. Maven will then consult its registry of lifecycles and see the lifecycle for the `jar` (or whatever packaging you specified - assuming it exists) and based on that lifecycle it will add the plugin executions defined by the lifecycle. So, for example, if you don't specify a `packaging` then the `jar` lifecycle will be assumes, and the `jar` lifecycle binds `jar:jar` to the `package` phase. So you have (at first look) three choices: 1. Get your plugin goals added to the default lifecycle(s) in the appropriate phases 2. Define a custom lifecycle (with a corresponding custom packaging type) 3. Put up with having to define `executions` in the `pom.xml` Now, #1 is *never* going to happen for 99.99% of plugins. As that would push your plugin executions onto *every* Maven user. Changing the default lifecycles is not something we do on a whim. So let's cross that off your list of options. #3 is the one you are trying to avoid, so that leaves #2. How will #2 look? Well as you are defining a custom lifecycle, you will need to tell Maven about this custom packaging type. To do that you have to register the custom packaging type with Maven. This will require EITHER adding `extensionstrue/extensions` to the `plugin` section in the `pom.xml` using your custom packaging OR adding a `extension` to the `build` section. So, what I am saying is that there is no way you can have your plugin *magically* executed against a project which has not been informed of your plugins existence in some way or other... you will either have project ... build ... plugins ... plugin groupIdyour-group-id/groupId artifactIdyour-maven-plugin/artifactId versionx.y.z/version ... executions !-- some configuration goes here -- /executions ... /plugin ... /plugins ... /build ... /project or you will have project ... packagingyour-packaging/packaging ... build ... plugins ... plugin groupIdyour-group-id/groupId artifactIdyour-maven-plugin/artifactId versionx.y.z/version ... extensionstrue/extensions ... /plugin ... /plugins ... /build ... /project or you will have project ... packagingyour-packaging/packaging ... build ... extensions ... extension groupIdyour-group-id/groupId artifactIdyour-packaging-definition/artifactId versionx.y.z/version /extension ... /extensions ... /build ... /project Note: you could have the extensions registered in the parent (works for either the /project/build/plugins/plugin/extensions route or the /project/build/extensions/extension route), which might simplify things if you are building multiple modules of the same packaging. So it is really a question of picking which is the least pain. See http://developer-blog.cloudbees.com/2013/04/the-maven-way.html for some hints as to the end-game direction you want to head towards. Finally, the `execution` section does not have to be too bad. If you specify a default phase when you define your mojo, you can usually get away with just execution goals goalmy-goal/goal /goals /execution or if you have multiple goals with different default phases, you can have execution goals goalmy-goal/goal goalmy-other-goal/goal /goals /execution And they will execute against their respective default phases... you only need multiple `execution` sections with their own `id` for the case where you want to override / have to specify the `phase` HTH -Stephen On 5 June 2013 10:23, alesky alessandro.dotta...@gmail.com wrote: what i want to do is to force to execute my plugin in a specific phase with a specific goal (my plugin will have only one goal) without declare it i mean that i don't want that the user declare the execution tag as for example i use the jar-plugin -- View this message in context: http://maven.40175.n5.nabble.com/Call-a-custom-plugin-from-another-project-tp5758214p5758280.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: Release dependencies keep getting downloaded
dependency:tree when used on Maven 3.x can give slightly confusing results as the closest reference with the same version as the winning reference to the dependency is the reference that is shown. So you could have the dependency somewhere else in your dependency tree (i.e. somewhere with a higher priority than jaxws-rt) but because there is a closer dependency with the same resolved version, dependency:tree shows it as originating from the closer source confusing I know! On 5 June 2013 10:48, Henri Tremblay henri.tremb...@gmail.com wrote: Ok. I managed to check. So no, there is no range like in your example from what I see. The dependency tree tells me that com.sun.xml.ws:jaxws-rt:jar:2.1.7 is referencing version 1.2 and that's it. I just realized that the problem occurs when I'm using the -U option. The help is telling that it Forces a check for updated releases and snapshots on remote. It's a bit weird that rekeases are checked but why not. BUT why is staxex maven-metadata.xml file the only one the keeps being downloaded? (with groovy-eclipse-batch that also is)??? Some timestamp issue? On 29 May 2013 15:40, Stephen Connolly stephen.alan.conno...@gmail.com wrote: it would look something like version[1.7.3,)/version but most likely it will be a transitive dependency that some dependency of yours is pulling in. have a look at the output of dependency:tree On 29 May 2013 14:35, Henri Tremblay henri.tremb...@gmail.com wrote: A version range? How can I have a version range in a dependency tree? Aren't dependencies always fixed values? How can I check that? On 29 May 2013 14:34, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I would guess you might have a version range in your dependency tree On 29 May 2013 13:30, Henri Tremblay henri.tremb...@gmail.com wrote: Hi, Some of metadata.xml files are downloaded for every build done from Jenkins. I don't know why. One example is org.jvnet.staxex:stax-ex:1.7.1 -X doesn't tell me anything How can I find out? (including where to put a breakpoint in the maven source code) Thanks Henri
RE: Release dependencies keep getting downloaded
it is possible the remote repositories cannot be reached so a metadata stub is put into your local repository indicating the attributes of the plugin maven is looking for..here is an example ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.opensymphony/groupId artifactIdxwork/artifactId version2.1.6-SNAPSHOT/version versioning snapshot timestamp20090909.201054/timestamp buildNumber1/buildNumber /snapshot lastUpdated20090909201054/lastUpdated /versioning /metadata personally I always install all necessary plugins to my local-repository and then operate off of my local repository to avoid any guesswork on which repository is online or offline mvn -o $COMMAND can you send us your pom.xml and the exact command syntax with a list of all the repositories you are referencing from $M2_HOME/conf/settings.xml so we can replicate this issue Bon Chance, Martin __ Note de déni et de confidentialité 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: henri.tremb...@gmail.com Date: Wed, 5 Jun 2013 11:48:27 +0200 Subject: Re: Release dependencies keep getting downloaded To: users@maven.apache.org Ok. I managed to check. So no, there is no range like in your example from what I see. The dependency tree tells me that com.sun.xml.ws:jaxws-rt:jar:2.1.7 is referencing version 1.2 and that's it. I just realized that the problem occurs when I'm using the -U option. The help is telling that it Forces a check for updated releases and snapshots on remote. It's a bit weird that rekeases are checked but why not. BUT why is staxex maven-metadata.xml file the only one the keeps being downloaded? (with groovy-eclipse-batch that also is)??? Some timestamp issue? On 29 May 2013 15:40, Stephen Connolly stephen.alan.conno...@gmail.comwrote: it would look something like version[1.7.3,)/version but most likely it will be a transitive dependency that some dependency of yours is pulling in. have a look at the output of dependency:tree On 29 May 2013 14:35, Henri Tremblay henri.tremb...@gmail.com wrote: A version range? How can I have a version range in a dependency tree? Aren't dependencies always fixed values? How can I check that? On 29 May 2013 14:34, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I would guess you might have a version range in your dependency tree On 29 May 2013 13:30, Henri Tremblay henri.tremb...@gmail.com wrote: Hi, Some of metadata.xml files are downloaded for every build done from Jenkins. I don't know why. One example is org.jvnet.staxex:stax-ex:1.7.1 -X doesn't tell me anything How can I find out? (including where to put a breakpoint in the maven source code) Thanks Henri
RE: Call a custom plugin from another project
Take a look at this tutorial to get you started binding your plugin to user-selected phase http://books.sonatype.com/mvnref-book/reference/writing-plugins-sect-plugins-lifecycle.html Bon Chance, Martin __ Note de déni et de confidentialité 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. Date: Tue, 4 Jun 2013 19:57:55 +0200 Subject: Re: Call a custom plugin from another project From: m...@batmat.net To: users@maven.apache.org If I understand correctly, you want to be able to execute your plugin without having to declare it. If so then your are on the right path since the only way to do that is to create a custom lifecycle. Hope this helps. Cheers -- Baptiste Le 4 juin 2013 19:17, alesky alessandro.dotta...@gmail.com a écrit : ok Stephen thanks specifying an execution to the plugin it works but i would like to injects an execution in the packaging for the specified plugin project in the way that i can use the plugin in this way, and don't have to force the user to specific the execution but i didn't found any documentation on-line or in the reference guide regarding this point or at list I'm not able to find a correct on-line document to do it what i i found is that in the plugin annotation there is the @execute annotation, but from my understand this annotation is complete different from what i want to do @execute goal=goal This will execute the given goal before execution of this one. The goal name is specified using the prefix:goal notation. @execute phase=phase This will fork an alternate build lifecycle up to the specified phase before continuing to execute the current one. If no lifecycle is specified, Maven will use the lifecycle of the current build. @execute lifecycle=lifecycle phase=phase This will execute the given alternate lifecycle. A custom lifecycle can be defined in META-INF/maven/lifecycles.xml. -- View this message in context: http://maven.40175.n5.nabble.com/Call-a-custom-plugin-from-another-project-tp5758214p5758242.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: Release dependencies keep getting downloaded
I digged a bit and, helped by your thought, seem to have found the cause. We use Nexus to be a mirror of many repositories. All these public repositories are in a group which is defined to be the mirror in our settings.xml. On of these public repositories is JBoss ( https://repository.jboss.org/nexus/content/groups/public/org/jvnet/staxex/stax-ex/). And if you have a look at the url, for version 1.2 there is only a md5 and a sha1. No actual maven-metadata.xml file. My guess is that it's what keeps the download to happen. I tried to put maven central first in the group hoping it will solve the issue. It didn't. Someone have a workaround apart from removing JBoss from there? (or using a higher version of stax-ex which I will need to test) Thanks, Henri On 5 June 2013 12:19, Martin Gainty mgai...@hotmail.com wrote: it is possible the remote repositories cannot be reached so a metadata stub is put into your local repository indicating the attributes of the plugin maven is looking for..here is an example ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.opensymphony/groupId artifactIdxwork/artifactId version2.1.6-SNAPSHOT/version versioning snapshot timestamp20090909.201054/timestamp buildNumber1/buildNumber /snapshot lastUpdated20090909201054/lastUpdated /versioning /metadata personally I always install all necessary plugins to my local-repository and then operate off of my local repository to avoid any guesswork on which repository is online or offline mvn -o $COMMAND can you send us your pom.xml and the exact command syntax with a list of all the repositories you are referencing from $M2_HOME/conf/settings.xml so we can replicate this issue Bon Chance, Martin __ Note de déni et de confidentialité 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: henri.tremb...@gmail.com Date: Wed, 5 Jun 2013 11:48:27 +0200 Subject: Re: Release dependencies keep getting downloaded To: users@maven.apache.org Ok. I managed to check. So no, there is no range like in your example from what I see. The dependency tree tells me that com.sun.xml.ws:jaxws-rt:jar:2.1.7 is referencing version 1.2 and that's it. I just realized that the problem occurs when I'm using the -U option. The help is telling that it Forces a check for updated releases and snapshots on remote. It's a bit weird that rekeases are checked but why not. BUT why is staxex maven-metadata.xml file the only one the keeps being downloaded? (with groovy-eclipse-batch that also is)??? Some timestamp issue? On 29 May 2013 15:40, Stephen Connolly stephen.alan.conno...@gmail.com wrote: it would look something like version[1.7.3,)/version but most likely it will be a transitive dependency that some dependency of yours is pulling in. have a look at the output of dependency:tree On 29 May 2013 14:35, Henri Tremblay henri.tremb...@gmail.com wrote: A version range? How can I have a version range in a dependency tree? Aren't dependencies always fixed values? How can I check that? On 29 May 2013 14:34, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I would guess you might have a version range in your dependency tree On 29 May 2013 13:30, Henri Tremblay henri.tremb...@gmail.com wrote: Hi, Some of metadata.xml files are downloaded for every build done from Jenkins. I don't know why. One example is org.jvnet.staxex:stax-ex:1.7.1 -X doesn't tell me anything How can I find out? (including where to put a breakpoint in the maven source code) Thanks Henri
Re: Release dependencies keep getting downloaded
You shouldn't be proxying a Nexus group, but rather the specific repo(s) that you need. /Anders On Wed, Jun 5, 2013 at 1:46 PM, Henri Tremblay henri.tremb...@gmail.comwrote: I digged a bit and, helped by your thought, seem to have found the cause. We use Nexus to be a mirror of many repositories. All these public repositories are in a group which is defined to be the mirror in our settings.xml. On of these public repositories is JBoss ( https://repository.jboss.org/nexus/content/groups/public/org/jvnet/staxex/stax-ex/ ). And if you have a look at the url, for version 1.2 there is only a md5 and a sha1. No actual maven-metadata.xml file. My guess is that it's what keeps the download to happen. I tried to put maven central first in the group hoping it will solve the issue. It didn't. Someone have a workaround apart from removing JBoss from there? (or using a higher version of stax-ex which I will need to test) Thanks, Henri On 5 June 2013 12:19, Martin Gainty mgai...@hotmail.com wrote: it is possible the remote repositories cannot be reached so a metadata stub is put into your local repository indicating the attributes of the plugin maven is looking for..here is an example ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.opensymphony/groupId artifactIdxwork/artifactId version2.1.6-SNAPSHOT/version versioning snapshot timestamp20090909.201054/timestamp buildNumber1/buildNumber /snapshot lastUpdated20090909201054/lastUpdated /versioning /metadata personally I always install all necessary plugins to my local-repository and then operate off of my local repository to avoid any guesswork on which repository is online or offline mvn -o $COMMAND can you send us your pom.xml and the exact command syntax with a list of all the repositories you are referencing from $M2_HOME/conf/settings.xml so we can replicate this issue Bon Chance, Martin __ Note de déni et de confidentialité 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: henri.tremb...@gmail.com Date: Wed, 5 Jun 2013 11:48:27 +0200 Subject: Re: Release dependencies keep getting downloaded To: users@maven.apache.org Ok. I managed to check. So no, there is no range like in your example from what I see. The dependency tree tells me that com.sun.xml.ws:jaxws-rt:jar:2.1.7 is referencing version 1.2 and that's it. I just realized that the problem occurs when I'm using the -U option. The help is telling that it Forces a check for updated releases and snapshots on remote. It's a bit weird that rekeases are checked but why not. BUT why is staxex maven-metadata.xml file the only one the keeps being downloaded? (with groovy-eclipse-batch that also is)??? Some timestamp issue? On 29 May 2013 15:40, Stephen Connolly stephen.alan.conno...@gmail.com wrote: it would look something like version[1.7.3,)/version but most likely it will be a transitive dependency that some dependency of yours is pulling in. have a look at the output of dependency:tree On 29 May 2013 14:35, Henri Tremblay henri.tremb...@gmail.com wrote: A version range? How can I have a version range in a dependency tree? Aren't dependencies always fixed values? How can I check that? On 29 May 2013 14:34, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I would guess you might have a version range in your dependency tree On 29 May 2013 13:30, Henri Tremblay henri.tremb...@gmail.com wrote: Hi, Some of metadata.xml files are downloaded for every build done from Jenkins. I don't know why. One example is org.jvnet.staxex:stax-ex:1.7.1 -X doesn't tell me anything How can I find out? (including where to put a breakpoint in the maven source code) Thanks Henri
DLL Artifact
Hi All, I have searched to death the jni project solutions and would just like a simple solution to a trivial issue, but having difficulty pulling it off. I have the classic jar and dll (I am really not interested the native plugin or packaging the dll in a jar yet, etc. I just don't have the time right now). I know I can manually deploy the dll artifact to our repo and declare a dep etc, then use the dependency module to get it - This is what I've done so far as a quick fix. What I'd like to do is more simple than that in the long run. I want to have the jar and dll projects as modules in a multi-module pom, that's done. parentjar/pom.xml |dll/pom.xml |dll/...my.dll Now I'd just like the dll/pom.xml to say 'do not package a jar, then deploy the dll as the artifact. To disable the jar is easy enough... execution iddefault-jar/id phasenone/phase /execution ...but how to get the dll to automatically deploy on the deploy phase? I know I've see it done somewhere, but just can't find what I need. Thanks in advance. Andy. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release dependencies keep getting downloaded
Why? Maven allows a mirror to be a mirror of many repositories. So why should I avoid it? Knowing that, unless I'm mistaken, doing this grouping prevent maven to look into many repositories for each download. On 5 June 2013 14:15, Anders Hammar and...@hammar.net wrote: You shouldn't be proxying a Nexus group, but rather the specific repo(s) that you need. /Anders On Wed, Jun 5, 2013 at 1:46 PM, Henri Tremblay henri.tremb...@gmail.com wrote: I digged a bit and, helped by your thought, seem to have found the cause. We use Nexus to be a mirror of many repositories. All these public repositories are in a group which is defined to be the mirror in our settings.xml. On of these public repositories is JBoss ( https://repository.jboss.org/nexus/content/groups/public/org/jvnet/staxex/stax-ex/ ). And if you have a look at the url, for version 1.2 there is only a md5 and a sha1. No actual maven-metadata.xml file. My guess is that it's what keeps the download to happen. I tried to put maven central first in the group hoping it will solve the issue. It didn't. Someone have a workaround apart from removing JBoss from there? (or using a higher version of stax-ex which I will need to test) Thanks, Henri On 5 June 2013 12:19, Martin Gainty mgai...@hotmail.com wrote: it is possible the remote repositories cannot be reached so a metadata stub is put into your local repository indicating the attributes of the plugin maven is looking for..here is an example ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.opensymphony/groupId artifactIdxwork/artifactId version2.1.6-SNAPSHOT/version versioning snapshot timestamp20090909.201054/timestamp buildNumber1/buildNumber /snapshot lastUpdated20090909201054/lastUpdated /versioning /metadata personally I always install all necessary plugins to my local-repository and then operate off of my local repository to avoid any guesswork on which repository is online or offline mvn -o $COMMAND can you send us your pom.xml and the exact command syntax with a list of all the repositories you are referencing from $M2_HOME/conf/settings.xml so we can replicate this issue Bon Chance, Martin __ Note de déni et de confidentialité 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: henri.tremb...@gmail.com Date: Wed, 5 Jun 2013 11:48:27 +0200 Subject: Re: Release dependencies keep getting downloaded To: users@maven.apache.org Ok. I managed to check. So no, there is no range like in your example from what I see. The dependency tree tells me that com.sun.xml.ws:jaxws-rt:jar:2.1.7 is referencing version 1.2 and that's it. I just realized that the problem occurs when I'm using the -U option. The help is telling that it Forces a check for updated releases and snapshots on remote. It's a bit weird that rekeases are checked but why not. BUT why is staxex maven-metadata.xml file the only one the keeps being downloaded? (with groovy-eclipse-batch that also is)??? Some timestamp issue? On 29 May 2013 15:40, Stephen Connolly stephen.alan.conno...@gmail.com wrote: it would look something like version[1.7.3,)/version but most likely it will be a transitive dependency that some dependency of yours is pulling in. have a look at the output of dependency:tree On 29 May 2013 14:35, Henri Tremblay henri.tremb...@gmail.com wrote: A version range? How can I have a version range in a dependency tree? Aren't dependencies always fixed values? How can I check that? On 29 May 2013 14:34, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I would guess you might have a version range in your dependency tree On 29 May 2013 13:30, Henri Tremblay henri.tremb...@gmail.com wrote: Hi, Some of metadata.xml files are downloaded for every build done from Jenkins. I don't know why. One example is org.jvnet.staxex:stax-ex:1.7.1 -X doesn't tell me anything How can I find out? (including where to put a breakpoint in the maven source code)
Re: Release dependencies keep getting downloaded
What Anders is saying is that Nexus should not be proxying proxies, but rather proxying the original source. i.e. you have something like http://your-nexus/content/groups/public which is an aggregate view of http://my-nexus/content/groups/public http://his-nexus/content/groups/public What you really should be doing is have it as an aggregate view of http://my-nexus/content/repositories/foo http://my-nexus/content/repositories/bar http://his-nexus/content/repositories/manchu http://his-nexus/content/repositories/barfoo http://repo1.maven.org/maven2 That would allow you to set the priorities for each appropriately and ensure that you have e.g. central hosted artifacts resolved from central. By aggregating the aggregates you have duplicate artifacts and conflicts and start to rely on the priority rules, plus you cannot move and reprioritise content as easily. On 5 June 2013 13:26, Henri Tremblay henri.tremb...@gmail.com wrote: Why? Maven allows a mirror to be a mirror of many repositories. So why should I avoid it? Knowing that, unless I'm mistaken, doing this grouping prevent maven to look into many repositories for each download. On 5 June 2013 14:15, Anders Hammar and...@hammar.net wrote: You shouldn't be proxying a Nexus group, but rather the specific repo(s) that you need. /Anders On Wed, Jun 5, 2013 at 1:46 PM, Henri Tremblay henri.tremb...@gmail.com wrote: I digged a bit and, helped by your thought, seem to have found the cause. We use Nexus to be a mirror of many repositories. All these public repositories are in a group which is defined to be the mirror in our settings.xml. On of these public repositories is JBoss ( https://repository.jboss.org/nexus/content/groups/public/org/jvnet/staxex/stax-ex/ ). And if you have a look at the url, for version 1.2 there is only a md5 and a sha1. No actual maven-metadata.xml file. My guess is that it's what keeps the download to happen. I tried to put maven central first in the group hoping it will solve the issue. It didn't. Someone have a workaround apart from removing JBoss from there? (or using a higher version of stax-ex which I will need to test) Thanks, Henri On 5 June 2013 12:19, Martin Gainty mgai...@hotmail.com wrote: it is possible the remote repositories cannot be reached so a metadata stub is put into your local repository indicating the attributes of the plugin maven is looking for..here is an example ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.opensymphony/groupId artifactIdxwork/artifactId version2.1.6-SNAPSHOT/version versioning snapshot timestamp20090909.201054/timestamp buildNumber1/buildNumber /snapshot lastUpdated20090909201054/lastUpdated /versioning /metadata personally I always install all necessary plugins to my local-repository and then operate off of my local repository to avoid any guesswork on which repository is online or offline mvn -o $COMMAND can you send us your pom.xml and the exact command syntax with a list of all the repositories you are referencing from $M2_HOME/conf/settings.xml so we can replicate this issue Bon Chance, Martin __ Note de déni et de confidentialité 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: henri.tremb...@gmail.com Date: Wed, 5 Jun 2013 11:48:27 +0200 Subject: Re: Release dependencies keep getting downloaded To: users@maven.apache.org Ok. I managed to check. So no, there is no range like in your example from what I see. The dependency tree tells me that com.sun.xml.ws:jaxws-rt:jar:2.1.7 is referencing version 1.2 and that's it. I just realized that the problem occurs when I'm using the -U option. The help is telling that it Forces a check for updated releases and snapshots on remote. It's a bit weird that rekeases are checked but why not. BUT why is staxex maven-metadata.xml file the only one the keeps being downloaded? (with groovy-eclipse-batch that also is)??? Some timestamp issue? On 29 May 2013 15:40, Stephen Connolly stephen.alan.conno...@gmail.com wrote: it would look something like version[1.7.3,)/version but most
Re: DLL Artifact
packagingpom/packaging that stops the deploying a jar when you don't have one problem As for your second issue I would use http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html On 5 June 2013 13:26, Andy andy.gumbre...@orprovision.com wrote: Hi All, I have searched to death the jni project solutions and would just like a simple solution to a trivial issue, but having difficulty pulling it off. I have the classic jar and dll (I am really not interested the native plugin or packaging the dll in a jar yet, etc. I just don't have the time right now). I know I can manually deploy the dll artifact to our repo and declare a dep etc, then use the dependency module to get it - This is what I've done so far as a quick fix. What I'd like to do is more simple than that in the long run. I want to have the jar and dll projects as modules in a multi-module pom, that's done. parentjar/pom.xml |dll/pom.xml |dll/...my.dll Now I'd just like the dll/pom.xml to say 'do not package a jar, then deploy the dll as the artifact. To disable the jar is easy enough... execution iddefault-jar/id phasenone/phase /execution ...but how to get the dll to automatically deploy on the deploy phase? I know I've see it done somewhere, but just can't find what I need. Thanks in advance. Andy. --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release dependencies keep getting downloaded
That is extremely interesting. I'm not sure to understand why it makes a difference. Currently I have: - maven-public-mirror: A nexus group containing: - Maven Central: A proxy for Maven Central - JBoss public: A proxy for JBoss public - ... I can order my proxies in my group. Which seems to be the same as referencing them directly. No? (not that I don't want to change it. I'm just trying to understand) On 5 June 2013 14:34, Stephen Connolly stephen.alan.conno...@gmail.comwrote: What Anders is saying is that Nexus should not be proxying proxies, but rather proxying the original source. i.e. you have something like http://your-nexus/content/groups/public which is an aggregate view of http://my-nexus/content/groups/public http://his-nexus/content/groups/public What you really should be doing is have it as an aggregate view of http://my-nexus/content/repositories/foo http://my-nexus/content/repositories/bar http://his-nexus/content/repositories/manchu http://his-nexus/content/repositories/barfoo http://repo1.maven.org/maven2 That would allow you to set the priorities for each appropriately and ensure that you have e.g. central hosted artifacts resolved from central. By aggregating the aggregates you have duplicate artifacts and conflicts and start to rely on the priority rules, plus you cannot move and reprioritise content as easily. On 5 June 2013 13:26, Henri Tremblay henri.tremb...@gmail.com wrote: Why? Maven allows a mirror to be a mirror of many repositories. So why should I avoid it? Knowing that, unless I'm mistaken, doing this grouping prevent maven to look into many repositories for each download. On 5 June 2013 14:15, Anders Hammar and...@hammar.net wrote: You shouldn't be proxying a Nexus group, but rather the specific repo(s) that you need. /Anders On Wed, Jun 5, 2013 at 1:46 PM, Henri Tremblay henri.tremb...@gmail.com wrote: I digged a bit and, helped by your thought, seem to have found the cause. We use Nexus to be a mirror of many repositories. All these public repositories are in a group which is defined to be the mirror in our settings.xml. On of these public repositories is JBoss ( https://repository.jboss.org/nexus/content/groups/public/org/jvnet/staxex/stax-ex/ ). And if you have a look at the url, for version 1.2 there is only a md5 and a sha1. No actual maven-metadata.xml file. My guess is that it's what keeps the download to happen. I tried to put maven central first in the group hoping it will solve the issue. It didn't. Someone have a workaround apart from removing JBoss from there? (or using a higher version of stax-ex which I will need to test) Thanks, Henri On 5 June 2013 12:19, Martin Gainty mgai...@hotmail.com wrote: it is possible the remote repositories cannot be reached so a metadata stub is put into your local repository indicating the attributes of the plugin maven is looking for..here is an example ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.opensymphony/groupId artifactIdxwork/artifactId version2.1.6-SNAPSHOT/version versioning snapshot timestamp20090909.201054/timestamp buildNumber1/buildNumber /snapshot lastUpdated20090909201054/lastUpdated /versioning /metadata personally I always install all necessary plugins to my local-repository and then operate off of my local repository to avoid any guesswork on which repository is online or offline mvn -o $COMMAND can you send us your pom.xml and the exact command syntax with a list of all the repositories you are referencing from $M2_HOME/conf/settings.xml so we can replicate this issue Bon Chance, Martin __ Note de déni et de confidentialité 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: henri.tremb...@gmail.com Date: Wed, 5 Jun 2013 11:48:27 +0200 Subject: Re: Release dependencies keep getting downloaded To: users@maven.apache.org Ok. I managed to check. So no, there is no range like in your example from what I see. The dependency tree tells me that
Re: Javadoc: single configuration
Hi Stanimir, Stanimir Stamenkov wrote: states it should behave as you expect. May be it is a bug in the javadoc plugin, but I can't say for sure. Do you use the latest (2.9) plugin version? Does it happen with Maven 2 or 3, or both? I'm using maven 3.0.4, java 1.6.0_27 (openjdk), and maven-javadoc-plugin 2.9. Would you like me to file a bug? I couldn't figure out how to create an account on the bug tracker... Ultimately I'm trying to define the javadoc configuration once and have it apply to all invocations of the javadoc plugin. You may try defining the common configuration in a build/pluginManagement section, but again I don't know if it's supposed to work that way (for the reporting configuration) I tried just defining the configuration in the build/pluginManagement sections, but then `mvn site` didn't use it. The workaround I've developed is to define the configuration in the build section and then add an execution for the site phase: execution idsite-javadoc/id phasesite/phase goals goaljavadoc/goal goaltest-javadoc/goal /goals /execution I just tried the workaround this moring and it seems to be working well. Regards, Evan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release dependencies keep getting downloaded
But JBoss public is a mirror of several repositories using the priorities that suit JBoss's requirements, you probably only want a subset of their repositories, especially given that you have Maven Central in the mix also. On 5 June 2013 13:42, Henri Tremblay henri.tremb...@gmail.com wrote: That is extremely interesting. I'm not sure to understand why it makes a difference. Currently I have: - maven-public-mirror: A nexus group containing: - Maven Central: A proxy for Maven Central - JBoss public: A proxy for JBoss public - ... I can order my proxies in my group. Which seems to be the same as referencing them directly. No? (not that I don't want to change it. I'm just trying to understand) On 5 June 2013 14:34, Stephen Connolly stephen.alan.conno...@gmail.com wrote: What Anders is saying is that Nexus should not be proxying proxies, but rather proxying the original source. i.e. you have something like http://your-nexus/content/groups/public which is an aggregate view of http://my-nexus/content/groups/public http://his-nexus/content/groups/public What you really should be doing is have it as an aggregate view of http://my-nexus/content/repositories/foo http://my-nexus/content/repositories/bar http://his-nexus/content/repositories/manchu http://his-nexus/content/repositories/barfoo http://repo1.maven.org/maven2 That would allow you to set the priorities for each appropriately and ensure that you have e.g. central hosted artifacts resolved from central. By aggregating the aggregates you have duplicate artifacts and conflicts and start to rely on the priority rules, plus you cannot move and reprioritise content as easily. On 5 June 2013 13:26, Henri Tremblay henri.tremb...@gmail.com wrote: Why? Maven allows a mirror to be a mirror of many repositories. So why should I avoid it? Knowing that, unless I'm mistaken, doing this grouping prevent maven to look into many repositories for each download. On 5 June 2013 14:15, Anders Hammar and...@hammar.net wrote: You shouldn't be proxying a Nexus group, but rather the specific repo(s) that you need. /Anders On Wed, Jun 5, 2013 at 1:46 PM, Henri Tremblay henri.tremb...@gmail.com wrote: I digged a bit and, helped by your thought, seem to have found the cause. We use Nexus to be a mirror of many repositories. All these public repositories are in a group which is defined to be the mirror in our settings.xml. On of these public repositories is JBoss ( https://repository.jboss.org/nexus/content/groups/public/org/jvnet/staxex/stax-ex/ ). And if you have a look at the url, for version 1.2 there is only a md5 and a sha1. No actual maven-metadata.xml file. My guess is that it's what keeps the download to happen. I tried to put maven central first in the group hoping it will solve the issue. It didn't. Someone have a workaround apart from removing JBoss from there? (or using a higher version of stax-ex which I will need to test) Thanks, Henri On 5 June 2013 12:19, Martin Gainty mgai...@hotmail.com wrote: it is possible the remote repositories cannot be reached so a metadata stub is put into your local repository indicating the attributes of the plugin maven is looking for..here is an example ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.opensymphony/groupId artifactIdxwork/artifactId version2.1.6-SNAPSHOT/version versioning snapshot timestamp20090909.201054/timestamp buildNumber1/buildNumber /snapshot lastUpdated20090909201054/lastUpdated /versioning /metadata personally I always install all necessary plugins to my local-repository and then operate off of my local repository to avoid any guesswork on which repository is online or offline mvn -o $COMMAND can you send us your pom.xml and the exact command syntax with a list of all the repositories you are referencing from $M2_HOME/conf/settings.xml so we can replicate this issue Bon Chance, Martin __ Note de déni et de confidentialité 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
Re: Release dependencies keep getting downloaded
Ok! Got it! Thanks! On 5 June 2013 15:12, Stephen Connolly stephen.alan.conno...@gmail.comwrote: But JBoss public is a mirror of several repositories using the priorities that suit JBoss's requirements, you probably only want a subset of their repositories, especially given that you have Maven Central in the mix also. On 5 June 2013 13:42, Henri Tremblay henri.tremb...@gmail.com wrote: That is extremely interesting. I'm not sure to understand why it makes a difference. Currently I have: - maven-public-mirror: A nexus group containing: - Maven Central: A proxy for Maven Central - JBoss public: A proxy for JBoss public - ... I can order my proxies in my group. Which seems to be the same as referencing them directly. No? (not that I don't want to change it. I'm just trying to understand) On 5 June 2013 14:34, Stephen Connolly stephen.alan.conno...@gmail.com wrote: What Anders is saying is that Nexus should not be proxying proxies, but rather proxying the original source. i.e. you have something like http://your-nexus/content/groups/public which is an aggregate view of http://my-nexus/content/groups/public http://his-nexus/content/groups/public What you really should be doing is have it as an aggregate view of http://my-nexus/content/repositories/foo http://my-nexus/content/repositories/bar http://his-nexus/content/repositories/manchu http://his-nexus/content/repositories/barfoo http://repo1.maven.org/maven2 That would allow you to set the priorities for each appropriately and ensure that you have e.g. central hosted artifacts resolved from central. By aggregating the aggregates you have duplicate artifacts and conflicts and start to rely on the priority rules, plus you cannot move and reprioritise content as easily. On 5 June 2013 13:26, Henri Tremblay henri.tremb...@gmail.com wrote: Why? Maven allows a mirror to be a mirror of many repositories. So why should I avoid it? Knowing that, unless I'm mistaken, doing this grouping prevent maven to look into many repositories for each download. On 5 June 2013 14:15, Anders Hammar and...@hammar.net wrote: You shouldn't be proxying a Nexus group, but rather the specific repo(s) that you need. /Anders On Wed, Jun 5, 2013 at 1:46 PM, Henri Tremblay henri.tremb...@gmail.com wrote: I digged a bit and, helped by your thought, seem to have found the cause. We use Nexus to be a mirror of many repositories. All these public repositories are in a group which is defined to be the mirror in our settings.xml. On of these public repositories is JBoss ( https://repository.jboss.org/nexus/content/groups/public/org/jvnet/staxex/stax-ex/ ). And if you have a look at the url, for version 1.2 there is only a md5 and a sha1. No actual maven-metadata.xml file. My guess is that it's what keeps the download to happen. I tried to put maven central first in the group hoping it will solve the issue. It didn't. Someone have a workaround apart from removing JBoss from there? (or using a higher version of stax-ex which I will need to test) Thanks, Henri On 5 June 2013 12:19, Martin Gainty mgai...@hotmail.com wrote: it is possible the remote repositories cannot be reached so a metadata stub is put into your local repository indicating the attributes of the plugin maven is looking for..here is an example ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.opensymphony/groupId artifactIdxwork/artifactId version2.1.6-SNAPSHOT/version versioning snapshot timestamp20090909.201054/timestamp buildNumber1/buildNumber /snapshot lastUpdated20090909201054/lastUpdated /versioning /metadata personally I always install all necessary plugins to my local-repository and then operate off of my local repository to avoid any guesswork on which repository is online or offline mvn -o $COMMAND can you send us your pom.xml and the exact command syntax with a list of all the repositories you are referencing from $M2_HOME/conf/settings.xml so we can replicate this issue Bon Chance, Martin __ Note de déni et de confidentialité 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
Re: DLL Artifact
You could use the maven native plugin to do this: http://mojo.codehaus.org/maven-native/native-maven-plugin/usage.html dll is one of the options. There is also jnilib as one of the options (I am assuming for linux jni binaries) Thanks, Roy Lyons On 6/5/13 7:26 AM, Andy andy.gumbre...@orprovision.com wrote: Hi All, I have searched to death the jni project solutions and would just like a simple solution to a trivial issue, but having difficulty pulling it off. I have the classic jar and dll (I am really not interested the native plugin or packaging the dll in a jar yet, etc. I just don't have the time right now). I know I can manually deploy the dll artifact to our repo and declare a dep etc, then use the dependency module to get it - This is what I've done so far as a quick fix. What I'd like to do is more simple than that in the long run. I want to have the jar and dll projects as modules in a multi-module pom, that's done. parentjar/pom.xml |dll/pom.xml |dll/...my.dll Now I'd just like the dll/pom.xml to say 'do not package a jar, then deploy the dll as the artifact. To disable the jar is easy enough... execution iddefault-jar/id phasenone/phase /execution ...but how to get the dll to automatically deploy on the deploy phase? I know I've see it done somewhere, but just can't find what I need. Thanks in advance. Andy. - 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: Release dependencies keep getting downloaded
I also happen to know that there are/used to be features in Nexus groups that leave orphan checksum files hanging around. As well as metadata files *I think*... /Anders On Wed, Jun 5, 2013 at 2:34 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: What Anders is saying is that Nexus should not be proxying proxies, but rather proxying the original source. i.e. you have something like http://your-nexus/content/groups/public which is an aggregate view of http://my-nexus/content/groups/public http://his-nexus/content/groups/public What you really should be doing is have it as an aggregate view of http://my-nexus/content/repositories/foo http://my-nexus/content/repositories/bar http://his-nexus/content/repositories/manchu http://his-nexus/content/repositories/barfoo http://repo1.maven.org/maven2 That would allow you to set the priorities for each appropriately and ensure that you have e.g. central hosted artifacts resolved from central. By aggregating the aggregates you have duplicate artifacts and conflicts and start to rely on the priority rules, plus you cannot move and reprioritise content as easily. On 5 June 2013 13:26, Henri Tremblay henri.tremb...@gmail.com wrote: Why? Maven allows a mirror to be a mirror of many repositories. So why should I avoid it? Knowing that, unless I'm mistaken, doing this grouping prevent maven to look into many repositories for each download. On 5 June 2013 14:15, Anders Hammar and...@hammar.net wrote: You shouldn't be proxying a Nexus group, but rather the specific repo(s) that you need. /Anders On Wed, Jun 5, 2013 at 1:46 PM, Henri Tremblay henri.tremb...@gmail.com wrote: I digged a bit and, helped by your thought, seem to have found the cause. We use Nexus to be a mirror of many repositories. All these public repositories are in a group which is defined to be the mirror in our settings.xml. On of these public repositories is JBoss ( https://repository.jboss.org/nexus/content/groups/public/org/jvnet/staxex/stax-ex/ ). And if you have a look at the url, for version 1.2 there is only a md5 and a sha1. No actual maven-metadata.xml file. My guess is that it's what keeps the download to happen. I tried to put maven central first in the group hoping it will solve the issue. It didn't. Someone have a workaround apart from removing JBoss from there? (or using a higher version of stax-ex which I will need to test) Thanks, Henri On 5 June 2013 12:19, Martin Gainty mgai...@hotmail.com wrote: it is possible the remote repositories cannot be reached so a metadata stub is put into your local repository indicating the attributes of the plugin maven is looking for..here is an example ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.opensymphony/groupId artifactIdxwork/artifactId version2.1.6-SNAPSHOT/version versioning snapshot timestamp20090909.201054/timestamp buildNumber1/buildNumber /snapshot lastUpdated20090909201054/lastUpdated /versioning /metadata personally I always install all necessary plugins to my local-repository and then operate off of my local repository to avoid any guesswork on which repository is online or offline mvn -o $COMMAND can you send us your pom.xml and the exact command syntax with a list of all the repositories you are referencing from $M2_HOME/conf/settings.xml so we can replicate this issue Bon Chance, Martin __ Note de déni et de confidentialité 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: henri.tremb...@gmail.com Date: Wed, 5 Jun 2013 11:48:27 +0200 Subject: Re: Release dependencies keep getting downloaded To: users@maven.apache.org Ok. I managed to check. So no, there is no range like in your example from what I see. The dependency tree tells me that com.sun.xml.ws:jaxws-rt:jar:2.1.7 is referencing version 1.2 and that's it. I just realized that the problem occurs when I'm using the -U option. The help is telling that it Forces a check for updated releases and snapshots on
Re: DLL Artifact
Hi Andy, I have the classic jar and dll If you want an even simpler solution, you can build the DLL outside Maven (with e.g. CMake), then put the DLL into src/main/resources so that it is included in the JAR, then use native-lib-loader [1] at runtime to load the library. Regards, Curtis P.S. Of course, if your DLL is large it will bloat your SCM repository unless you use something like git-annex [2]. [1] https://github.com/scijava/native-lib-loader [2] http://git-annex.branchable.com/ On Wed, Jun 5, 2013 at 7:26 AM, Andy andy.gumbre...@orprovision.com wrote: Hi All, I have searched to death the jni project solutions and would just like a simple solution to a trivial issue, but having difficulty pulling it off. I have the classic jar and dll (I am really not interested the native plugin or packaging the dll in a jar yet, etc. I just don't have the time right now). I know I can manually deploy the dll artifact to our repo and declare a dep etc, then use the dependency module to get it - This is what I've done so far as a quick fix. What I'd like to do is more simple than that in the long run. I want to have the jar and dll projects as modules in a multi-module pom, that's done. parentjar/pom.xml |dll/pom.xml |dll/...my.dll Now I'd just like the dll/pom.xml to say 'do not package a jar, then deploy the dll as the artifact. To disable the jar is easy enough... execution iddefault-jar/id phasenone/phase /execution ...but how to get the dll to automatically deploy on the deploy phase? I know I've see it done somewhere, but just can't find what I need. Thanks in advance. Andy. --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: create manifest with jars in multiple directories?
If use the maven-shade-plugin, is the generated jar directly usable in other builds using the dependency mechanism? I had assumed otherwise. Specifying the complete class path is a reasonable option for me, but is there a way to do that without specifying the entire manifest? Thanks, Russ On Jun 4, 2013, at 2:51 PM, Robert Scholte rfscho...@apache.org wrote: How do you decide which artifacts go into which folder? If this is done by hand, then there's your answer: specify the complete classpath yourself. Otherwise I'd suggest to write a custom ManifestResourceTransformer for the maven-shade-plugin. Robert Op Tue, 04 Jun 2013 20:11:21 +0200 schreef Russell Gold r...@gold-family.us: If I enable manifest class path creation, the jar or assembly or shade plugin will create a manifest class path that lists all of my dependencies in the same directory. But what if I need them in different directories? Our current requirements place certain jars in specific directories so that layered products can find them - something I doubt that I could get changed. How could I have Maven take that into consideration? - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! - 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
