Re: Want primary artifact of type 'zip'
Hrm, that worries me a bit. If the packaging type=pom then most tools will expect that there is only a pom with no classifier (ie main artifact). The better way is to use a classifier. I'm pretty sure this setup you propose will confuse the indexer. On Fri, Jul 30, 2010 at 1:18 AM, Jörg Schaible wrote: > Benson Margulies wrote: > >> Vincent: Oh! It never occurred to me that this was legit. > > :D > > Same to me ... > > > > - > 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: force maven to redownload/refresh "released" dependencies
On 30/07/2010 5:09 PM, Paul Benedict wrote: You can use -X for a debug log. Or you can funnel system out to a file. I believe tools like Continuum or Hudson do such things. Paul On Fri, Jul 30, 2010 at 4:07 PM, Shan Syed wrote: no, this isn't in regard to our own published artifacts I regret starting this thread, I apologize Don 't be sorry. You are getting really good advice from some very knowledgeable people who just want to help you. You are not doing things in a way that make it easy for you to satisfy your client and your life is much harder than it needs to be. No need to apologize. That is what the forum is for. Take a close look at what is being proposed and ask the questions that you need to have answered. Everyone has clients to satisfy and sometimes they don't ask for what they really need in the most direct way but you can give them what they need to do their job in a better way than your current approach and you will have a lot less work to do as well. Ron I didn't mean this question to be an affront to maven conventions - I just need to figure out a better way to capture a full log they even want a log of how the build environment was downloaded and installed On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict wrote: There is a maxim to follow when deploying: "do not redeploy a version more than once". Once you deploy version X.Y.Z, it should never be updated, and those who download it never need to download it again. So, back to the original problem, are you guys doing that? On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed wrote: it only applies to our final release cuts, not our day-to-day just once for this project really; I wanted to insert such this switch (if existed) in our "delivery build" profile we use archiva for everything else, and actually only make use of public maven repositories when we up a version of our dependencies, which is rare because of change control it's all weird stuff, I know, but sometimes I just don't question it On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: deleting the m2 works, I was just curious to see if there was a switch in maven to force all downloads again This makes absolutely no sense, doesn't change your BOM, and is just wasteful. Consumes bandwidth unnecessarily from a resource that is being used by the whole Maven community. I'd think that if you had enough developers doing this on every machine on a consistent basis (eg every build), it might add up to enough traffic to get you on a blacklist somewhere... You really need to install Nexus or another MRM, this is just plain dumb. Wayne - 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: force maven to redownload/refresh "released" dependencies
You can use -X for a debug log. Or you can funnel system out to a file. I believe tools like Continuum or Hudson do such things. Paul On Fri, Jul 30, 2010 at 4:07 PM, Shan Syed wrote: > no, this isn't in regard to our own published artifacts > > I regret starting this thread, I apologize > I didn't mean this question to be an affront to maven conventions - I just > need to figure out a better way to capture a full log > they even want a log of how the build environment was downloaded and > installed > > > On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict > wrote: > > > There is a maxim to follow when deploying: "do not redeploy a version > more > > than once". Once you deploy version X.Y.Z, it should never be updated, > and > > those who download it never need to download it again. So, back to the > > original problem, are you guys doing that? > > > > On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed wrote: > > > > > it only applies to our final release cuts, not our day-to-day > > > just once for this project really; I wanted to insert such this switch > > (if > > > existed) in our "delivery build" profile > > > we use archiva for everything else, and actually only make use of > public > > > maven repositories when we up a version of our dependencies, which is > > rare > > > because of change control > > > > > > it's all weird stuff, I know, but sometimes I just don't question it > > > > > > On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: > > > > > > > >> deleting the m2 works, I was just curious to see if there was a > > switch > > > > in > > > > >> maven to force all downloads again > > > > > > > > > > This makes absolutely no sense, doesn't change your BOM, and is > just > > > > > wasteful. Consumes bandwidth unnecessarily from a resource that is > > > being > > > > > used by the whole Maven community. > > > > > > > > I'd think that if you had enough developers doing this on every > > > > machine on a consistent basis (eg every build), it might add up to > > > > enough traffic to get you on a blacklist somewhere... You really need > > > > to install Nexus or another MRM, this is just plain dumb. > > > > > > > > Wayne > > > > > > > > - > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > > > > >
Re: force maven to redownload/refresh "released" dependencies
no, this isn't in regard to our own published artifacts I regret starting this thread, I apologize I didn't mean this question to be an affront to maven conventions - I just need to figure out a better way to capture a full log they even want a log of how the build environment was downloaded and installed On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict wrote: > There is a maxim to follow when deploying: "do not redeploy a version more > than once". Once you deploy version X.Y.Z, it should never be updated, and > those who download it never need to download it again. So, back to the > original problem, are you guys doing that? > > On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed wrote: > > > it only applies to our final release cuts, not our day-to-day > > just once for this project really; I wanted to insert such this switch > (if > > existed) in our "delivery build" profile > > we use archiva for everything else, and actually only make use of public > > maven repositories when we up a version of our dependencies, which is > rare > > because of change control > > > > it's all weird stuff, I know, but sometimes I just don't question it > > > > On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: > > > > > >> deleting the m2 works, I was just curious to see if there was a > switch > > > in > > > >> maven to force all downloads again > > > > > > > > This makes absolutely no sense, doesn't change your BOM, and is just > > > > wasteful. Consumes bandwidth unnecessarily from a resource that is > > being > > > > used by the whole Maven community. > > > > > > I'd think that if you had enough developers doing this on every > > > machine on a consistent basis (eg every build), it might add up to > > > enough traffic to get you on a blacklist somewhere... You really need > > > to install Nexus or another MRM, this is just plain dumb. > > > > > > Wayne > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > >
Re: force maven to redownload/refresh "released" dependencies
There is a maxim to follow when deploying: "do not redeploy a version more than once". Once you deploy version X.Y.Z, it should never be updated, and those who download it never need to download it again. So, back to the original problem, are you guys doing that? On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed wrote: > it only applies to our final release cuts, not our day-to-day > just once for this project really; I wanted to insert such this switch (if > existed) in our "delivery build" profile > we use archiva for everything else, and actually only make use of public > maven repositories when we up a version of our dependencies, which is rare > because of change control > > it's all weird stuff, I know, but sometimes I just don't question it > > On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: > > > >> deleting the m2 works, I was just curious to see if there was a switch > > in > > >> maven to force all downloads again > > > > > > This makes absolutely no sense, doesn't change your BOM, and is just > > > wasteful. Consumes bandwidth unnecessarily from a resource that is > being > > > used by the whole Maven community. > > > > I'd think that if you had enough developers doing this on every > > machine on a consistent basis (eg every build), it might add up to > > enough traffic to get you on a blacklist somewhere... You really need > > to install Nexus or another MRM, this is just plain dumb. > > > > Wayne > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: force maven to redownload/refresh "released" dependencies
it only applies to our final release cuts, not our day-to-day just once for this project really; I wanted to insert such this switch (if existed) in our "delivery build" profile we use archiva for everything else, and actually only make use of public maven repositories when we up a version of our dependencies, which is rare because of change control it's all weird stuff, I know, but sometimes I just don't question it On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: > >> deleting the m2 works, I was just curious to see if there was a switch > in > >> maven to force all downloads again > > > > This makes absolutely no sense, doesn't change your BOM, and is just > > wasteful. Consumes bandwidth unnecessarily from a resource that is being > > used by the whole Maven community. > > I'd think that if you had enough developers doing this on every > machine on a consistent basis (eg every build), it might add up to > enough traffic to get you on a blacklist somewhere... You really need > to install Nexus or another MRM, this is just plain dumb. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: force maven to redownload/refresh "released" dependencies
>> deleting the m2 works, I was just curious to see if there was a switch in >> maven to force all downloads again > > This makes absolutely no sense, doesn't change your BOM, and is just > wasteful. Consumes bandwidth unnecessarily from a resource that is being > used by the whole Maven community. I'd think that if you had enough developers doing this on every machine on a consistent basis (eg every build), it might add up to enough traffic to get you on a blacklist somewhere... You really need to install Nexus or another MRM, this is just plain dumb. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Jul 30, 2010, at 3:45 PM, Shan Syed wrote: > not my organization - our client wants a log of everything that came down > the pipe to create this build, that's all > it's not a matter of "worry" or "concern", so no need to be overly dramatic > some companies just want a complete audit trail of what they paid for, which > is fine by me > I'm looking for technical solutions because I'm in a technical role, not > policy advice; sometimes in this business you delivery what you're paid to > deliver regardless of whether it makes sense to you > we cannot respond to our clients saying "the guys on the maven list told us > that your request is stupid" Sounds like you're being paid to deliver an accurate bill of materials (BOM) which is perfectly reasonable. Not download things over and over again which frankly isn't very sensible. In that the BOM, containing released artifacts, will not be different whether you download 1 or 100 times. You'll have "what came down the pipe." And that you might want to explain this to your client that the BOM is not any more accurate if they are, in fact, asking you to explicitly download the released artifacts on each build. > > deleting the m2 works, I was just curious to see if there was a switch in > maven to force all downloads again This makes absolutely no sense, doesn't change your BOM, and is just wasteful. Consumes bandwidth unnecessarily from a resource that is being used by the whole Maven community. > > On Fri, Jul 30, 2010 at 2:47 PM, Jason van Zyl wrote: > >> >> On Jul 30, 2010, at 2:21 PM, Shan Syed wrote: >> >>> ok, thanks >>> basically for liability reasons for a certain project, we have to provide >>> specific times of when a project was built and when/where all its >>> dependencies were retrieved at/from >>> we have to ensure a sanitary build for all these JARs and a complete log >> of >>> going from 0 to 100 for the build; so we are faced with either clearing >> out >>> the .m2 each time >>> I was wondering if there was a way to force this through maven >>> >> >> Put the artifacts in a repository manager where you download the released >> artifact once and then manage it from your infrastructure. Once the artifact >> is within your infrastructure the released artifact is not going to change >> unless someone from within your organization changes it. They shouldn't, and >> can't if your permissions are setup correctly, and so the requirement of >> using the same artifacts and their origin becomes moot. If your organization >> cares that much about liability concerns then you absolutely should not be >> connecting to the outside world every time you build. >> >>> On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis >>> wrote: >>> On 07/30/2010 07:16 PM, Wayne Fay wrote: > is there a way to force a project to refresh certain dependencies every >> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts >> > > Absolutely not. Released artifacts MUST NOT CHANGE. > +1, never ever ;-) Released artifact versioning is supposed to guarantee consistency. Manos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> believe nothing, no matter where you read it, >> or who has said it, >> not even if i have said it, >> unless it agrees with your own reason >> and your own common sense. >> >> -- Buddha >> >> >> >> Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
Re: force maven to redownload/refresh "released" dependencies
not my organization - our client wants a log of everything that came down the pipe to create this build, that's all it's not a matter of "worry" or "concern", so no need to be overly dramatic some companies just want a complete audit trail of what they paid for, which is fine by me I'm looking for technical solutions because I'm in a technical role, not policy advice; sometimes in this business you delivery what you're paid to deliver regardless of whether it makes sense to you we cannot respond to our clients saying "the guys on the maven list told us that your request is stupid" deleting the m2 works, I was just curious to see if there was a switch in maven to force all downloads again On Fri, Jul 30, 2010 at 2:47 PM, Jason van Zyl wrote: > > On Jul 30, 2010, at 2:21 PM, Shan Syed wrote: > > > ok, thanks > > basically for liability reasons for a certain project, we have to provide > > specific times of when a project was built and when/where all its > > dependencies were retrieved at/from > > we have to ensure a sanitary build for all these JARs and a complete log > of > > going from 0 to 100 for the build; so we are faced with either clearing > out > > the .m2 each time > > I was wondering if there was a way to force this through maven > > > > Put the artifacts in a repository manager where you download the released > artifact once and then manage it from your infrastructure. Once the artifact > is within your infrastructure the released artifact is not going to change > unless someone from within your organization changes it. They shouldn't, and > can't if your permissions are setup correctly, and so the requirement of > using the same artifacts and their origin becomes moot. If your organization > cares that much about liability concerns then you absolutely should not be > connecting to the outside world every time you build. > > > On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis > > wrote: > > > >> On 07/30/2010 07:16 PM, Wayne Fay wrote: > >> > >>> is there a way to force a project to refresh certain dependencies every > build? i.e. replicate SNAPSHOT behaviour with "released" artifacts > > >>> > >>> Absolutely not. Released artifacts MUST NOT CHANGE. > >>> > >> > >> +1, never ever ;-) > >> > >> Released artifact versioning is supposed to guarantee consistency. > >> > >> Manos > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > believe nothing, no matter where you read it, > or who has said it, > not even if i have said it, > unless it agrees with your own reason > and your own common sense. > > -- Buddha > > > >
RE: force maven to redownload/refresh "released" dependencies
You could try changing the repository location property on the command line to a fresh empty directory. That will force the download and logging of all SNAPSHOT and release dependencies. >mvn ... -Dmaven.repo.local= To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: force maven to redownload/refresh "released" dependencies
On Jul 30, 2010, at 2:21 PM, Shan Syed wrote: > ok, thanks > basically for liability reasons for a certain project, we have to provide > specific times of when a project was built and when/where all its > dependencies were retrieved at/from > we have to ensure a sanitary build for all these JARs and a complete log of > going from 0 to 100 for the build; so we are faced with either clearing out > the .m2 each time > I was wondering if there was a way to force this through maven > Put the artifacts in a repository manager where you download the released artifact once and then manage it from your infrastructure. Once the artifact is within your infrastructure the released artifact is not going to change unless someone from within your organization changes it. They shouldn't, and can't if your permissions are setup correctly, and so the requirement of using the same artifacts and their origin becomes moot. If your organization cares that much about liability concerns then you absolutely should not be connecting to the outside world every time you build. > On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis > wrote: > >> On 07/30/2010 07:16 PM, Wayne Fay wrote: >> >>> is there a way to force a project to refresh certain dependencies every build? i.e. replicate SNAPSHOT behaviour with "released" artifacts >>> >>> Absolutely not. Released artifacts MUST NOT CHANGE. >>> >> >> +1, never ever ;-) >> >> Released artifact versioning is supposed to guarantee consistency. >> >> Manos >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
wagon-webdav
Hi, I'm trying to use maven-site-plugin and the wagon-webdav artifact. I get this error when I do mvn site-deploy. But according to http://maven.apache.org/wagon/wagon-providers/wagon-webdav/ it says it does support directory copying... anyone know what could produce this error? Thanks, Chris [INFO] --- maven-site-plugin:2.1.1:deploy (default-deploy) @ wsaxisM --- [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 5.287s [INFO] Finished at: Fri Jul 30 13:41:59 CDT 2010 [INFO] Final Memory: 6M/15M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:2.1.1:deploy (default-deploy) on project wsaxisM: Wagon protocol 'dav' doesn't support directory copying -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-site-plugin:2.1.1:deploy (default-deploy) on project wsaxisM: Wagon protocol 'dav' doesn't support directory copying at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:585) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:324) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:247) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:104) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:427) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:157) at org.apache.maven.cli.MavenCli.main(MavenCli.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launche r.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:2 30) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launc her.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352 ) Caused by: org.apache.maven.plugin.MojoExecutionException: Wagon protocol 'dav' doesn't support directory copying at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java :193) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBui ldPluginManager.java:105) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:577) ... 14 more [ERROR] [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
Re: force maven to redownload/refresh "released" dependencies
Wouldn't you be better off implementing such mechanism in an SCM package? Audit can be done with scripts either sitting on top of SCM or Unix/Linux machine. Added logging layer from hosting it on Linux/Unix would benefit you far more and provide better flexibility. Hope it helps, Dave On Fri, Jul 30, 2010 at 1:21 PM, Shan Syed wrote: > ok, thanks > basically for liability reasons for a certain project, we have to provide > specific times of when a project was built and when/where all its > dependencies were retrieved at/from > we have to ensure a sanitary build for all these JARs and a complete log of > going from 0 to 100 for the build; so we are faced with either clearing out > the .m2 each time > I was wondering if there was a way to force this through maven > > On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis > wrote: > > > On 07/30/2010 07:16 PM, Wayne Fay wrote: > > > >> is there a way to force a project to refresh certain dependencies every > >>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts > >>> > >> > >> Absolutely not. Released artifacts MUST NOT CHANGE. > >> > > > > +1, never ever ;-) > > > > Released artifact versioning is supposed to guarantee consistency. > > > > Manos > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: force maven to redownload/refresh "released" dependencies
On 30/07/2010 12:57 PM, Manos Batsis wrote: On 07/30/2010 07:16 PM, Wayne Fay wrote: is there a way to force a project to refresh certain dependencies every build? i.e. replicate SNAPSHOT behaviour with "released" artifacts Absolutely not. Released artifacts MUST NOT CHANGE. +1, never ever ;-) Released artifact versioning is supposed to guarantee consistency. Manos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org +1 I have been the victim of an Apache project that rereleased its artifacts. This led to great difficulty in controlling builds to ensure that the correct version of the release was used. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Replacing a SNAPSHOT with a non-SNAPSHOT version is equivalent to upgrading. Jason is right in that this should never be automatically done by Maven. Maven cannot guess or determine when you are ready to give up SNAPSHOT versions. However, perhaps you need an external batch process that discovers new versions and automatically upgrades POMs. Paul On Fri, Jul 30, 2010 at 1:21 PM, Shan Syed wrote: > ok, thanks > basically for liability reasons for a certain project, we have to provide > specific times of when a project was built and when/where all its > dependencies were retrieved at/from > we have to ensure a sanitary build for all these JARs and a complete log of > going from 0 to 100 for the build; so we are faced with either clearing out > the .m2 each time > I was wondering if there was a way to force this through maven > > On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis > wrote: > > > On 07/30/2010 07:16 PM, Wayne Fay wrote: > > > >> is there a way to force a project to refresh certain dependencies every > >>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts > >>> > >> > >> Absolutely not. Released artifacts MUST NOT CHANGE. > >> > > > > +1, never ever ;-) > > > > Released artifact versioning is supposed to guarantee consistency. > > > > Manos > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: force maven to redownload/refresh "released" dependencies
ok, thanks basically for liability reasons for a certain project, we have to provide specific times of when a project was built and when/where all its dependencies were retrieved at/from we have to ensure a sanitary build for all these JARs and a complete log of going from 0 to 100 for the build; so we are faced with either clearing out the .m2 each time I was wondering if there was a way to force this through maven On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis wrote: > On 07/30/2010 07:16 PM, Wayne Fay wrote: > >> is there a way to force a project to refresh certain dependencies every >>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts >>> >> >> Absolutely not. Released artifacts MUST NOT CHANGE. >> > > +1, never ever ;-) > > Released artifact versioning is supposed to guarantee consistency. > > Manos > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Classloader problems in eclipse helios with maven 3.0
I just downloaded the latest version of eclipse 3.6. When I try to debug using the maven jetty plugin, I get all sorts of classloader problems, where resources in src/main/resources in dependent projects cannot be found (FileNotFoundException). I have no such problems in eclipse 3.4 or running maven 2.2.0 on the command line. My eclipse helios is using embedded maven version 3.0-SNAPSHOT/0.10.2.20100623-1649. Let me know if I should file a bug and if so, where. Thanks. -- View this message in context: http://maven.40175.n5.nabble.com/Classloader-problems-in-eclipse-helios-with-maven-3-0-tp2259811p2259811.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
‘mvn clean’ wipes out eclipse settings file
Hi I have manually configured Eclipse WTP to deploy my web-app from my project's target directory (so my deployment includes the result of JSP pre-compilation). I have done this by manually editing my project's settings/rg.eclipse.wst.common.component file. But now every time I run an "mvn clean" build (command-line or in M2Eclipse), the file reverts to a previous state. Anyone know why this might be happening? Thanks
Re: force maven to redownload/refresh "released" dependencies
On 07/30/2010 07:16 PM, Wayne Fay wrote: is there a way to force a project to refresh certain dependencies every build? i.e. replicate SNAPSHOT behaviour with "released" artifacts Absolutely not. Released artifacts MUST NOT CHANGE. +1, never ever ;-) Released artifact versioning is supposed to guarantee consistency. Manos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
I was actually under the impression you could do this like this: always Although I've never tried this because it's a terrible idea. If this doesn't work, someone should probably remove the corresponding section from http://maven.apache.org/settings.html#Repositories and http://maven.apache.org/settings.html#Repositories (yes, those pages show the repository being disabled, but it is still configured with an updatePolicy). Justin On 7/30/10 12:39 PM, Jason van Zyl wrote: > Maven won't do that, and we would never make that possible. If you require > this you have something seriously wrong with your project infrastructure. > Seriously bad project infrastructure smell. > > On Jul 30, 2010, at 12:01 PM, Shan Syed wrote: > >> is there a way to force a project to refresh certain dependencies every >> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts >> >> S > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Shan, Maven has a policy how often it checks for updated snapshots. Is that what you are looking for? Paul On Fri, Jul 30, 2010 at 11:39 AM, Jason van Zyl wrote: > Maven won't do that, and we would never make that possible. If you require > this you have something seriously wrong with your project infrastructure. > Seriously bad project infrastructure smell. > > On Jul 30, 2010, at 12:01 PM, Shan Syed wrote: > > > is there a way to force a project to refresh certain dependencies every > > build? i.e. replicate SNAPSHOT behaviour with "released" artifacts > > > > S > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > > > >
Re: force maven to redownload/refresh "released" dependencies
Maven won't do that, and we would never make that possible. If you require this you have something seriously wrong with your project infrastructure. Seriously bad project infrastructure smell. On Jul 30, 2010, at 12:01 PM, Shan Syed wrote: > is there a way to force a project to refresh certain dependencies every > build? i.e. replicate SNAPSHOT behaviour with "released" artifacts > > S Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: force maven to redownload/refresh "released" dependencies
> is there a way to force a project to refresh certain dependencies every > build? i.e. replicate SNAPSHOT behaviour with "released" artifacts Absolutely not. Released artifacts MUST NOT CHANGE. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
force maven to redownload/refresh "released" dependencies
is there a way to force a project to refresh certain dependencies every build? i.e. replicate SNAPSHOT behaviour with "released" artifacts S
Re: how to get pom updated during mvn release when sub-project is not part of normal build
Using a profile where you specify the modules? I.e. a special profile for the release work where C is included. /Anders On Fri, Jul 30, 2010 at 16:30, Gordon Cody wrote: > Hello List > > I have a multimodule project similar to the following: > > toplevel > pom.xml > modA > pom.xml > modB > pom.xml > modC > pom.xml > > Modules A & B are specified explicitly in the toplevel pom. Module C is > not. > It is only to be run when required and is done stand-alone. > > When I do mvn release, the toplevel pom and the poms in modA and modB > all get updated with new version as expected but modC does not. Is there > a way to get the normal build to skip modC but get mv release to also > update > the pom in modC ? > > Thanks for any help > Gord > gc...@zafinlabs.com >
how to get pom updated during mvn release when sub-project is not part of normal build
Hello List I have a multimodule project similar to the following: toplevel pom.xml modA pom.xml modB pom.xml modC pom.xml Modules A & B are specified explicitly in the toplevel pom. Module C is not. It is only to be run when required and is done stand-alone. When I do mvn release, the toplevel pom and the poms in modA and modB all get updated with new version as expected but modC does not. Is there a way to get the normal build to skip modC but get mv release to also update the pom in modC ? Thanks for any help Gord gc...@zafinlabs.com
Re: looks for manually installed in all remote repositories
If you are going to be doing your development with Maven and want to speed things up and make your life a lot better install Nexus. It make not make the sex or the beer better but you will have more time to pursue them. Ron On 30/07/2010 6:40 AM, Lukin wrote: Solved! Thank you for assistance. I have probably made some mistake when I was experimenting with Maven for the first time. You pointed me to the right direction - the jar was not very well installed. The problem was, that in .m2\repository\com\microsoft\sqljdbc4\2\ was missing .pom file. I just have created sqljdbc4-2.pom with 4.0.0 com.microsoft sqljdbc4 2 and that was IT. Thank to all for help - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem uploading bundles via Sonatype
Yes, or file an INFRA ticket: https://issues.apache.org On Fri, Jul 30, 2010 at 4:28 AM, Dennis Lundberg wrote: > Jason, shouldn't that be reposit...@apache.org instead? > > On 2010-07-29 21:11, Jason van Zyl wrote: >> The Apache repository specific concerns go to >> repo-maintain...@maven.apache.org. Maybe we can try and whip up a solution >> for you that you can use with your Ant build so you can deploy directly to >> Nexus. >> >> On Jul 29, 2010, at 2:58 PM, Greg Brown wrote: >> >>> Yes, I am using https://repository.apache.org. >>> >>> Should I repost this issue to the Sonatype bug DB? >>> >>> On Jul 29, 2010, at 2:47 PM, Jason van Zyl wrote: >>> I'm CC'ing Juven as he takes care of the support requests. Or use JIRA: https://issues.sonatype.org/browse/OSSRH You know there is a Nexus instance at Apache for use by Apache projects? On Jul 29, 2010, at 11:47 AM, Greg Brown wrote: > > Hi all, > > I'm trying to upload some bundles for Pivot 1.5.1 using Sonatype. The > bundles are here: > > http://people.apache.org/~tvolkert/maven/pivot/v1.5.1/ > > The pivot-1.5.1-bundle.jar file uploads fine, but > pivot-core-1.5.1-bundle.jar hangs. I haven't tested the others since they > depend on pivot-core-1.5.1-bundle.jar. > > I don't get any error messages from the UI. Is there any way to find out > what is going wrong? > > Thanks, > Greg > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Problem-uploading-bundles-via-Sonatype-tp2256735p2256735.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 > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Three people can keep a secret provided two of them are dead. -- Unknown >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> Three people can keep a secret provided two of them are dead. >> >> -- Unknown >> >> >> >> > > > -- > Dennis Lundberg > > - > 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: looks for manually installed in all remote repositories
Solved! Thank you for assistance. I have probably made some mistake when I was experimenting with Maven for the first time. You pointed me to the right direction - the jar was not very well installed. The problem was, that in .m2\repository\com\microsoft\sqljdbc4\2\ was missing .pom file. I just have created sqljdbc4-2.pom with 4.0.0 com.microsoft sqljdbc4 2 and that was IT. Thank to all for help -- View this message in context: http://maven.40175.n5.nabble.com/looks-for-manually-installed-in-all-remote-repositories-tp2259297p2259404.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: dependency plugin does not find dependency for release
Hmm it seems I solved this by adding: clean install to release plugin. But still, should reactor be searched be dependency plugin. On Fri, Jul 30, 2010 at 12:05 PM, Bartosz Baranowski wrote: > Hi > > Im having problem with dependency plugin and release process. Stage looks > like: > > /parent.pom.xml > /impl/pom.xml > /doc/pom.xml > /docs/sources/pom.xml > /docs/prepare/pom.xml > > > On regular mvn install - /docs/sources just creates bundle with files - > lets say it creates docs-sources-SNAPSHOT.jar. > /docs/preapre fetches(with dependency) artifact: docs-sources-SNAPSHOT.jar > and does filters resources, simple. > With -X I can see artifact: docs-sources-SNAPSHOT.jar in reactor as project > and maven indicates that it ignores repos and uses local. Fine. > This works. > > However with mvn release:prepare it fails. Even though artifact: > docs-sources.jar is in reactor, dependency plugin goes through list of > repos(failing, since its not released) and than fails, completly ignoring > reactor. This happens in "verify" phase, so non snapshot artifacts are not > present in local repo. > > Has anyone faced somethin like this? > > > Apache Maven 2.2.1 (rNON-CANONICAL_2010-04-08_21-32_root; 2010-04-08 > 21:32:53+0200) > Java version: 1.6.0_0 > Java home: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.31.5-127.fc12.x86_64" arch: "amd64" Family: > "unix" > >
dependency plugin does not find dependency for release
Hi Im having problem with dependency plugin and release process. Stage looks like: /parent.pom.xml /impl/pom.xml /doc/pom.xml /docs/sources/pom.xml /docs/prepare/pom.xml On regular mvn install - /docs/sources just creates bundle with files - lets say it creates docs-sources-SNAPSHOT.jar. /docs/preapre fetches(with dependency) artifact: docs-sources-SNAPSHOT.jar and does filters resources, simple. With -X I can see artifact: docs-sources-SNAPSHOT.jar in reactor as project and maven indicates that it ignores repos and uses local. Fine. This works. However with mvn release:prepare it fails. Even though artifact: docs-sources.jar is in reactor, dependency plugin goes through list of repos(failing, since its not released) and than fails, completly ignoring reactor. This happens in "verify" phase, so non snapshot artifacts are not present in local repo. Has anyone faced somethin like this? Apache Maven 2.2.1 (rNON-CANONICAL_2010-04-08_21-32_root; 2010-04-08 21:32:53+0200) Java version: 1.6.0_0 Java home: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.31.5-127.fc12.x86_64" arch: "amd64" Family: "unix"
Re: looks for manually installed in all remote repositories
How did you install it in your local repo? Wit install:install-file or manually? I'm guessing here, but could it be that the local metadata files don't include this version of the artifact and therefore Maven will go remote? /Anders On Fri, Jul 30, 2010 at 11:18, Lukin wrote: > > Thank you for your reply. > > It is not snapshot, > I have defined it this way: > > >com.microsoft >sqljdbc4 >2 > > > it is located in my .m2\repository\com\microsoft\sqljdbc4\2\sqljdbc4-2.jar > -- > View this message in context: > http://maven.40175.n5.nabble.com/looks-for-manually-installed-in-all-remote-repositories-tp2259297p2259343.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: looks for manually installed in all remote repositories
Thank you for your reply. It is not snapshot, I have defined it this way: com.microsoft sqljdbc4 2 it is located in my .m2\repository\com\microsoft\sqljdbc4\2\sqljdbc4-2.jar -- View this message in context: http://maven.40175.n5.nabble.com/looks-for-manually-installed-in-all-remote-repositories-tp2259297p2259343.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: looks for manually installed in all remote repositories
Hi, Likin. Is this dependency SNAPSHOT or not? Aleksey. 30.07.2010 12:36, Lukin пишет: Hi, I have defined additional repositories in my settings.xml - works OK. I have manually installed one dependency - OK (it is in my .m2 directory). Problem is, that this dependency is always looked for in all of those additional repositories and Maven complains "Unable to find resource ...". Build process is slow because of this. Can I tell Maven not to look for this dependency in remote repositories? Anyway, I thought, Maven searches local repository first and it should find it there. Thank you for any help, Lukas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
looks for manually installed in all remote repositories
Hi, I have defined additional repositories in my settings.xml - works OK. I have manually installed one dependency - OK (it is in my .m2 directory). Problem is, that this dependency is always looked for in all of those additional repositories and Maven complains "Unable to find resource ...". Build process is slow because of this. Can I tell Maven not to look for this dependency in remote repositories? Anyway, I thought, Maven searches local repository first and it should find it there. Thank you for any help, Lukas -- View this message in context: http://maven.40175.n5.nabble.com/looks-for-manually-installed-in-all-remote-repositories-tp2259297p2259297.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: Problem uploading bundles via Sonatype
Jason, shouldn't that be reposit...@apache.org instead? On 2010-07-29 21:11, Jason van Zyl wrote: > The Apache repository specific concerns go to > repo-maintain...@maven.apache.org. Maybe we can try and whip up a solution > for you that you can use with your Ant build so you can deploy directly to > Nexus. > > On Jul 29, 2010, at 2:58 PM, Greg Brown wrote: > >> Yes, I am using https://repository.apache.org. >> >> Should I repost this issue to the Sonatype bug DB? >> >> On Jul 29, 2010, at 2:47 PM, Jason van Zyl wrote: >> >>> I'm CC'ing Juven as he takes care of the support requests. Or use JIRA: >>> https://issues.sonatype.org/browse/OSSRH >>> >>> You know there is a Nexus instance at Apache for use by Apache projects? >>> >>> On Jul 29, 2010, at 11:47 AM, Greg Brown wrote: >>> Hi all, I'm trying to upload some bundles for Pivot 1.5.1 using Sonatype. The bundles are here: http://people.apache.org/~tvolkert/maven/pivot/v1.5.1/ The pivot-1.5.1-bundle.jar file uploads fine, but pivot-core-1.5.1-bundle.jar hangs. I haven't tested the others since they depend on pivot-core-1.5.1-bundle.jar. I don't get any error messages from the UI. Is there any way to find out what is going wrong? Thanks, Greg -- View this message in context: http://maven.40175.n5.nabble.com/Problem-uploading-bundles-via-Sonatype-tp2256735p2256735.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 >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> Three people can keep a secret provided two of them are dead. >>> >>> -- Unknown >>> >>> >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > Three people can keep a secret provided two of them are dead. > > -- Unknown > > > > -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
