Re: maven3 snapshots in local repo
I would recommend that you use Aether in that non-maven code to interact with remote and local repo. This is what Maven does and it will then ensure you don't run into issues. /Anders On Tue, Sep 25, 2012 at 12:13 AM, Tim Eck t...@terracottatech.com wrote: Using mvn 3.0.4, when a SNAPSHOT artifact is resolved from a remote repo it seems that my local repository ends up with both a -SNAPSHOT artifact and a timestamped version (the remote end has only timestamped versions). I'm curious if I can rely on this behavior since I have other (non-maven) code that interacts with my local maven repo. For example, from a dependency like so: dependency groupIdfoo/groupId artifactIdbar/artifactId version1.0.0-SNAPSHOT/version /dependency I end up with with two identical jars in my local repo after resolving it: bar-1.0.0-20120924.201711-2.jar bar-1.0.0-SNAPSHOT.jar I think the code in org.eclipse.aether.internal.impl.DefaultArtifactResolver::getFile() is responsible for making this additional 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: Ear Plugin skinnyWars EJB problem
Well, okay, I read that instruction. But I may also need to have a WAR artifact including all dependent EJBs in case I want to deploy it as WAR only, no EAR. In this case I still need to preserve original WAR dependencies. And I need m-ear-p to strip them if they're a listed as EAR dependencies (when I configure m-ear-p to produce skinnyWar modules). This doesn't really work. Whatever typejar/type dependencies I have in my EAR artifact get stripped from the WAR. But no typeejb/type EAR dependencies get stripped from WAR. And I can't do a typejar/type on them because I will loose the ejbModule capability (to generate proper application.xml). I guess, there was something in mind when making m-ear-p to skip those typeejb/type dependencies when stripping down WAR artifact. -- View this message in context: http://maven.40175.n5.nabble.com/Ear-Plugin-skinnyWars-EJB-problem-tp563p5723616.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: Ear Plugin skinnyWars EJB problem
In that case WAR Overlays[1] come into picture. Markku [1] http://maven.apache.org/plugins/maven-war-plugin/overlays.html On 09/25/2012 05:57 PM, nskmda wrote: Well, okay, I read that instruction. But I may also need to have a WAR artifact including all dependent EJBs in case I want to deploy it as WAR only, no EAR. In this case I still need to preserve original WAR dependencies. And I need m-ear-p to strip them if they're a listed as EAR dependencies (when I configure m-ear-p to produce skinnyWar modules). This doesn't really work. Whatever typejar/type dependencies I have in my EAR artifact get stripped from the WAR. But no typeejb/type EAR dependencies get stripped from WAR. And I can't do a typejar/type on them because I will loose the ejbModule capability (to generate proper application.xml). I guess, there was something in mind when making m-ear-p to skip those typeejb/type dependencies when stripping down WAR artifact. -- View this message in context: http://maven.40175.n5.nabble.com/Ear-Plugin-skinnyWars-EJB-problem-tp563p5723616.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to put a dependency in the classpath BEFORE jre.jar?
I did never suggest to modify the POM and said no word about any future form of the POM, so I skip your comments about that and right go on with the idea of a Platform: I like some of your idea about the concept of a platform but this is not as trivial as you think. There is the issue of building with JDK5 an artifact to be run on JDK5 or JDK6 The idea of having a Platform interface actually solves exactly that problem, since the JDK5 platform will tell how to build on JDK5, while the JDK6 platform will tell how to build on JDK6. Are you sure that you mean build? What are you building that is different? Yes, I mean *build*. My source code needs the @Resource(lookup = ...) field, which comes with Java EE 6, while Java SE 6 only has @Resource without the field lookup. So my code simply does not build, as long as javaee6.jar ist a simple dependency in the user classpath. I need to have it in the bootstrap classpath. This is why this thread is called How to put a dependency in the classpath BEFORE jre.jar? and the original problem that started it. It still sounds like an installation issue and Package is what an installer builder creates. If you follow the thread to the start you will see that it has nothing to do with packaging. Maven will build the modules that you need to create the package of jars that gets installed. ...and how does that solve the case described by me now for the second time...? ;-) Regards Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to put a dependency in the classpath BEFORE jre.jar?
Markus, If you want to join in on the fun of the development community, please join us on the dev list. As you've heard on this thread, your particular concern smacks into a messy conundrum about our desire to avoid breaking other people's tools that read poms -- no matter how poorly coded. However, there is a design in progress, it needs more refinement, and mostly it will need people to actually code it. --benson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to put a dependency in the classpath BEFORE jre.jar?
I did not read through the whole thread, so maybe I missed (sorry for that). Afaik maven plugins use a different ClassLoader hierarchy than you might expect. Most frameworks use ParentClassLoaderFirst, but maven afaik uses ClientClassLoaderFirst. Which means it's perfectly fine to to put a javax.* dependency in your plugin classpath. The only thing which is not allowed is to overwrite native SE stuff. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Users List users@maven.apache.org Cc: Sent: Tuesday, September 25, 2012 8:08 PM Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? Markus, If you want to join in on the fun of the development community, please join us on the dev list. As you've heard on this thread, your particular concern smacks into a messy conundrum about our desire to avoid breaking other people's tools that read poms -- no matter how poorly coded. However, there is a design in progress, it needs more refinement, and mostly it will need people to actually code it. --benson - 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: strategy for incorporating private jars into a project
Let's say I wanted to automate the process of promoting daily snapshots to the nexus repository, and then configuring the project to always utilize the latest version in the repo. Is there a way to automate incrementing the version number and deploy to nexus? Specifically: I've used the nexus GUI before to manually upload an artifact, but that's it. If I knew the locations of the artifacts built that I need to get to the repo (and that's all I would have -- no POM file, etc), does anyone have a script I could take a look at that would accomplish deploying these to a nexus repo in such a way that projects will always download the latest version? -- View this message in context: http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5723629.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: strategy for incorporating private jars into a project
On 25/09/2012 3:59 PM, mlandman99 wrote: Let's say I wanted to automate the process of promoting daily snapshots to the nexus repository, and then configuring the project to always utilize the latest version in the repo. Is there a way to automate incrementing the version number and deploy to nexus? Specifically: I've used the nexus GUI before to manually upload an artifact, but that's it. If I knew the locations of the artifacts built that I need to get to the repo (and that's all I would have -- no POM file, etc), does anyone have a script I could take a look at that would accomplish deploying these to a nexus repo in such a way that projects will always download the latest version? Could you use the maven plug-ins that write into the repo? -- View this message in context: http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5723629.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 -- 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: strategy for incorporating private jars into a project
Is there a way to automate incrementing the version number and deploy to nexus? versions plugin @ codehaus mojo deploy plugin @ apache maven (deploy-file mojo) Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Ear Plugin skinnyWars EJB problem
Not sure what you mean. A brief sample config? -- View this message in context: http://maven.40175.n5.nabble.com/Ear-Plugin-skinnyWars-EJB-problem-tp563p5723651.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
Geotoolkit snapshot
Hi - I'm working on my first Maven project and find it great but we have run into a small issue. We are using a snap-shot version of the geotoolkit ( http://www.geotoolkit.org/) because of a bug in the current release. We are in testing and am concerned that we could introduce bugs into our application when the snapshot release gets updated nightly. We would prefer to use a specific snapshot (like last nights build) but because of networking issues are reluctant to create our own maven repository. Is there another or better solution? Thanks, Douglas Kunzman 12201 Sunrise Valley Drive Reston, VA 20192
Re: Geotoolkit snapshot
On Tue, September 25, 2012 2:17 pm, Doug Kunzman wrote: Hi - I'm working on my first Maven project and find it great but we have run into a small issue. We are using a snap-shot version of the geotoolkit ( http://www.geotoolkit.org/) because of a bug in the current release. We are in testing and am concerned that we could introduce bugs into our application when the snapshot release gets updated nightly. We would prefer to use a specific snapshot (like last nights build) but because of networking issues are reluctant to create our own maven repository. Especially if you have networking issues you should use a repository manager. Is there another or better solution? You could use the explicit snapshot version number comprised of the datetime stamp and the iterator. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Geotoolkit snapshot
The networking issues are more contractual than performance and availability. The hours available for network administrator support are somewhat limited. Douglas Kunzman 12201 Sunrise Valley Drive Reston, VA 20192 Phone: 703 648-4234 dkunz...@usgs.gov From: Manfred Moser manf...@mosabuam.com To: Maven Users List users@maven.apache.org Date: 09/25/2012 06:28 PM Subject: Re: Geotoolkit snapshot On Tue, September 25, 2012 2:17 pm, Doug Kunzman wrote: Hi - I'm working on my first Maven project and find it great but we have run into a small issue. We are using a snap-shot version of the geotoolkit ( http://www.geotoolkit.org/) because of a bug in the current release. We are in testing and am concerned that we could introduce bugs into our application when the snapshot release gets updated nightly. We would prefer to use a specific snapshot (like last nights build) but because of networking issues are reluctant to create our own maven repository. Especially if you have networking issues you should use a repository manager. Is there another or better solution? You could use the explicit snapshot version number comprised of the datetime stamp and the iterator. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Geotoolkit snapshot
On Tue, September 25, 2012 3:32 pm, Doug Kunzman wrote: The networking issues are more contractual than performance and availability. The hours available for network administrator support are somewhat limited. Even more a reason to look at running a repo manager. In either case.. are these desired snapshots available in a maven snapshot repository somewhere? If so you can lock your version string to a snapshot. However keep in mind that this is bad practice and a snapshot repository is in fact not guaranteed to stay around. In fact they get deleted as regular clean up all the time. Which is where a repo manager comes in again since your manager would still have the artifacts cached and therefore keep your build running. Otherwise your build could suddenly stop working if you are building from scratch and have not downloaded the artifact yet.. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Geotoolkit snapshot
On 25/09/2012 6:32 PM, Doug Kunzman wrote: The networking issues are more contractual than performance and availability. The hours available for network administrator support are somewhat limited. That is all the more reason to use an internal repository manager. We have been running Nexus Community Version for a number of years and it never crashes and runs for months or years without stopping or causing any problems. It makes Maven so much easier and would solve this problem in 5 minutes. Ron Douglas Kunzman 12201 Sunrise Valley Drive Reston, VA 20192 Phone: 703 648-4234 dkunz...@usgs.gov From: Manfred Moser manf...@mosabuam.com To: Maven Users List users@maven.apache.org Date: 09/25/2012 06:28 PM Subject: Re: Geotoolkit snapshot On Tue, September 25, 2012 2:17 pm, Doug Kunzman wrote: Hi - I'm working on my first Maven project and find it great but we have run into a small issue. We are using a snap-shot version of the geotoolkit ( http://www.geotoolkit.org/) because of a bug in the current release. We are in testing and am concerned that we could introduce bugs into our application when the snapshot release gets updated nightly. We would prefer to use a specific snapshot (like last nights build) but because of networking issues are reluctant to create our own maven repository. Especially if you have networking issues you should use a repository manager. Is there another or better solution? You could use the explicit snapshot version number comprised of the datetime stamp and the iterator. manfred - 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: Geotoolkit snapshot
Are you using any other snapshots? If this is your only snapshot dependency, or the only one you are not building), you could use the new -nsu flag (no snapshot updates) in Maven 3.0.4 so that snapshots, once downloaded, are not checked for updates. A better alternative is to ask Martin to make a new geotoolkit release (it has been a year), or a milestone release if he is not ready. Milestones are a common pattern in GeoTools (from which Geotoolkit was forked) and are commonly made when needed for uDig releases. Kind regards, Ben. On 26/09/12 05:17, Doug Kunzman wrote: Hi - I'm working on my first Maven project and find it great but we have run into a small issue. We are using a snap-shot version of the geotoolkit ( http://www.geotoolkit.org/) because of a bug in the current release. We are in testing and am concerned that we could introduce bugs into our application when the snapshot release gets updated nightly. We would prefer to use a specific snapshot (like last nights build) but because of networking issues are reluctant to create our own maven repository. Is there another or better solution? Thanks, Douglas Kunzman 12201 Sunrise Valley Drive Reston, VA 20192 -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Geotoolkit snapshot
On Wed, Sep 26, 2012 at 11:21 AM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au wrote: Are you using any other snapshots? If this is your only snapshot dependency, or the only one you are not building), you could use the new -nsu flag (no snapshot updates) in Maven 3.0.4 so that snapshots, once downloaded, are not checked for updates. A better alternative is to ask Martin to make a new geotoolkit release (it has been a year), or a milestone release if he is not ready. Milestones are a common pattern in GeoTools (from which Geotoolkit was forked) and are commonly made when needed for uDig releases. Ideally you dont want to maintain this stuff and you want to get the changes in the official baseline as soon as possible. However if you are pressed for time and you are only releasing artifacts internally, with no plans to share with others on the internet, then another alternative is to build, and deploy, a local version of the snapshot. See http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins for some rough notes. Since this solution only deploys locally (either to your own repository, or corporate repository) it is no good if you are sharing with others across the internet. The benefits are you can version control your changes until they get officially support, and avoids the use of -SNAPSHOTs which will stop you being able to release your artifacts. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: maven3 snapshots in local repo
Thanks, that is the most reasonable thing to do. Brining in a dependency on aether a great choice for my usage(s) though. Fortunately it should be pretty obvious in my case if this hack/assumption ever breaks. -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Tuesday, September 25, 2012 3:04 AM To: Maven Users List Subject: Re: maven3 snapshots in local repo I would recommend that you use Aether in that non-maven code to interact with remote and local repo. This is what Maven does and it will then ensure you don't run into issues. /Anders On Tue, Sep 25, 2012 at 12:13 AM, Tim Eck t...@terracottatech.com wrote: Using mvn 3.0.4, when a SNAPSHOT artifact is resolved from a remote repo it seems that my local repository ends up with both a -SNAPSHOT artifact and a timestamped version (the remote end has only timestamped versions). I'm curious if I can rely on this behavior since I have other (non-maven) code that interacts with my local maven repo. For example, from a dependency like so: dependency groupIdfoo/groupId artifactIdbar/artifactId version1.0.0-SNAPSHOT/version /dependency I end up with with two identical jars in my local repo after resolving it: bar-1.0.0-20120924.201711-2.jar bar-1.0.0-SNAPSHOT.jar I think the code in org.eclipse.aether.internal.impl.DefaultArtifactResolver::getFile() is responsible for making this additional 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
