Deprecate dependency:purge-local-repository, build-helper:remove-project-artifact
Hi We have similar goals in two plugins: - https://www.mojohaus.org/build-helper-maven-plugin/remove-project-artifact-mojo.html - https://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html By the way, using such goals is not recommended today with Maven 3 and so much with Maven 4 Even more, when we remove one artifact from a local repository meta-data information is not fixed. We can achieve some of the requirements by using Enhanced LRM with Split Local Repository - so installed artifacts can be separated for each build and can be easily removed. https://maven.apache.org/resolver/local-repository.html We can use -Dmaven.repo.local to be sure that the build uses a clean one. Also today there is no problem downloading artifacts from remote repositories, so cleaning the whole remote repo from time to time can be a good idea. I'm interested in which scenarios those goals are used and who needs it. For reference there was a discussion: https://lists.apache.org/thread/nnqfjq4y8g56cdq38mo5mv9ov156797t -- Sławomir Jaranowski
Re: Maven resilience to interrupted install to local repository
Thu, 29 Feb 2024, /Tamás Cservenák/: am not Windows user, but we had several reports about issues, like this one: https://issues.apache.org/jira/browse/MRESOLVER-372 I see. Thank you for the reference. As far as I'm aware, such "access denied" exceptions on Windows are not specific to atomic moves. It could happen one process has opened a file for reading, preventing another from overwriting it immediately. I guess such updates need a retry mechanism, at least for the atomic move part. On Thu, Feb 29, 2024 at 1:40 PM Stanimir Stamenkov wrote: Thu, 29 Feb 2024, /Tamás Cservenák/: Resolver 1.9.18 uses the temp file technique you describe: copies to (random) temp file located in the same directory where target file is, and then atomically moves the file to its place (unless OS is windows, for obvious reasons). Doesn't atomic file move/replace work on Windows? I'm using Files.move() [1] with ATOMIC_MOVE [2] option to achieve the same technique on Windows successfully. [1] https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/Files.html#move(java.nio.file.Path,java.nio.file.Path,java.nio.file.CopyOption.. .) [2] https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/StandardCopyOption.html#ATOMIC_MOVE -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven resilience to interrupted install to local repository
Howdy, am not Windows user, but we had several reports about issues, like this one: https://issues.apache.org/jira/browse/MRESOLVER-372 T On Thu, Feb 29, 2024 at 1:40 PM Stanimir Stamenkov wrote: > Thu, 29 Feb 2024, /Tamás Cservenák/: > > > Resolver 1.9.18 uses the temp file technique you describe: > > copies to (random) temp file located in the same directory where target > > file is, and then atomically moves the file to its place > > (unless OS is windows, for obvious reasons). > > Doesn't atomic file move/replace work on Windows? I'm using > Files.move() [1] with ATOMIC_MOVE [2] option to achieve the same > technique on Windows successfully. > > [1] > > https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/Files.html#move(java.nio.file.Path,java.nio.file.Path,java.nio.file.CopyOption.. > .) > [2] > > https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/StandardCopyOption.html#ATOMIC_MOVE > > -- > Stanimir > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Maven resilience to interrupted install to local repository
Thu, 29 Feb 2024, /Tamás Cservenák/: Resolver 1.9.18 uses the temp file technique you describe: copies to (random) temp file located in the same directory where target file is, and then atomically moves the file to its place (unless OS is windows, for obvious reasons). Doesn't atomic file move/replace work on Windows? I'm using Files.move() [1] with ATOMIC_MOVE [2] option to achieve the same technique on Windows successfully. [1] https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/Files.html#move(java.nio.file.Path,java.nio.file.Path,java.nio.file.CopyOption...) [2] https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/StandardCopyOption.html#ATOMIC_MOVE -- Stanimir - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven resilience to interrupted install to local repository
Resolver 1.9.18 uses the temp file technique you describe: copies to (random) temp file located in the same directory where target file is, and then atomically moves the file to its place (unless OS is windows, for obvious reasons). T On Thu, Feb 29, 2024 at 12:17 PM Václav Haisman wrote: > Hi. > > How resilient is Maven to JVM being killed (K8s POD being killed) while it > is installing artifact files into a local repository? Does it do the copy > into a temporary file then rename method or does it copy into the target > artifact file directly? > > -- > VH >
Maven resilience to interrupted install to local repository
Hi. How resilient is Maven to JVM being killed (K8s POD being killed) while it is installing artifact files into a local repository? Does it do the copy into a temporary file then rename method or does it copy into the target artifact file directly? -- VH
Re: Maven 4.0.0-aplha3 [MNG-7612] - Chained Local Repository
Many thanks Tamàs Provided links are clear. I will used suggested solution ready in current Maven version Thanks, Arnaud Le ven. 16 déc. 2022 à 20:20, Tamás Cservenák a écrit : > Hi Arnaud > > drafted a page (should probably go to resolver side) about CLRM > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=235837219 > > The "shared" local repo among several bulbs could work, as long the shared > local repo is not modified while ANY build is using in CLRM tail. > > Build1 could use CLRM(LM1, SHARED) > Build2 could use CLRM(LM2, SHARED) > etc > > For "branched development" see > https://maven.apache.org/resolver/local-repository.html#use-cases as that > would suit better for your use case > > HTH > T > > On Fri, Dec 16, 2022 at 6:13 PM Arnaud bourree > wrote: > > > Hello, > > > > I'm interested by [MNG-7612 < > > https://issues.apache.org/jira/browse/MNG-7612>] > > - Chained Local Repository. > > In Jira, feature is described to be for IT testings, I suppose Maven > plugin > > IT. > > Does it trully limited? Or can we image using it in others usecases? > > I've in mind share local repository on non project's artifact between > > branches and 2nd one for each branch I'm working on. > > > > Regardes, > > > > Arnaud > > >
Re: Maven 4.0.0-aplha3 [MNG-7612] - Chained Local Repository
Hi Arnaud drafted a page (should probably go to resolver side) about CLRM https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=235837219 The "shared" local repo among several bulbs could work, as long the shared local repo is not modified while ANY build is using in CLRM tail. Build1 could use CLRM(LM1, SHARED) Build2 could use CLRM(LM2, SHARED) etc For "branched development" see https://maven.apache.org/resolver/local-repository.html#use-cases as that would suit better for your use case HTH T On Fri, Dec 16, 2022 at 6:13 PM Arnaud bourree wrote: > Hello, > > I'm interested by [MNG-7612 < > https://issues.apache.org/jira/browse/MNG-7612>] > - Chained Local Repository. > In Jira, feature is described to be for IT testings, I suppose Maven plugin > IT. > Does it trully limited? Or can we image using it in others usecases? > I've in mind share local repository on non project's artifact between > branches and 2nd one for each branch I'm working on. > > Regardes, > > Arnaud >
Maven 4.0.0-aplha3 [MNG-7612] - Chained Local Repository
Hello, I'm interested by [MNG-7612 <https://issues.apache.org/jira/browse/MNG-7612>] - Chained Local Repository. In Jira, feature is described to be for IT testings, I suppose Maven plugin IT. Does it trully limited? Or can we image using it in others usecases? I've in mind share local repository on non project's artifact between branches and 2nd one for each branch I'm working on. Regardes, Arnaud
Re: Local repository accessed by multiple Maven instances - how is it solved ?
* Build this one first: https://github.com/apache/maven/tree/maven-3.8.x-resolver-1.7.x (https://maven.apache.org/resolver/maven-3.8.x.html) * Follow this guide: https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html If you have failures, follow this guide: * https://maven.apache.org/resolver/maven-resolver-named-locks/analyzing-lock-issues.html The guide has been tested on realworld projects reported by users. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Local repository accessed by multiple Maven instances - how is it solved ?
Hi Tamas,
I've been trying the Redisson approach for the last 7 weeks, but my machine
locks up every second or third build for long periods of time 5-20min.
I'm on Ubuntu running the Redis 6.2.6 snap using the Maven 3.8.3 and 3.8.4
wrapper. I followed these instructions to setup
Edit the file *${maven.home}/bin/m2.conf* and after *${maven.conf}/logging*
add *load ${maven.home}/lib/ext/redisson/*.jar*
Create the folder *${maven.home}/lib/ext/redisson/* and populate with
https://repo1.maven.org/maven2/org/apache/maven/resolver/maven-resolver-named-locks-redisson/1.7.2/maven-resolver-named-locks-redisson-1.7.2.jar
https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-annotations/2.12.1/jackson-annotations-2.12.1.jar
https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.12.1/jackson-core-2.12.1.jar
https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-databind/2.12.1/jackson-databind-2.12.1.jar
https://repo1.maven.org/maven2/com/fasterxml/jackson/dataformat/jackson-dataformat-yaml/2.12.1/jackson-dataformat-yaml-2.12.1.jar
https://repo1.maven.org/maven2/org/jboss/marshalling/jboss-marshalling/2.0.11.Final/jboss-marshalling-2.0.11.Final.jar
https://repo1.maven.org/maven2/org/jboss/marshalling/jboss-marshalling-river/2.0.11.Final/jboss-marshalling-river-2.0.11.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-buffer/4.1.65.Final/netty-buffer-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-codec/4.1.65.Final/netty-codec-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-codec-dns/4.1.65.Final/netty-codec-dns-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-common/4.1.65.Final/netty-common-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-handler/4.1.65.Final/netty-handler-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-resolver/4.1.65.Final/netty-resolver-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-resolver-dns/4.1.65.Final/netty-resolver-dns-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-transport/4.1.65.Final/netty-transport-4.1.65.Final.jar
https://repo1.maven.org/maven2/org/redisson/redisson/3.15.6/redisson-3.15.6.jar
https://repo1.maven.org/maven2/org/yaml/snakeyaml/1.27/snakeyaml-1.27.jar
Delany
On Fri, 8 Oct 2021 at 10:05, Delany wrote:
> Thanks Tamás.
> Since I use the wrapper, I was thinking there's a case for Maven wrapper
> variants. But I guess this is what containers are all about anyway.
> Delany
>
> On Thu, 7 Oct 2021 at 11:32, Tamás Cservenák wrote:
>
>> Hi Delany,
>>
>> from Sisu website: "Sisu is a modular JSR330-based container that
>> supports *classpath
>> scanning*, *auto-binding*, and *dynamic auto-wiring*. Sisu uses
>> Google-Guice to perform dependency injection and provide the core JSR330
>> support, but removes the need to write explicit bindings in Guice
>> modules.".
>>
>> Simply, SISU will scan your classpath for components and dynamically pick
>> them up and wire them up.
>>
>> For Guice, you need to _explicitly add_ bindings (as this "dynamism" is a
>> Sisu feature).
>>
>> ServiceLocator is deprecated, leave it out (but same thing stands: is
>> "static").
>>
>> ===
>>
>> More simpler: with Sisu, just throw a component onto classpath, and Sisu
>> will "automagically" pick it up, no code change needed. This is how
>> extensions and other things work in Maven for example (just copy a JAR
>> with
>> components to classpath and they are discovered).
>>
>> Locking implementations like Redisson and Hazelcast are "opt-in", they are
>> not bundled with Maven (to not bloat distro). They work only after you
>> "install" them (provide JARs with their components and all component
>> dependencies to Maven classpath, as explained in the Install step on that
>> page).
>>
>> This remark you quoted is geared more toward "resolver integrators", for
>> those using Resolver into some other project than Maven. If you integrate
>> Resolver, then:
>> - if you use Sisu, you have nothing to do :)
>> - if you use vanilla Guice, then in your integration you have to provide
>> the things you want on classpath and explicitly bind them
>> - if you use ServiceLocator, move away from it (will be soon dropped),
>> simplest is to "roll your own" bootstrap class (that does same as
>> ServiceLocator was doing, statically wiring things up), and again, you
>> should upfront provide whatever you need on classpath and instantiate them
>> using your own "bootstrap" class.
>>
>> If you just want to use it with Maven, nothing to be done for you, just
>> Install it as per page.
>>
>> ===
>>
>> HTH
>> Tamas
>>
>> On Thu, Oct 7, 2021 at 10:07 AM Delany
>> wrote:
>>
>> > Michael, could you clarify this line pls: "It only works when Sisu DI is
>> > used and not the bundled AetherModule or ServiceLocator (Maven uses Sisu
>> > dependency injection)."
>> >
>> >
>> https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html
>> >
>> > What should I do
Re: Local repository accessed by multiple Maven instances - how is it solved ?
Thanks Tamás. Since I use the wrapper, I was thinking there's a case for Maven wrapper variants. But I guess this is what containers are all about anyway. Delany On Thu, 7 Oct 2021 at 11:32, Tamás Cservenák wrote: > Hi Delany, > > from Sisu website: "Sisu is a modular JSR330-based container that > supports *classpath > scanning*, *auto-binding*, and *dynamic auto-wiring*. Sisu uses > Google-Guice to perform dependency injection and provide the core JSR330 > support, but removes the need to write explicit bindings in Guice > modules.". > > Simply, SISU will scan your classpath for components and dynamically pick > them up and wire them up. > > For Guice, you need to _explicitly add_ bindings (as this "dynamism" is a > Sisu feature). > > ServiceLocator is deprecated, leave it out (but same thing stands: is > "static"). > > === > > More simpler: with Sisu, just throw a component onto classpath, and Sisu > will "automagically" pick it up, no code change needed. This is how > extensions and other things work in Maven for example (just copy a JAR with > components to classpath and they are discovered). > > Locking implementations like Redisson and Hazelcast are "opt-in", they are > not bundled with Maven (to not bloat distro). They work only after you > "install" them (provide JARs with their components and all component > dependencies to Maven classpath, as explained in the Install step on that > page). > > This remark you quoted is geared more toward "resolver integrators", for > those using Resolver into some other project than Maven. If you integrate > Resolver, then: > - if you use Sisu, you have nothing to do :) > - if you use vanilla Guice, then in your integration you have to provide > the things you want on classpath and explicitly bind them > - if you use ServiceLocator, move away from it (will be soon dropped), > simplest is to "roll your own" bootstrap class (that does same as > ServiceLocator was doing, statically wiring things up), and again, you > should upfront provide whatever you need on classpath and instantiate them > using your own "bootstrap" class. > > If you just want to use it with Maven, nothing to be done for you, just > Install it as per page. > > === > > HTH > Tamas > > On Thu, Oct 7, 2021 at 10:07 AM Delany wrote: > > > Michael, could you clarify this line pls: "It only works when Sisu DI is > > used and not the bundled AetherModule or ServiceLocator (Maven uses Sisu > > dependency injection)." > > > > > https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html > > > > What should I do about this issue? > > > > Thanks, > > Delany > > > > > > On Wed, 6 Oct 2021 at 22:18, Michael Osipov wrote: > > > > > Am 2021-10-06 um 21:05 schrieb Francois Marot: > > > > Michael, I do not agree. As a user and maintainer of the build chain > in > > > my > > > > company, I think Maven would really benefit from an out of the box > > > > solution. I think any user is susceptible to the bug by launching > > > multiple > > > > Maven instances at the same time on his computer. Bugs then > encountered > > > are > > > > really a bad sign sent to users, and requiring each dev to setup a > > > database > > > > (even simple) is cumbersome. > > > > > > I agree with you, but we are developers after all, I can expect people > > > to set up something if necessary. > > > At the end you need to consider that file based locking has issues, it > > > does not work everywhere, it is advisory at best, it protects you only > > > from multiprocess access, multithreaded requires an extra layer of > > > in-JVM locks. Given that we are all volunteers and the pain for the > > > community isn't big enough to contribute something valuable, I won't. > > > Especially that Tamás and me invested almost year developing the named > > > locks approach with pluggable providers is more than enough to solve > any > > > type of build setup on any FS and OS. > > > > > > I'd like to quote Marshall Kirk McKusick: Why write something good if > > > you can steal something better? (trade file locks with Redis). > > > > > > A more lightweight approach would be something like POSIX semaphores > > > available everywhere, but Windows. Requires likely native code or JNR > > > and time. Out of personal interest I'd peek at it next year. > > > > > > M > > > > > > > Le lun. 4 oct. 2021 à 22:13, Michael Osipov a > > > écrit : > > > > > > > >> Tamás, > > > >> > > > >> Redis is so easy to install and get going in 5 minutes that I would > > > >> rather see your energy go into areas which need more attention. > > > >> > > > >> M > > > >> > > > >> Am 2021-10-04 um 22:02 schrieb Tamás Cservenák: > > > >>> Hi Bernd, > > > >>> > > > >>> nothing is wrong with advisory file locking, as long as you don't > > store > > > >>> local repo on NFS ;) > > > >>> Will re-add file locking once I get there, as in my opinion it is > the > > > >> most > > > >>> "lightweight" MP (multi process) solution on a single host. > > > >>> Redis and
Re: Local repository accessed by multiple Maven instances - how is it solved ?
Hi Delany, from Sisu website: "Sisu is a modular JSR330-based container that supports *classpath scanning*, *auto-binding*, and *dynamic auto-wiring*. Sisu uses Google-Guice to perform dependency injection and provide the core JSR330 support, but removes the need to write explicit bindings in Guice modules.". Simply, SISU will scan your classpath for components and dynamically pick them up and wire them up. For Guice, you need to _explicitly add_ bindings (as this "dynamism" is a Sisu feature). ServiceLocator is deprecated, leave it out (but same thing stands: is "static"). === More simpler: with Sisu, just throw a component onto classpath, and Sisu will "automagically" pick it up, no code change needed. This is how extensions and other things work in Maven for example (just copy a JAR with components to classpath and they are discovered). Locking implementations like Redisson and Hazelcast are "opt-in", they are not bundled with Maven (to not bloat distro). They work only after you "install" them (provide JARs with their components and all component dependencies to Maven classpath, as explained in the Install step on that page). This remark you quoted is geared more toward "resolver integrators", for those using Resolver into some other project than Maven. If you integrate Resolver, then: - if you use Sisu, you have nothing to do :) - if you use vanilla Guice, then in your integration you have to provide the things you want on classpath and explicitly bind them - if you use ServiceLocator, move away from it (will be soon dropped), simplest is to "roll your own" bootstrap class (that does same as ServiceLocator was doing, statically wiring things up), and again, you should upfront provide whatever you need on classpath and instantiate them using your own "bootstrap" class. If you just want to use it with Maven, nothing to be done for you, just Install it as per page. === HTH Tamas On Thu, Oct 7, 2021 at 10:07 AM Delany wrote: > Michael, could you clarify this line pls: "It only works when Sisu DI is > used and not the bundled AetherModule or ServiceLocator (Maven uses Sisu > dependency injection)." > > https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html > > What should I do about this issue? > > Thanks, > Delany > > > On Wed, 6 Oct 2021 at 22:18, Michael Osipov wrote: > > > Am 2021-10-06 um 21:05 schrieb Francois Marot: > > > Michael, I do not agree. As a user and maintainer of the build chain in > > my > > > company, I think Maven would really benefit from an out of the box > > > solution. I think any user is susceptible to the bug by launching > > multiple > > > Maven instances at the same time on his computer. Bugs then encountered > > are > > > really a bad sign sent to users, and requiring each dev to setup a > > database > > > (even simple) is cumbersome. > > > > I agree with you, but we are developers after all, I can expect people > > to set up something if necessary. > > At the end you need to consider that file based locking has issues, it > > does not work everywhere, it is advisory at best, it protects you only > > from multiprocess access, multithreaded requires an extra layer of > > in-JVM locks. Given that we are all volunteers and the pain for the > > community isn't big enough to contribute something valuable, I won't. > > Especially that Tamás and me invested almost year developing the named > > locks approach with pluggable providers is more than enough to solve any > > type of build setup on any FS and OS. > > > > I'd like to quote Marshall Kirk McKusick: Why write something good if > > you can steal something better? (trade file locks with Redis). > > > > A more lightweight approach would be something like POSIX semaphores > > available everywhere, but Windows. Requires likely native code or JNR > > and time. Out of personal interest I'd peek at it next year. > > > > M > > > > > Le lun. 4 oct. 2021 à 22:13, Michael Osipov a > > écrit : > > > > > >> Tamás, > > >> > > >> Redis is so easy to install and get going in 5 minutes that I would > > >> rather see your energy go into areas which need more attention. > > >> > > >> M > > >> > > >> Am 2021-10-04 um 22:02 schrieb Tamás Cservenák: > > >>> Hi Bernd, > > >>> > > >>> nothing is wrong with advisory file locking, as long as you don't > store > > >>> local repo on NFS ;) > > >>> Will re-add file locking once I get there, as in my opinion it is the > > >> most > > >>> "lightweight" MP (multi process) solution on a single host. > > >>> Redis and Hazelcast are more for "farms", where several hosts with > many > > >>> processes (and each with many threads) is bashing local repo (that > MAY > > be > > >>> on NFS as well). > > >>> > > >>> Thanks > > >>> Tamas > > >>> > > >>> On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels < > e...@zusammenkunft.net > > > > > >>> wrote: > > >>> > > What’s the problem with adivisory locking, as long as Maven honors > the > > advice it is the same as it’s a
Re: Local repository accessed by multiple Maven instances - how is it solved ?
Michael, could you clarify this line pls: "It only works when Sisu DI is used and not the bundled AetherModule or ServiceLocator (Maven uses Sisu dependency injection)." https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html What should I do about this issue? Thanks, Delany On Wed, 6 Oct 2021 at 22:18, Michael Osipov wrote: > Am 2021-10-06 um 21:05 schrieb Francois Marot: > > Michael, I do not agree. As a user and maintainer of the build chain in > my > > company, I think Maven would really benefit from an out of the box > > solution. I think any user is susceptible to the bug by launching > multiple > > Maven instances at the same time on his computer. Bugs then encountered > are > > really a bad sign sent to users, and requiring each dev to setup a > database > > (even simple) is cumbersome. > > I agree with you, but we are developers after all, I can expect people > to set up something if necessary. > At the end you need to consider that file based locking has issues, it > does not work everywhere, it is advisory at best, it protects you only > from multiprocess access, multithreaded requires an extra layer of > in-JVM locks. Given that we are all volunteers and the pain for the > community isn't big enough to contribute something valuable, I won't. > Especially that Tamás and me invested almost year developing the named > locks approach with pluggable providers is more than enough to solve any > type of build setup on any FS and OS. > > I'd like to quote Marshall Kirk McKusick: Why write something good if > you can steal something better? (trade file locks with Redis). > > A more lightweight approach would be something like POSIX semaphores > available everywhere, but Windows. Requires likely native code or JNR > and time. Out of personal interest I'd peek at it next year. > > M > > > Le lun. 4 oct. 2021 à 22:13, Michael Osipov a > écrit : > > > >> Tamás, > >> > >> Redis is so easy to install and get going in 5 minutes that I would > >> rather see your energy go into areas which need more attention. > >> > >> M > >> > >> Am 2021-10-04 um 22:02 schrieb Tamás Cservenák: > >>> Hi Bernd, > >>> > >>> nothing is wrong with advisory file locking, as long as you don't store > >>> local repo on NFS ;) > >>> Will re-add file locking once I get there, as in my opinion it is the > >> most > >>> "lightweight" MP (multi process) solution on a single host. > >>> Redis and Hazelcast are more for "farms", where several hosts with many > >>> processes (and each with many threads) is bashing local repo (that MAY > be > >>> on NFS as well). > >>> > >>> Thanks > >>> Tamas > >>> > >>> On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels > > >>> wrote: > >>> > What’s the problem with adivisory locking, as long as Maven honors the > advice it is the same as it’s a redis lock? (But much less footprint). > >> In > fact on the same machine it should even work without locking as Long > as > >> you > use pidfiles? > > Gruss > Bernd > > > >>> > >> > >> > >> > >> - > >> 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: Local repository accessed by multiple Maven instances - how is it solved ?
Am 2021-10-06 um 21:05 schrieb Francois Marot: Michael, I do not agree. As a user and maintainer of the build chain in my company, I think Maven would really benefit from an out of the box solution. I think any user is susceptible to the bug by launching multiple Maven instances at the same time on his computer. Bugs then encountered are really a bad sign sent to users, and requiring each dev to setup a database (even simple) is cumbersome. I agree with you, but we are developers after all, I can expect people to set up something if necessary. At the end you need to consider that file based locking has issues, it does not work everywhere, it is advisory at best, it protects you only from multiprocess access, multithreaded requires an extra layer of in-JVM locks. Given that we are all volunteers and the pain for the community isn't big enough to contribute something valuable, I won't. Especially that Tamás and me invested almost year developing the named locks approach with pluggable providers is more than enough to solve any type of build setup on any FS and OS. I'd like to quote Marshall Kirk McKusick: Why write something good if you can steal something better? (trade file locks with Redis). A more lightweight approach would be something like POSIX semaphores available everywhere, but Windows. Requires likely native code or JNR and time. Out of personal interest I'd peek at it next year. M Le lun. 4 oct. 2021 à 22:13, Michael Osipov a écrit : Tamás, Redis is so easy to install and get going in 5 minutes that I would rather see your energy go into areas which need more attention. M Am 2021-10-04 um 22:02 schrieb Tamás Cservenák: Hi Bernd, nothing is wrong with advisory file locking, as long as you don't store local repo on NFS ;) Will re-add file locking once I get there, as in my opinion it is the most "lightweight" MP (multi process) solution on a single host. Redis and Hazelcast are more for "farms", where several hosts with many processes (and each with many threads) is bashing local repo (that MAY be on NFS as well). Thanks Tamas On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels wrote: What’s the problem with adivisory locking, as long as Maven honors the advice it is the same as it’s a redis lock? (But much less footprint). In fact on the same machine it should even work without locking as Long as you use pidfiles? Gruss Bernd - 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: Local repository accessed by multiple Maven instances - how is it solved ?
Michael, I do not agree. As a user and maintainer of the build chain in my company, I think Maven would really benefit from an out of the box solution. I think any user is susceptible to the bug by launching multiple Maven instances at the same time on his computer. Bugs then encountered are really a bad sign sent to users, and requiring each dev to setup a database (even simple) is cumbersome. Regards François Le lun. 4 oct. 2021 à 22:13, Michael Osipov a écrit : > Tamás, > > Redis is so easy to install and get going in 5 minutes that I would > rather see your energy go into areas which need more attention. > > M > > Am 2021-10-04 um 22:02 schrieb Tamás Cservenák: > > Hi Bernd, > > > > nothing is wrong with advisory file locking, as long as you don't store > > local repo on NFS ;) > > Will re-add file locking once I get there, as in my opinion it is the > most > > "lightweight" MP (multi process) solution on a single host. > > Redis and Hazelcast are more for "farms", where several hosts with many > > processes (and each with many threads) is bashing local repo (that MAY be > > on NFS as well). > > > > Thanks > > Tamas > > > > On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels > > wrote: > > > >> What’s the problem with adivisory locking, as long as Maven honors the > >> advice it is the same as it’s a redis lock? (But much less footprint). > In > >> fact on the same machine it should even work without locking as Long as > you > >> use pidfiles? > >> > >> Gruss > >> Bernd > >> > >> > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Local repository accessed by multiple Maven instances - how is it solved ?
Just chiming in on my experience using the redis locks with maven 3.8.x and resolver 1.6. I've been running it on my Jenkins nodes for about a year now with great success. Before it, we had corrupted local maven repos (zip file empty kind of exceptions) a couple of times a week. Then, we configured Jenkins to properly handle multiple concurrent builds by not sharing the maven local repo and run each build in docker which is wasteful since you have to redownload all your dependencies on each build and build time is obviously very long. Then I bumped into the lock feature which is available on resolver 1.6 (instructions here https://svn.apache.org/repos/asf/maven/website/components/resolver-archives/resolver-1.6.3/maven-resolver-synccontext-redisson/index.html). It is a bit cumbersome to setup but after that, we started sharing the same local repos and our build time dramatically improved (something like from 4 minutes to ~30 seconds) and we had a corrupted maven repo once or twice throughout the year (and it could have been some job that a dev created without the proper config, I didn't investigate much). Redis is really easy to setup and is available via docker or apt so it should be a breeze to add it to your init script like we did. My nodes had docker already installed so it was just adding this to the "Init script" in the nodes configuration : #!/bin/bash -ue docker run -d --network host --name mvn_redis redis:6.2-alpine I'd be interested to keep up with all the latest work that have been done on this in resolver 1.7, that's why I created another issue to request a java 8 maven 3.9 release. On 2021/10/04 20:13:45, Francois Marot wrote: > "Salut" Michael, > > thanks for the detailled answer. > Regarding my Jenkins 'hack' you can totally forget about it: it just > ensures no more than one Maven execution uses a given repo at once by > locating the local repositories in a folder reflecting the executor (which > are kinda Jenkins "threads"). > I plan not to use your work right now mostly because it would involve > setting up a Redis Database and my 'hack' still works (despite using a lot > of disk space and being a bit slow). > > If I understand correctly after Tams' message, your work is mostly geared > toward running multiple Maven build in parallel and on multiple hosts, all > sharing one big "local" repository through the network. Am I correct ? In > my case, I have multiple Jenkins workers but never thought about making > them collaborate on a shared "local" repo. I'll have to think about it ! > > Thanks ! > > François > > > > Le lun. 4 oct. 2021 à 21:22, Michael Osipov a écrit : > > > Am 2021-10-04 um 14:31 schrieb Francois Marot: > > > Hello all, > > > > > > I would like clarifications on MNG-2802[*] that seems to be solved. If I > > > understand correctly it solves the problem where multiple simultaneous > > > Maven executions shared the same local repository. > > > I have been keeping for years a bit of code in my Jenkinsfiles ensuring > > the > > > local repos were accessed only by a single jenkins executor at the same > > > time, so it seems like I can get rid of this doesn't it ? > > > I'd like your input on this because reproducing the bug is difficult so > > I'd > > > like to be sure before simplifying my Jenkinsfile. > > > > > > Moreover, does anyone know how this problem is solved technically ? Using > > > files lock ? Can anybody explain ? > > > > > > Thanks you and thanks the Maven team for keeping up the good work at such > > > pace ! > > > > Salut François, > > > > I don't know what you exactly fiddled in your Jenkinsfile, but there is > > no way make it right just with Jenkinsfile foo when you want access > > *one* local repo with *multiple* processes you *must* use an external > > coordinator process. > > Forget also about file locks, they are all advisory, at least on > > POSIX-like filesystems. There is no way, or a very hard way to make them > > right. We tried and removed them. > > > > Now, let me give you bit of history: I have integrated/implemented a > > fully working multi-process Redisson-based synchronization lock factory > > for Maven Resolver 1.6.x which ships with Maven 3.8.x. (It has already > > been battle tested for several months by a user on a busy CI server). > > Tamás took it to the next level in Resolver 1.7.x and generalized it to > > a named lock approach where the Redisson Lock Factory plugs in nicely > > with other lock implementations. Almost nine months of work and it works > > very good now. > > Now here is the proble
Re: Local repository accessed by multiple Maven instances - how is it solved ?
Am 2021-10-04 um 22:13 schrieb Francois Marot: "Salut" Michael, thanks for the detailled answer. Regarding my Jenkins 'hack' you can totally forget about it: it just ensures no more than one Maven execution uses a given repo at once by locating the local repositories in a folder reflecting the executor (which are kinda Jenkins "threads"). I plan not to use your work right now mostly because it would involve setting up a Redis Database and my 'hack' still works (despite using a lot of disk space and being a bit slow). If I understand correctly after Tams' message, your work is mostly geared toward running multiple Maven build in parallel and on multiple hosts, all sharing one big "local" repository through the network. Am I correct ? In my case, I have multiple Jenkins workers but never thought about making them collaborate on a shared "local" repo. I'll have to think about it ! Not quite, we have multiple named locks which will give you the granularity you need. Either in-JVM only, or multi-JVM. Then it does not matter whether it is on the same host or not. You decide, the Redisson approach will work. You need to read the docs how named locks are discrimnated with a lock impl. That is all. You will benefit. User I was talking about has now a huge speed bump due to the shared local repo, for free. M - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Local repository accessed by multiple Maven instances - how is it solved ?
"Salut" Michael, thanks for the detailled answer. Regarding my Jenkins 'hack' you can totally forget about it: it just ensures no more than one Maven execution uses a given repo at once by locating the local repositories in a folder reflecting the executor (which are kinda Jenkins "threads"). I plan not to use your work right now mostly because it would involve setting up a Redis Database and my 'hack' still works (despite using a lot of disk space and being a bit slow). If I understand correctly after Tams' message, your work is mostly geared toward running multiple Maven build in parallel and on multiple hosts, all sharing one big "local" repository through the network. Am I correct ? In my case, I have multiple Jenkins workers but never thought about making them collaborate on a shared "local" repo. I'll have to think about it ! Thanks ! François Le lun. 4 oct. 2021 à 21:22, Michael Osipov a écrit : > Am 2021-10-04 um 14:31 schrieb Francois Marot: > > Hello all, > > > > I would like clarifications on MNG-2802[*] that seems to be solved. If I > > understand correctly it solves the problem where multiple simultaneous > > Maven executions shared the same local repository. > > I have been keeping for years a bit of code in my Jenkinsfiles ensuring > the > > local repos were accessed only by a single jenkins executor at the same > > time, so it seems like I can get rid of this doesn't it ? > > I'd like your input on this because reproducing the bug is difficult so > I'd > > like to be sure before simplifying my Jenkinsfile. > > > > Moreover, does anyone know how this problem is solved technically ? Using > > files lock ? Can anybody explain ? > > > > Thanks you and thanks the Maven team for keeping up the good work at such > > pace ! > > Salut François, > > I don't know what you exactly fiddled in your Jenkinsfile, but there is > no way make it right just with Jenkinsfile foo when you want access > *one* local repo with *multiple* processes you *must* use an external > coordinator process. > Forget also about file locks, they are all advisory, at least on > POSIX-like filesystems. There is no way, or a very hard way to make them > right. We tried and removed them. > > Now, let me give you bit of history: I have integrated/implemented a > fully working multi-process Redisson-based synchronization lock factory > for Maven Resolver 1.6.x which ships with Maven 3.8.x. (It has already > been battle tested for several months by a user on a busy CI server). > Tamás took it to the next level in Resolver 1.7.x and generalized it to > a named lock approach where the Redisson Lock Factory plugs in nicely > with other lock implementations. Almost nine months of work and it works > very good now. > Now here is the problem: Maven Resolver 1.7.x comes only with Maven 4.x. > I have created a branch which reconciles best of breed: Maven 3.8.x and > Maven Resolver 1.7.x. It just works (also verified by this user). I also > ran more than a thousand builds with 8 parallel processes and 4 threads. > It will easily handle thousands of locks in parralel with an one digit > percent overhead. > > I don't know for what documentation you are waiting for, but everything > is there, you can start *now* to leverage it: [2], [3]. With Resolver > 2.0.0 and Maven 4.0.0 it will likely be even easier to integrate. > > Hazelcast will also work, but Tamás is the special here. > > Again: You *must* use an external process to synchronize access. No > excuses. > > Michael > > [1] https://github.com/apache/maven/tree/maven-3.8.x-resolver-1.7.x > [2] > https://maven.apache.org/resolver/maven-resolver-named-locks/index.html > [3] > > https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Local repository accessed by multiple Maven instances - how is it solved ?
Even for nfs fcntl locking can work and create/ln/mv are atomic. Do you know if there is any file lock based impl available? Gruss Bernd -- http://bernd.eckenfels.net Von: Tamás Cservenák Gesendet: Monday, October 4, 2021 10:02:27 PM An: Maven Users List Betreff: Re: Local repository accessed by multiple Maven instances - how is it solved ? Hi Bernd, nothing is wrong with advisory file locking, as long as you don't store local repo on NFS ;) Will re-add file locking once I get there, as in my opinion it is the most "lightweight" MP (multi process) solution on a single host. Redis and Hazelcast are more for "farms", where several hosts with many processes (and each with many threads) is bashing local repo (that MAY be on NFS as well). Thanks Tamas On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels wrote: > What’s the problem with adivisory locking, as long as Maven honors the > advice it is the same as it’s a redis lock? (But much less footprint). In > fact on the same machine it should even work without locking as Long as you > use pidfiles? > > Gruss > Bernd > >
Re: Local repository accessed by multiple Maven instances - how is it solved ?
Tamás, Redis is so easy to install and get going in 5 minutes that I would rather see your energy go into areas which need more attention. M Am 2021-10-04 um 22:02 schrieb Tamás Cservenák: Hi Bernd, nothing is wrong with advisory file locking, as long as you don't store local repo on NFS ;) Will re-add file locking once I get there, as in my opinion it is the most "lightweight" MP (multi process) solution on a single host. Redis and Hazelcast are more for "farms", where several hosts with many processes (and each with many threads) is bashing local repo (that MAY be on NFS as well). Thanks Tamas On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels wrote: What’s the problem with adivisory locking, as long as Maven honors the advice it is the same as it’s a redis lock? (But much less footprint). In fact on the same machine it should even work without locking as Long as you use pidfiles? Gruss Bernd - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Local repository accessed by multiple Maven instances - how is it solved ?
Hi Bernd, nothing is wrong with advisory file locking, as long as you don't store local repo on NFS ;) Will re-add file locking once I get there, as in my opinion it is the most "lightweight" MP (multi process) solution on a single host. Redis and Hazelcast are more for "farms", where several hosts with many processes (and each with many threads) is bashing local repo (that MAY be on NFS as well). Thanks Tamas On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels wrote: > What’s the problem with adivisory locking, as long as Maven honors the > advice it is the same as it’s a redis lock? (But much less footprint). In > fact on the same machine it should even work without locking as Long as you > use pidfiles? > > Gruss > Bernd > >
Re: Local repository accessed by multiple Maven instances - how is it solved ?
What’s the problem with adivisory locking, as long as Maven honors the advice it is the same as it’s a redis lock? (But much less footprint). In fact on the same machine it should even work without locking as Long as you use pidfiles? Gruss Bernd -- http://bernd.eckenfels.net Von: Michael Osipov Gesendet: Monday, October 4, 2021 9:15:23 PM An: users@maven.apache.org Betreff: Re: Local repository accessed by multiple Maven instances - how is it solved ? Am 2021-10-04 um 14:31 schrieb Francois Marot: > Hello all, > > I would like clarifications on MNG-2802[*] that seems to be solved. If I > understand correctly it solves the problem where multiple simultaneous > Maven executions shared the same local repository. > I have been keeping for years a bit of code in my Jenkinsfiles ensuring the > local repos were accessed only by a single jenkins executor at the same > time, so it seems like I can get rid of this doesn't it ? > I'd like your input on this because reproducing the bug is difficult so I'd > like to be sure before simplifying my Jenkinsfile. > > Moreover, does anyone know how this problem is solved technically ? Using > files lock ? Can anybody explain ? > > Thanks you and thanks the Maven team for keeping up the good work at such > pace ! Salut François, I don't know what you exactly fiddled in your Jenkinsfile, but there is no way make it right just with Jenkinsfile foo when you want access *one* local repo with *multiple* processes you *must* use an external coordinator process. Forget also about file locks, they are all advisory, at least on POSIX-like filesystems. There is no way, or a very hard way to make them right. We tried and removed them. Now, let me give you bit of history: I have integrated/implemented a fully working multi-process Redisson-based synchronization lock factory for Maven Resolver 1.6.x which ships with Maven 3.8.x. (It has already been battle tested for several months by a user on a busy CI server). Tamás took it to the next level in Resolver 1.7.x and generalized it to a named lock approach where the Redisson Lock Factory plugs in nicely with other lock implementations. Almost nine months of work and it works very good now. Now here is the problem: Maven Resolver 1.7.x comes only with Maven 4.x. I have created a branch which reconciles best of breed: Maven 3.8.x and Maven Resolver 1.7.x. It just works (also verified by this user). I also ran more than a thousand builds with 8 parallel processes and 4 threads. It will easily handle thousands of locks in parralel with an one digit percent overhead. I don't know for what documentation you are waiting for, but everything is there, you can start *now* to leverage it: [2], [3]. With Resolver 2.0.0 and Maven 4.0.0 it will likely be even easier to integrate. Hazelcast will also work, but Tamás is the special here. Again: You *must* use an external process to synchronize access. No excuses. Michael [1] https://github.com/apache/maven/tree/maven-3.8.x-resolver-1.7.x [2] https://maven.apache.org/resolver/maven-resolver-named-locks/index.html [3] https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Local repository accessed by multiple Maven instances - how is it solved ?
Am 2021-10-04 um 14:31 schrieb Francois Marot: Hello all, I would like clarifications on MNG-2802[*] that seems to be solved. If I understand correctly it solves the problem where multiple simultaneous Maven executions shared the same local repository. I have been keeping for years a bit of code in my Jenkinsfiles ensuring the local repos were accessed only by a single jenkins executor at the same time, so it seems like I can get rid of this doesn't it ? I'd like your input on this because reproducing the bug is difficult so I'd like to be sure before simplifying my Jenkinsfile. Moreover, does anyone know how this problem is solved technically ? Using files lock ? Can anybody explain ? Thanks you and thanks the Maven team for keeping up the good work at such pace ! Salut François, I don't know what you exactly fiddled in your Jenkinsfile, but there is no way make it right just with Jenkinsfile foo when you want access *one* local repo with *multiple* processes you *must* use an external coordinator process. Forget also about file locks, they are all advisory, at least on POSIX-like filesystems. There is no way, or a very hard way to make them right. We tried and removed them. Now, let me give you bit of history: I have integrated/implemented a fully working multi-process Redisson-based synchronization lock factory for Maven Resolver 1.6.x which ships with Maven 3.8.x. (It has already been battle tested for several months by a user on a busy CI server). Tamás took it to the next level in Resolver 1.7.x and generalized it to a named lock approach where the Redisson Lock Factory plugs in nicely with other lock implementations. Almost nine months of work and it works very good now. Now here is the problem: Maven Resolver 1.7.x comes only with Maven 4.x. I have created a branch which reconciles best of breed: Maven 3.8.x and Maven Resolver 1.7.x. It just works (also verified by this user). I also ran more than a thousand builds with 8 parallel processes and 4 threads. It will easily handle thousands of locks in parralel with an one digit percent overhead. I don't know for what documentation you are waiting for, but everything is there, you can start *now* to leverage it: [2], [3]. With Resolver 2.0.0 and Maven 4.0.0 it will likely be even easier to integrate. Hazelcast will also work, but Tamás is the special here. Again: You *must* use an external process to synchronize access. No excuses. Michael [1] https://github.com/apache/maven/tree/maven-3.8.x-resolver-1.7.x [2] https://maven.apache.org/resolver/maven-resolver-named-locks/index.html [3] https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Local repository accessed by multiple Maven instances - how is it solved ?
Yes, these are good news! Am 04.10.21 um 15:10 schrieb Thomas Broyer: From JIRA links, this is apparently fixed by https://issues.apache.org/jira/browse/MRESOLVER-131, which means you need to deploy a Redis server. There apparently also is an Hazelcast-based version: https://maven.apache.org/resolver/maven-resolver-named-locks/index.html On Mon, Oct 4, 2021 at 2:32 PM Francois Marot wrote: Hello all, I would like clarifications on MNG-2802[*] that seems to be solved. If I understand correctly it solves the problem where multiple simultaneous Maven executions shared the same local repository. I have been keeping for years a bit of code in my Jenkinsfiles ensuring the local repos were accessed only by a single jenkins executor at the same time, so it seems like I can get rid of this doesn't it ? I'd like your input on this because reproducing the bug is difficult so I'd like to be sure before simplifying my Jenkinsfile. Moreover, does anyone know how this problem is solved technically ? Using files lock ? Can anybody explain ? Thanks you and thanks the Maven team for keeping up the good work at such pace ! François MAROT * https://issues.apache.org/jira/browse/MNG-2802 -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b.fisc...@swe-blog.net S oliver.b.fischer J oliver.b.fisc...@jabber.org X http://xing.to/obf - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Local repository accessed by multiple Maven instances - how is it solved ?
Wooohaa, thanks Thomas. It's a whole new world being revealed to me: I wasn't aware of the huge work happening on artifact resolvers. At the same time, it seems not to be available out of the box (needs a Redis server) so I'll keep my Jenkinsfile hacks for now and will wait for proper documentation and how-to. Thanks for the pointers ! *François Marot* Le lun. 4 oct. 2021 à 15:10, Thomas Broyer a écrit : > From JIRA links, this is apparently fixed by > https://issues.apache.org/jira/browse/MRESOLVER-131, which means you need > to deploy a Redis server. > There apparently also is an Hazelcast-based version: > https://maven.apache.org/resolver/maven-resolver-named-locks/index.html > > On Mon, Oct 4, 2021 at 2:32 PM Francois Marot > wrote: > > > Hello all, > > > > I would like clarifications on MNG-2802[*] that seems to be solved. If I > > understand correctly it solves the problem where multiple simultaneous > > Maven executions shared the same local repository. > > I have been keeping for years a bit of code in my Jenkinsfiles ensuring > the > > local repos were accessed only by a single jenkins executor at the same > > time, so it seems like I can get rid of this doesn't it ? > > I'd like your input on this because reproducing the bug is difficult so > I'd > > like to be sure before simplifying my Jenkinsfile. > > > > Moreover, does anyone know how this problem is solved technically ? Using > > files lock ? Can anybody explain ? > > > > Thanks you and thanks the Maven team for keeping up the good work at such > > pace ! > > > > François MAROT > > > > > > * https://issues.apache.org/jira/browse/MNG-2802 > > > > > -- > Thomas Broyer > /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> < > http://xn--nna.ma.xn--bwa-xxb.je/> >
Re: Local repository accessed by multiple Maven instances - how is it solved ?
>From JIRA links, this is apparently fixed by https://issues.apache.org/jira/browse/MRESOLVER-131, which means you need to deploy a Redis server. There apparently also is an Hazelcast-based version: https://maven.apache.org/resolver/maven-resolver-named-locks/index.html On Mon, Oct 4, 2021 at 2:32 PM Francois Marot wrote: > Hello all, > > I would like clarifications on MNG-2802[*] that seems to be solved. If I > understand correctly it solves the problem where multiple simultaneous > Maven executions shared the same local repository. > I have been keeping for years a bit of code in my Jenkinsfiles ensuring the > local repos were accessed only by a single jenkins executor at the same > time, so it seems like I can get rid of this doesn't it ? > I'd like your input on this because reproducing the bug is difficult so I'd > like to be sure before simplifying my Jenkinsfile. > > Moreover, does anyone know how this problem is solved technically ? Using > files lock ? Can anybody explain ? > > Thanks you and thanks the Maven team for keeping up the good work at such > pace ! > > François MAROT > > > * https://issues.apache.org/jira/browse/MNG-2802 > -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
Local repository accessed by multiple Maven instances - how is it solved ?
Hello all, I would like clarifications on MNG-2802[*] that seems to be solved. If I understand correctly it solves the problem where multiple simultaneous Maven executions shared the same local repository. I have been keeping for years a bit of code in my Jenkinsfiles ensuring the local repos were accessed only by a single jenkins executor at the same time, so it seems like I can get rid of this doesn't it ? I'd like your input on this because reproducing the bug is difficult so I'd like to be sure before simplifying my Jenkinsfile. Moreover, does anyone know how this problem is solved technically ? Using files lock ? Can anybody explain ? Thanks you and thanks the Maven team for keeping up the good work at such pace ! François MAROT * https://issues.apache.org/jira/browse/MNG-2802
Re: list of libraries in maven local repository
The directory tree is build out of your groupId. If your groupId is a.b.c, it should be a/b/c I am sure Gradle has a verbose mode (--verbose) or something like this. Can you turn it on and check it for helpful messages? Did you try find to find your artifact? I mean something like find . -name "myJar.jar"? Am 09.03.21 um 12:03 schrieb Nikos Karamolegkos: I know but in which sub-folder of the repository? On 9/3/21 12:47 μ.μ., Oliver B. Fischer wrote: The default configuration of Maven is to have its local repository in the directory ./m2/repository. Below this directory you should find your artifact. Am 09.03.21 um 11:25 schrieb Nikos Karamolegkos: Hello, I am trying to add a library to my maven local repository using ./gradlew publishToMavenLocal. How can I check that the library is really installed to the repository? Thank you -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b.fisc...@swe-blog.net S oliver.b.fischer J oliver.b.fisc...@jabber.org X http://xing.to/obf - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: list of libraries in maven local repository
I know but in which sub-folder of the repository? On 9/3/21 12:47 μ.μ., Oliver B. Fischer wrote: The default configuration of Maven is to have its local repository in the directory ./m2/repository. Below this directory you should find your artifact. Am 09.03.21 um 11:25 schrieb Nikos Karamolegkos: Hello, I am trying to add a library to my maven local repository using ./gradlew publishToMavenLocal. How can I check that the library is really installed to the repository? Thank you -- Nikos Karamolegkos R & D engineer at ICS-FORTH Telecommunications and Networks Lab (TNL) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: list of libraries in maven local repository
The default configuration of Maven is to have its local repository in the directory ./m2/repository. Below this directory you should find your artifact. Am 09.03.21 um 11:25 schrieb Nikos Karamolegkos: Hello, I am trying to add a library to my maven local repository using ./gradlew publishToMavenLocal. How can I check that the library is really installed to the repository? Thank you -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b.fisc...@swe-blog.net S oliver.b.fischer J oliver.b.fisc...@jabber.org X http://xing.to/obf - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
list of libraries in maven local repository
Hello, I am trying to add a library to my maven local repository using ./gradlew publishToMavenLocal. How can I check that the library is really installed to the repository? Thank you -- Nikos Karamolegkos R & D engineer at ICS-FORTH Telecommunications and Networks Lab (TNL) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: not storing/getting artifacts in/from local repository
If you turn on debut logging for the build you can grep for the artifact name. In your specific case however I guess it's found in the relative parent of your project. An other option might be any profile which is auto activated. Btw you can use the build helper plugin and ask it to produce the effective Pom, it should be the same for both system. You can also let it list (active) profiles. https://maven.apache.org/plugins/maven-help-plugin/effective-pom-mojo.html https://maven.apache.org/plugins/maven-help-plugin/active-profiles-mojo.html Effective settings and help:system could also show differences. Gruss Bernd -- http://bernd.eckenfels.net Von: Enrique Mingorance Cano Gesendet: Friday, May 8, 2020 2:09:42 PM An: users@maven.apache.org Betreff: not storing/getting artifacts in/from local repository Hello, I have a question about how I can see an artifact being taken. Let me explain the situation. This is more a question than a bug itself (I guess so) I have two machines: - I build the same project https://github.com/kiegroup/appformer/ from both of them. - same maven version in both of them 3.5.2 - same settings.xml in both of them - clean repository ~/.m2/repository in both of them - both of them show the same DEBUG informationThis is more a question than a bug itself (I guess so) [DEBUG] Reading global settings from /opt/tools/apache-maven-3.5.2/conf/settings.xml [DEBUG] Reading user settings from /home/user/settings.xml [DEBUG] Reading global toolchains from /opt/tools/apache-maven-3.5.2/conf/toolchains.xml [DEBUG] Reading user toolchains from /home/user/.m2/toolchains.xml [DEBUG] Using local repository at /home/user/.m2/repository [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0 for /home/user/.m2/repository I run the command (-pl and -am to make the test faster) with OK in both of them /opt/tools/apache-maven-3.5.2/bin/mvn -s /home/user/settings.xml -DskipTests clean install -pl :appformer-js -am In the first machine: - the kie-parent and the rest of the artifacts are in the ~/.m2/repository folder (org/kie/kie-parent) In the second machine: - the kie-parent IS NOT but some other artifacts in the ~/.m2/repository folder so... my question is, *where should/can they be? How can I know where maven is taking the kie-parent artifact from?* Thanks a lot, Kike.
not storing/getting artifacts in/from local repository
Hello, I have a question about how I can see an artifact being taken. Let me explain the situation. This is more a question than a bug itself (I guess so) I have two machines: - I build the same project https://github.com/kiegroup/appformer/ from both of them. - same maven version in both of them 3.5.2 - same settings.xml in both of them - clean repository ~/.m2/repository in both of them - both of them show the same DEBUG informationThis is more a question than a bug itself (I guess so) [DEBUG] Reading global settings from /opt/tools/apache-maven-3.5.2/conf/settings.xml [DEBUG] Reading user settings from /home/user/settings.xml [DEBUG] Reading global toolchains from /opt/tools/apache-maven-3.5.2/conf/toolchains.xml [DEBUG] Reading user toolchains from /home/user/.m2/toolchains.xml [DEBUG] Using local repository at /home/user/.m2/repository [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0 for /home/user/.m2/repository I run the command (-pl and -am to make the test faster) with OK in both of them /opt/tools/apache-maven-3.5.2/bin/mvn -s /home/user/settings.xml -DskipTests clean install -pl :appformer-js -am In the first machine: - the kie-parent and the rest of the artifacts are in the ~/.m2/repository folder (org/kie/kie-parent) In the second machine: - the kie-parent IS NOT but some other artifacts in the ~/.m2/repository folder so... my question is, *where should/can they be? How can I know where maven is taking the kie-parent artifact from?* Thanks a lot, Kike.
Re: Installing a File into Local Repository
Have you considered using
https://www.mojohaus.org/build-helper-maven-plugin/attach-artifact-mojo.html
<https://www.mojohaus.org/build-helper-maven-plugin/attach-artifact-mojo.html>
Or http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html
<http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html> ?
Perhaps inspecting the source code for these plugins will help you.
> On Jan 24, 2020, at 8:18 AM, Andreas Schaefer
> wrote:
>
> Hi
>
> I want to install a file into my local repository. The code below did work at
> one time but now it is creating the file in the local repository but that
> file is empty. Any idea on how to fix it or is there another way to do that?
>
> Current Maven version:
>
> mvn --version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /Java/maven3
> Java version: 1.8.0_201, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: “mac"
>
> Requirements:
>
> This code is installing a generated file (JSon file) into the local
> repository with the extension ’slingosgifeature’. The packaging is ‘jar’ as
> this project creates a JAR file. That said it needs also to install that file
> into the local repository.
>
> Code:
>
> private void installFMDescriptor(File file, Feature feature) {
>Collection artifacts =
> Collections.synchronizedCollection(new ArrayList<>());
>if(file.exists() && file.canRead()) {
>getLog().debug("FM File to be installed: " + file.getAbsolutePath());
>// Need to create a new Artifact Handler for the different extension
> and an Artifact to not
>// change the module artifact
>DefaultArtifactHandler fmArtifactHandler = new
> DefaultArtifactHandler("slingosgifeature");
>ArtifactId artifactId = feature.getId();
>DefaultArtifact fmArtifact = new DefaultArtifact(
>artifactId.getGroupId(), artifactId.getArtifactId(),
> artifactId.getVersion(),
>null, "slingosgifeature", null, fmArtifactHandler
>);
>fmArtifact.setFile(file);
>artifacts.add(fmArtifact);
>try {
>installArtifact(mavenSession.getProjectBuildingRequest(),
> artifacts);
>} catch (MojoExecutionException e) {
>getLog().error("Failed to install FM Descriptor", e);
>}
>} else {
>getLog().error("Could not find FM Descriptor File: " + file);
>}
> }
>
> private void installArtifact(ProjectBuildingRequest pbr,
> Collection artifacts )
>throws MojoExecutionException {
>try {
>installer.install(pbr, artifacts);
>} catch ( ArtifactInstallerException e ) {
>throw new MojoExecutionException( "ArtifactInstallerException", e );
>}
> }
>
> Cheers - Andy Schaefer
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
Installing a File into Local Repository
Hi
I want to install a file into my local repository. The code below did work at
one time but now it is creating the file in the local repository but that file
is empty. Any idea on how to fix it or is there another way to do that?
Current Maven version:
mvn --version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /Java/maven3
Java version: 1.8.0_201, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: “mac"
Requirements:
This code is installing a generated file (JSon file) into the local repository
with the extension ’slingosgifeature’. The packaging is ‘jar’ as this project
creates a JAR file. That said it needs also to install that file into the local
repository.
Code:
private void installFMDescriptor(File file, Feature feature) {
Collection artifacts =
Collections.synchronizedCollection(new ArrayList<>());
if(file.exists() && file.canRead()) {
getLog().debug("FM File to be installed: " + file.getAbsolutePath());
// Need to create a new Artifact Handler for the different extension
and an Artifact to not
// change the module artifact
DefaultArtifactHandler fmArtifactHandler = new
DefaultArtifactHandler("slingosgifeature");
ArtifactId artifactId = feature.getId();
DefaultArtifact fmArtifact = new DefaultArtifact(
artifactId.getGroupId(), artifactId.getArtifactId(),
artifactId.getVersion(),
null, "slingosgifeature", null, fmArtifactHandler
);
fmArtifact.setFile(file);
artifacts.add(fmArtifact);
try {
installArtifact(mavenSession.getProjectBuildingRequest(),
artifacts);
} catch (MojoExecutionException e) {
getLog().error("Failed to install FM Descriptor", e);
}
} else {
getLog().error("Could not find FM Descriptor File: " + file);
}
}
private void installArtifact(ProjectBuildingRequest pbr,
Collection artifacts )
throws MojoExecutionException {
try {
installer.install(pbr, artifacts);
} catch ( ArtifactInstallerException e ) {
throw new MojoExecutionException( "ArtifactInstallerException", e );
}
}
Cheers - Andy Schaefer
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn dependency:purge-local-repository
Looks like you gave mvn as a goal In eclipse there should be a run as maven menu Jeff Le ven. 15 juin 2018 17:45, Karen Goh a écrit : > Hi, > > I run into a problem in my Spring Boot Web project and then there's an > advice following this URL : > > https://github.com/spring-projects/spring-boot/issues/12398 > > But, when I run mvn dependency:purge-local-repository, I get another error > : > > Unknown lifecycle phase "mvn". You must specify a valid lifecycle phase or > a goal in the format : or > :[:]:. Available > lifecycle phases are: validate, initialize, generate-sources, > process-sources, generate-resources, process-resources, compile, > process-classes, generate-test-sources, process-test-sources, > generate-test-resources, process-test-resources, test-compile, > process-test-classes, test, prepare-package, package, pre-integration-test, > integration-test, post-integration-test, verify, install, deploy, > pre-clean, clean, post-clean, pre-site, site, post-site, site-deploy. -> > [Help] > > I hope someone can tell you how to run mvn > dependency:purge-local-repository in Eclipse Oxygen. > > Tks > > Karen > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: mvn dependency:purge-local-repository
On Fri, Jun 15, 2018 at 5:45 PM Karen Goh wrote: > Hi, > > I run into a problem in my Spring Boot Web project and then there's an > advice following this URL : > > https://github.com/spring-projects/spring-boot/issues/12398 > > But, when I run mvn dependency:purge-local-repository, I get another error > : > > Unknown lifecycle phase "mvn". You must specify a valid lifecycle phase or > a goal in the format : or > :[:]:. Available > lifecycle phases are: validate, initialize, generate-sources, > process-sources, generate-resources, process-resources, compile, > process-classes, generate-test-sources, process-test-sources, > generate-test-resources, process-test-resources, test-compile, > process-test-classes, test, prepare-package, package, pre-integration-test, > integration-test, post-integration-test, verify, install, deploy, > pre-clean, clean, post-clean, pre-site, site, post-site, site-deploy. -> > [Help] > > I hope someone can tell you how to run mvn > dependency:purge-local-repository in Eclipse Oxygen. > "mvn" is the command-line tool for running Maven. When running Maven from within Eclipse, you only specify the arguments through the dialog box. In "target" (iiuc, haven't used Eclipse for years), you'd then put only "dependency:purge-local-repository". HTH
mvn dependency:purge-local-repository
Hi, I run into a problem in my Spring Boot Web project and then there's an advice following this URL : https://github.com/spring-projects/spring-boot/issues/12398 But, when I run mvn dependency:purge-local-repository, I get another error : Unknown lifecycle phase "mvn". You must specify a valid lifecycle phase or a goal in the format : or :[:]:. Available lifecycle phases are: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy, pre-clean, clean, post-clean, pre-site, site, post-site, site-deploy. -> [Help] I hope someone can tell you how to run mvn dependency:purge-local-repository in Eclipse Oxygen. Tks Karen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Question regarding Maven's local repository use
Anders, I am researching my project/repository against your explanation. I will follow up with a real answer once complete. Thanks for your response. On Mon, Feb 5, 2018 at 3:25 PM, Anders Hammar <and...@hammar.net> wrote: > I'd like to stress that my explanations are from what I recall. I could be > wrong. > > If my memory serves me right and this is how it works, I believe it was > just to prevent the scenario you're describing (switching between different > repos) from causing the wrong result. The idea was then that if you change > your repo/mirror config, your intention is to use the current declared > repo(s)/mirror(s). So anything from some other repo(s) shouldn't be used. > However, using the repo/mirror id is probably not the best solution; using > the url would probably be better. > > So, in your scenario, you typically work with a corporate proxy/mirror > (like Nexus) that only gives you access to procured artifacts. Then you > want to use/test some artifact that the mirror don't allow, so you work > directly towards central. Then you switch back to your procured mirror and > Maven now prevents you from using the artifact that doesn't exist in the > procured mirror. > I'd say everything works as intended then. Maven stops you from using an > artifact that you shouldn't be using according to your configuration. If > you would like to use that artifact, you should be working towards central > directly or your mirror should provide it. > Do you see my point? > > /Anders > > On Mon, Feb 5, 2018 at 10:06 PM, Paul Benedict <pbened...@apache.org> > wrote: > > > Anders, I have a question for your clarification. I think you're saying > > that because some repositories aren't in best condition, this is a way to > > make sure the intended artifact of the intended repository is downloaded? > > Okay. If that's the case, that sounds like a really weird edge case that > > shouldn't figure into normal use. If I ever encountered such a problem, a > > developer should rely on dependency:purge-local-repository to trash the > > bad > > download. > > > > So is there any room for a Maven enhancement here? I am still not > convinced > > the current behavior is sensible as a default. I really want to allow my > > repositories, with local artifacts pre-cached in my local repository, to > go > > offline without causing a build panic. What are anyone's thoughts on here > > about how Maven could adopt behavior like I want? I could probably write > a > > patch but I'd like a "meeting of the minds" to turn this idea from good > to > > better. > > > > On Mon, Feb 5, 2018 at 12:56 PM, Anders Hammar <and...@hammar.net> > wrote: > > > > > IIRC this change was introduced as an artifact sometimes differ between > > > repositories. They shouldn't do, but some repos aren't handled > correctly. > > > So if the repo id changes compared to the one stored for a locally > cached > > > artifact, Maven tries to download it again. > > > > > > /Anders > > > > > > On Mon, Feb 5, 2018 at 5:04 PM, Paul Benedict <pbened...@apache.org> > > > wrote: > > > > > > > I think you're right. However, I am still curious why Maven is acting > > > like > > > > it does -- in terms of requirements. Maven already has the artifact > > > > locally. There's not a reason (and never a reason?) for it to ever be > > > > retrieved again, right? > > > > > > > > On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net> > > wrote: > > > > > > > > > What I think you're running into is that Maven keeps track of from > > > which > > > > > repo an artifact in the local repo was downloaded from. When you > > > > > remove/restore the mirror config the repo id most likely changes > > which > > > > > causes Maven to try to download again. > > > > > There should be a filed named _remote.repositories next to every > > > artifact > > > > > in the loca lrepo where you can find this info. > > > > > > > > > > IIRC this was a change between Maven 2 and Maven 3, or a change > that > > > > > happened very early in the life of Maven 3. Before that Maven > didn't > > > keep > > > > > track of from where an artifact was downloaded. > > > > > > > > > > /Anders > > > > > > > > > > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict < > pbened...@apache.org> > > > > > wrote
Re: Question regarding Maven's local repository use
I'd like to stress that my explanations are from what I recall. I could be wrong. If my memory serves me right and this is how it works, I believe it was just to prevent the scenario you're describing (switching between different repos) from causing the wrong result. The idea was then that if you change your repo/mirror config, your intention is to use the current declared repo(s)/mirror(s). So anything from some other repo(s) shouldn't be used. However, using the repo/mirror id is probably not the best solution; using the url would probably be better. So, in your scenario, you typically work with a corporate proxy/mirror (like Nexus) that only gives you access to procured artifacts. Then you want to use/test some artifact that the mirror don't allow, so you work directly towards central. Then you switch back to your procured mirror and Maven now prevents you from using the artifact that doesn't exist in the procured mirror. I'd say everything works as intended then. Maven stops you from using an artifact that you shouldn't be using according to your configuration. If you would like to use that artifact, you should be working towards central directly or your mirror should provide it. Do you see my point? /Anders On Mon, Feb 5, 2018 at 10:06 PM, Paul Benedict <pbened...@apache.org> wrote: > Anders, I have a question for your clarification. I think you're saying > that because some repositories aren't in best condition, this is a way to > make sure the intended artifact of the intended repository is downloaded? > Okay. If that's the case, that sounds like a really weird edge case that > shouldn't figure into normal use. If I ever encountered such a problem, a > developer should rely on dependency:purge-local-repository to trash the > bad > download. > > So is there any room for a Maven enhancement here? I am still not convinced > the current behavior is sensible as a default. I really want to allow my > repositories, with local artifacts pre-cached in my local repository, to go > offline without causing a build panic. What are anyone's thoughts on here > about how Maven could adopt behavior like I want? I could probably write a > patch but I'd like a "meeting of the minds" to turn this idea from good to > better. > > On Mon, Feb 5, 2018 at 12:56 PM, Anders Hammar <and...@hammar.net> wrote: > > > IIRC this change was introduced as an artifact sometimes differ between > > repositories. They shouldn't do, but some repos aren't handled correctly. > > So if the repo id changes compared to the one stored for a locally cached > > artifact, Maven tries to download it again. > > > > /Anders > > > > On Mon, Feb 5, 2018 at 5:04 PM, Paul Benedict <pbened...@apache.org> > > wrote: > > > > > I think you're right. However, I am still curious why Maven is acting > > like > > > it does -- in terms of requirements. Maven already has the artifact > > > locally. There's not a reason (and never a reason?) for it to ever be > > > retrieved again, right? > > > > > > On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net> > wrote: > > > > > > > What I think you're running into is that Maven keeps track of from > > which > > > > repo an artifact in the local repo was downloaded from. When you > > > > remove/restore the mirror config the repo id most likely changes > which > > > > causes Maven to try to download again. > > > > There should be a filed named _remote.repositories next to every > > artifact > > > > in the loca lrepo where you can find this info. > > > > > > > > IIRC this was a change between Maven 2 and Maven 3, or a change that > > > > happened very early in the life of Maven 3. Before that Maven didn't > > keep > > > > track of from where an artifact was downloaded. > > > > > > > > /Anders > > > > > > > > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict <pbened...@apache.org> > > > > wrote: > > > > > > > > > My Maven version is 3.3.9. For my typical use case, my settings.xml > > > has a > > > > > of "central" that provides a procured subset of artifacts. > > It > > > > > contains nearly everything I might need to do a desktop build. > > However, > > > > > sometimes I need to connect to the real "central" directly to try > and > > > > test > > > > > an experimental artifact; therefore I temporarily wipe out my > > , > > > > let > > > > > Maven resolve the artifact and place it in my local repository, > and I
Re: Question regarding Maven's local repository use
Anders, I have a question for your clarification. I think you're saying that because some repositories aren't in best condition, this is a way to make sure the intended artifact of the intended repository is downloaded? Okay. If that's the case, that sounds like a really weird edge case that shouldn't figure into normal use. If I ever encountered such a problem, a developer should rely on dependency:purge-local-repository to trash the bad download. So is there any room for a Maven enhancement here? I am still not convinced the current behavior is sensible as a default. I really want to allow my repositories, with local artifacts pre-cached in my local repository, to go offline without causing a build panic. What are anyone's thoughts on here about how Maven could adopt behavior like I want? I could probably write a patch but I'd like a "meeting of the minds" to turn this idea from good to better. On Mon, Feb 5, 2018 at 12:56 PM, Anders Hammar <and...@hammar.net> wrote: > IIRC this change was introduced as an artifact sometimes differ between > repositories. They shouldn't do, but some repos aren't handled correctly. > So if the repo id changes compared to the one stored for a locally cached > artifact, Maven tries to download it again. > > /Anders > > On Mon, Feb 5, 2018 at 5:04 PM, Paul Benedict <pbened...@apache.org> > wrote: > > > I think you're right. However, I am still curious why Maven is acting > like > > it does -- in terms of requirements. Maven already has the artifact > > locally. There's not a reason (and never a reason?) for it to ever be > > retrieved again, right? > > > > On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net> wrote: > > > > > What I think you're running into is that Maven keeps track of from > which > > > repo an artifact in the local repo was downloaded from. When you > > > remove/restore the mirror config the repo id most likely changes which > > > causes Maven to try to download again. > > > There should be a filed named _remote.repositories next to every > artifact > > > in the loca lrepo where you can find this info. > > > > > > IIRC this was a change between Maven 2 and Maven 3, or a change that > > > happened very early in the life of Maven 3. Before that Maven didn't > keep > > > track of from where an artifact was downloaded. > > > > > > /Anders > > > > > > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict <pbened...@apache.org> > > > wrote: > > > > > > > My Maven version is 3.3.9. For my typical use case, my settings.xml > > has a > > > > of "central" that provides a procured subset of artifacts. > It > > > > contains nearly everything I might need to do a desktop build. > However, > > > > sometimes I need to connect to the real "central" directly to try and > > > test > > > > an experimental artifact; therefore I temporarily wipe out my > , > > > let > > > > Maven resolve the artifact and place it in my local repository, and I > > can > > > > test accordingly. > > > > > > > > Now this is where my trouble begins. After restoring my , > Maven > > > > complains: "Failure to find xxx:yyy:1.0.0 was cached in local > > > > repository, resolution will not be reattempted until...". > > > > > > > > This is very confusing to me. The artifact version is NOT a snapshot. > > > Yes, > > > > I am online, but why does Maven need to verify the artifact in the > > remote > > > > repository given it already resides in my local repository? Since > > > > non-snapshots can never be re-updated, I don't see a need for Maven > to > > > make > > > > a remote connection. It seems unnecessary. > > > > > > > > Perhaps I am misunderstanding a requirement of Maven. I was really > > > hoping I > > > > could be disconnected from the artifact's remote repository, but > > > evidently > > > > not. Why is Maven acting this way? > > > > > > > > Thank you! > > > > > > > > Cheers, > > > > Paul > > > > > > > > > > > > > > > -- > > Cheers, > > Paul > > > -- Cheers, Paul
Re: Question regarding Maven's local repository use
IIRC this change was introduced as an artifact sometimes differ between repositories. They shouldn't do, but some repos aren't handled correctly. So if the repo id changes compared to the one stored for a locally cached artifact, Maven tries to download it again. /Anders On Mon, Feb 5, 2018 at 5:04 PM, Paul Benedict <pbened...@apache.org> wrote: > I think you're right. However, I am still curious why Maven is acting like > it does -- in terms of requirements. Maven already has the artifact > locally. There's not a reason (and never a reason?) for it to ever be > retrieved again, right? > > On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net> wrote: > > > What I think you're running into is that Maven keeps track of from which > > repo an artifact in the local repo was downloaded from. When you > > remove/restore the mirror config the repo id most likely changes which > > causes Maven to try to download again. > > There should be a filed named _remote.repositories next to every artifact > > in the loca lrepo where you can find this info. > > > > IIRC this was a change between Maven 2 and Maven 3, or a change that > > happened very early in the life of Maven 3. Before that Maven didn't keep > > track of from where an artifact was downloaded. > > > > /Anders > > > > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict <pbened...@apache.org> > > wrote: > > > > > My Maven version is 3.3.9. For my typical use case, my settings.xml > has a > > > of "central" that provides a procured subset of artifacts. It > > > contains nearly everything I might need to do a desktop build. However, > > > sometimes I need to connect to the real "central" directly to try and > > test > > > an experimental artifact; therefore I temporarily wipe out my , > > let > > > Maven resolve the artifact and place it in my local repository, and I > can > > > test accordingly. > > > > > > Now this is where my trouble begins. After restoring my , Maven > > > complains: "Failure to find xxx:yyy:1.0.0 was cached in local > > > repository, resolution will not be reattempted until...". > > > > > > This is very confusing to me. The artifact version is NOT a snapshot. > > Yes, > > > I am online, but why does Maven need to verify the artifact in the > remote > > > repository given it already resides in my local repository? Since > > > non-snapshots can never be re-updated, I don't see a need for Maven to > > make > > > a remote connection. It seems unnecessary. > > > > > > Perhaps I am misunderstanding a requirement of Maven. I was really > > hoping I > > > could be disconnected from the artifact's remote repository, but > > evidently > > > not. Why is Maven acting this way? > > > > > > Thank you! > > > > > > Cheers, > > > Paul > > > > > > > > > -- > Cheers, > Paul >
Re: Question regarding Maven's local repository use
The issue here is that the build always runs in a brand new container so at the start no artifacts are available locally. All the artifacts that are fetched by the dependency:go-offline task will be cached in a Docker image layer and reused in later builds if the pom.xml doesn’t change. This would be great if the dependency:go-offline task actually downloaded all the dependencies. Because it doesn’t do so every time you change your code a lot of dependencies will get downloaded, even if not all. On Mon, Feb 5, 2018 at 5:05 PM Paul Benedict <pbened...@apache.org> wrote: > I think you're right. However, I am still curious why Maven is acting like > it does -- in terms of requirements. Maven already has the artifact > locally. There's not a reason (and never a reason?) for it to ever be > retrieved again, right? > > On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net> wrote: > > > What I think you're running into is that Maven keeps track of from which > > repo an artifact in the local repo was downloaded from. When you > > remove/restore the mirror config the repo id most likely changes which > > causes Maven to try to download again. > > There should be a filed named _remote.repositories next to every artifact > > in the loca lrepo where you can find this info. > > > > IIRC this was a change between Maven 2 and Maven 3, or a change that > > happened very early in the life of Maven 3. Before that Maven didn't keep > > track of from where an artifact was downloaded. > > > > /Anders > > > > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict <pbened...@apache.org> > > wrote: > > > > > My Maven version is 3.3.9. For my typical use case, my settings.xml > has a > > > of "central" that provides a procured subset of artifacts. It > > > contains nearly everything I might need to do a desktop build. However, > > > sometimes I need to connect to the real "central" directly to try and > > test > > > an experimental artifact; therefore I temporarily wipe out my , > > let > > > Maven resolve the artifact and place it in my local repository, and I > can > > > test accordingly. > > > > > > Now this is where my trouble begins. After restoring my , Maven > > > complains: "Failure to find xxx:yyy:1.0.0 was cached in local > > > repository, resolution will not be reattempted until...". > > > > > > This is very confusing to me. The artifact version is NOT a snapshot. > > Yes, > > > I am online, but why does Maven need to verify the artifact in the > remote > > > repository given it already resides in my local repository? Since > > > non-snapshots can never be re-updated, I don't see a need for Maven to > > make > > > a remote connection. It seems unnecessary. > > > > > > Perhaps I am misunderstanding a requirement of Maven. I was really > > hoping I > > > could be disconnected from the artifact's remote repository, but > > evidently > > > not. Why is Maven acting this way? > > > > > > Thank you! > > > > > > Cheers, > > > Paul > > > > > > > > > -- > Cheers, > Paul > -- Ádám Sándor Senior Engineer / Consultant Container Solutions <http://container-solutions.com/> 0680126174 <https://twitter.com/adamsand0r> <https://www.linkedin.com/in/adamsandor/>
Re: Question regarding Maven's local repository use
I think you're right. However, I am still curious why Maven is acting like it does -- in terms of requirements. Maven already has the artifact locally. There's not a reason (and never a reason?) for it to ever be retrieved again, right? On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net> wrote: > What I think you're running into is that Maven keeps track of from which > repo an artifact in the local repo was downloaded from. When you > remove/restore the mirror config the repo id most likely changes which > causes Maven to try to download again. > There should be a filed named _remote.repositories next to every artifact > in the loca lrepo where you can find this info. > > IIRC this was a change between Maven 2 and Maven 3, or a change that > happened very early in the life of Maven 3. Before that Maven didn't keep > track of from where an artifact was downloaded. > > /Anders > > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict <pbened...@apache.org> > wrote: > > > My Maven version is 3.3.9. For my typical use case, my settings.xml has a > > of "central" that provides a procured subset of artifacts. It > > contains nearly everything I might need to do a desktop build. However, > > sometimes I need to connect to the real "central" directly to try and > test > > an experimental artifact; therefore I temporarily wipe out my , > let > > Maven resolve the artifact and place it in my local repository, and I can > > test accordingly. > > > > Now this is where my trouble begins. After restoring my , Maven > > complains: "Failure to find xxx:yyy:1.0.0 was cached in local > > repository, resolution will not be reattempted until...". > > > > This is very confusing to me. The artifact version is NOT a snapshot. > Yes, > > I am online, but why does Maven need to verify the artifact in the remote > > repository given it already resides in my local repository? Since > > non-snapshots can never be re-updated, I don't see a need for Maven to > make > > a remote connection. It seems unnecessary. > > > > Perhaps I am misunderstanding a requirement of Maven. I was really > hoping I > > could be disconnected from the artifact's remote repository, but > evidently > > not. Why is Maven acting this way? > > > > Thank you! > > > > Cheers, > > Paul > > > -- Cheers, Paul
Re: Question regarding Maven's local repository use
What I think you're running into is that Maven keeps track of from which repo an artifact in the local repo was downloaded from. When you remove/restore the mirror config the repo id most likely changes which causes Maven to try to download again. There should be a filed named _remote.repositories next to every artifact in the loca lrepo where you can find this info. IIRC this was a change between Maven 2 and Maven 3, or a change that happened very early in the life of Maven 3. Before that Maven didn't keep track of from where an artifact was downloaded. /Anders On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict <pbened...@apache.org> wrote: > My Maven version is 3.3.9. For my typical use case, my settings.xml has a > of "central" that provides a procured subset of artifacts. It > contains nearly everything I might need to do a desktop build. However, > sometimes I need to connect to the real "central" directly to try and test > an experimental artifact; therefore I temporarily wipe out my , let > Maven resolve the artifact and place it in my local repository, and I can > test accordingly. > > Now this is where my trouble begins. After restoring my , Maven > complains: "Failure to find xxx:yyy:1.0.0 was cached in local > repository, resolution will not be reattempted until...". > > This is very confusing to me. The artifact version is NOT a snapshot. Yes, > I am online, but why does Maven need to verify the artifact in the remote > repository given it already resides in my local repository? Since > non-snapshots can never be re-updated, I don't see a need for Maven to make > a remote connection. It seems unnecessary. > > Perhaps I am misunderstanding a requirement of Maven. I was really hoping I > could be disconnected from the artifact's remote repository, but evidently > not. Why is Maven acting this way? > > Thank you! > > Cheers, > Paul >
Question regarding Maven's local repository use
My Maven version is 3.3.9. For my typical use case, my settings.xml has a of "central" that provides a procured subset of artifacts. It contains nearly everything I might need to do a desktop build. However, sometimes I need to connect to the real "central" directly to try and test an experimental artifact; therefore I temporarily wipe out my , let Maven resolve the artifact and place it in my local repository, and I can test accordingly. Now this is where my trouble begins. After restoring my , Maven complains: "Failure to find xxx:yyy:1.0.0 was cached in local repository, resolution will not be reattempted until...". This is very confusing to me. The artifact version is NOT a snapshot. Yes, I am online, but why does Maven need to verify the artifact in the remote repository given it already resides in my local repository? Since non-snapshots can never be re-updated, I don't see a need for Maven to make a remote connection. It seems unnecessary. Perhaps I am misunderstanding a requirement of Maven. I was really hoping I could be disconnected from the artifact's remote repository, but evidently not. Why is Maven acting this way? Thank you! Cheers, Paul
mvn dependency:purge-local-repository fails to resolve, but subsequent mvn dependency:go-offline succeeds
Using Maven since 10+ years, we have a strange problem with MVN 3.5.0. What we want to achieve is to ensure that all dependencies are latest version, even if somebody did a bad thing and replaced a release version in Nexus. So we type: mvn dependency:purge-local-repository This fails to re-resolve some of the artifacts in our POM (but not specific artifacts; always different ones!). But when we then (yes, directly subsequent) type: mvn dependency:go-offline it perfectly re-resolves and downloads everything -yes, even the failing ones- from Nexus. This is driving us nuts! Is that a bug or are we completely misunderstanding the concept of these commands? -Markus
Re: deployment to local repository
Hi, Am 25.05.2016 um 23:26 schrieb Adrien Rivard <adrien.riv...@gmail.com>: > Hello, > > On Wed, May 25, 2016 at 10:14 PM, Philipp Kraus < > philipp.kr...@tu-clausthal.de> wrote: > >> Hello, >> >> I’m working on my first Maven framework, I would like to test the >> framework in another project, >> so I build a jar file with „mvn package", and then I install the jar into >> my local repository with „mvn install:install-file -Dfile=myjar.jar“. >> >> > When you have the project source, you should do "mvn install" and not "mvn > install:install-file -Dx", it will take the right > parameters(groupId/artifactid/version ...) from the project pom. thanks that was my mistake. I have got the sources and I run „mvn package“, not „mvn install“. With install everything works fine Phil
Re: deployment to local repository
Hello, On Wed, May 25, 2016 at 10:14 PM, Philipp Kraus < philipp.kr...@tu-clausthal.de> wrote: > Hello, > > I’m working on my first Maven framework, I would like to test the > framework in another project, > so I build a jar file with „mvn package", and then I install the jar into > my local repository with „mvn install:install-file -Dfile=myjar.jar“. > > When you have the project source, you should do "mvn install" and not "mvn install:install-file -Dx", it will take the right parameters(groupId/artifactid/version ...) from the project pom. > I can use the package in another project with a dependency entry, but my > framework has got different dependencies e.g. to AntLR, Guava > or Apache Commons, but in my project the dependencies are not found. > > The pom of the framework is defined with: > > mygroup > framework > 0.1-SNAPSHOT > jar > > and the project has got > > > mygroup > framework > 0.1-SNAPSHOT > compile > > > I am not sure to understand, do you have a problem with the framework dependency (those pom snippets look good), or with AntLR, Guava dependencies ? in that case did you/how did you declared them? > IMHO I create a incomplete pom.xml on my framework, but I don’t know how I > can create it with the correct > way, so I can deploy the framework to my local repository only for > testing-case. Two other test projects should > use this deployed framework. > > Can you help me to create a correct pom.xml? > > Additional note, if those projects are used to test the framework, they probably should be in the same multiproject. > Thanks for help > > Phil > -- Adrien Rivard
Re: deployment to local repository
Do not use install-file and package like that. Just run mvn install that will package the jar and install the jar and pom into the local repo. That way the dependency info in the pom will not get lost. manfred Philipp Kraus wrote on 2016-05-25 13:14: > Hello, > > I’m working on my first Maven framework, I would like to test the framework > in another project, > so I build a jar file with „mvn package", and then I install the jar into my > local repository with „mvn install:install-file -Dfile=myjar.jar“. > > I can use the package in another project with a dependency entry, but my > framework has got different dependencies e.g. to AntLR, Guava > or Apache Commons, but in my project the dependencies are not found. > > The pom of the framework is defined with: > > mygroup > framework > 0.1-SNAPSHOT > jar > > and the project has got > > >mygroup >framework >0.1-SNAPSHOT >compile > > > IMHO I create a incomplete pom.xml on my framework, but I don’t know how I > can create it with the correct > way, so I can deploy the framework to my local repository only for > testing-case. Two other test projects should > use this deployed framework. > > Can you help me to create a correct pom.xml? > > Thanks for help > > Phil > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
deployment to local repository
Hello, I’m working on my first Maven framework, I would like to test the framework in another project, so I build a jar file with „mvn package", and then I install the jar into my local repository with „mvn install:install-file -Dfile=myjar.jar“. I can use the package in another project with a dependency entry, but my framework has got different dependencies e.g. to AntLR, Guava or Apache Commons, but in my project the dependencies are not found. The pom of the framework is defined with: mygroup framework 0.1-SNAPSHOT jar and the project has got mygroup framework 0.1-SNAPSHOT compile IMHO I create a incomplete pom.xml on my framework, but I don’t know how I can create it with the correct way, so I can deploy the framework to my local repository only for testing-case. Two other test projects should use this deployed framework. Can you help me to create a correct pom.xml? Thanks for help Phil signature.asc Description: Message signed with OpenPGP using GPGMail
Local Repository Question
Can the local repository be a Nexus repository on a server? If so How? Thanks Michael Tarullo Contractor (Engility Corp) Enterprise Architect NSRR System Administrator FAA WJH Technical Center (609)485-5294
Re: Local Repository Question
michael.ctr.taru...@faa.gov wrote: > Can the local repository be a Nexus repository on a server? If so How? No. Think of the local repo as cache. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Creating local repository
Hi, You don't share the "local repository", it should be seen and actually have been called "cache". Search for tools called "Maven Repository Manager". The famous ones out there are Archiva, Artifactory & Nexus (in alphabetical order). Cheers 2015-09-05 5:07 GMT+02:00 Niraj Chaudhary <niraj.m.chaudh...@gmail.com>: > Hi George, > > We had tried this earlier in my company. > The problem is you never know what is 'all' the artifacts. > Challenges faced: > > 1.One developer adding a new third-party dependency required that the > artifact should be present in all the local dev repos for proper > compilation. > 2.Repo grows in size. Sharing becomes difficult. > > Thanks, > Niraj > > On Fri, Sep 4, 2015 at 8:51 PM, George Karabotsos <kara...@gmail.com> > wrote: > > > Hi Gail, > > > > The problem is that the VM is not controlled by my organization--they > > are controlled by a third party. As such, they are not even within our > > intranet. > > > > I do have access to the master VM which has access to the internet to > > allow me to set it up. So what you and Michael mention, to get all > > artifacts first, then use the -o flag from offilne VMs, should do the > > trick. > > > > Thank you so much! > > > > Cheers, > > George > > > > On Fri, Sep 4, 2015, at 10:54 AM, Gail Stewart wrote: > > > How are you going to get the libraries you need to this server if you > > > have > > > no net access? > > > > > > I'm not sure if this would work, but one way might be to run the maven > on > > > a > > > system with internet access so it populates the local repository in > > > $HOME/.m2 > > > > > > Tar or zip that directory up and get it to your server. Unzip it into > > > your > > > $HOME/.m2 or to a common location for several developers to use. You > can > > > tell maven where to find the local repo if you aren't using the default > > > $HOME/.m2 location. > > > > > > Then run maven in offline mode. > > > > > > This is not ideal - why doesn't the server have internet access? Could > > > it > > > have access to a company managed server? If so you could setup a nexus > > > or > > > artifactory enterprise server - that would have internet access, but > > > could > > > be controlled in a secure manner. > > > > > > > > > On Fri, Sep 4, 2015 at 10:27 AM, George Karabotsos <kara...@gmail.com> > > > wrote: > > > > > > > Hello all, > > > > > > > > Let me start by admitting I am by no means a maven expert :). > > > > > > > > Now I have a need to create a local file-based repository to be used > by > > > > maven when building my project. I need this because I have no net > > > > access from a set of VMs I and colleagues have to use . > > > > > > > > I was thinking of the following: > > > > 1) connected to the net, normally proceed and download all necessary > > > > artifacts > > > > 2) copy these jars with > > > > > cp -r Users/gkarabotsos/.m2/repository . > > > > 3) Add the following to my pom.xml > > > > > > > > > > > > localrepository > > > > file:///c:/repository/ > > > > > > > > > > > > > > > > I do know that it does not work--I am guessing my c:/repository > > > > structure does not have the correct form. > > > > > > > > I have also seen, in the net, commands such as the following: > > > > > > > > mvn install:install-file -Dfile=YOUR_JAR.jar -DgroupId=YOUR_GROUP_ID > > > > -DartifactId=YOUR_ARTIFACT_ID -Dversion=YOUR_VERSION -Dpackaging=jar > > > > -DlocalRepositoryPath=/var/www/html/mavenRepository > > > > > > > > Is this the only correct way? I have yet to try it, primarily > because I > > > > have a few dozen artifacts and doing so will take me a long time. > > > > > > > > > > > > Cheers, > > > > George > > > > > > > > - > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > > > > > > > > -- > > > > > > Gail Stewart > > > Sr. Release Engineer > > > > > > AP & Payment Automation > > > 125 Cambridgepark Drive > > > Cambridge, MA 02140 > > > gail.stew...@mineraltree.com > > > 617.299.3399 x148 > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Using dependency plugin to build minimal local repository to run unit tests
Hi all, thanks for prompt replies! A common theme I'm hearing is to point to a clean repository and then do the build. The thing is, there are additional dependencies that are only pulled down when tests are actually run. Even doing `mvn test -DskipTests` still left me missing a surefire-junit4 dependency. I can hack around that by making my users specify these additional "test runtime" dependencies, but that's kind of unfortunate. Is this usecase supposed to be handled by the dependency plugin? It seems like what copy-dependencies and go-offline are intended for, and they even mention test scope, but after running them I'm still left missing many dependencies. I also already have all the deps in ~/.m2/repository, so it'd be really great to copy from there (or better, hardlink) rather than re-download from the internet. I could work on some of this if it sounds reasonable. Basically, a copy-dependency mode that also pulls in everything pulled by go-offline, and hardlinks to ~/.m2/repository rather than copying. Thanks, Andrew On Thu, Sep 10, 2015 at 4:35 PM, Laird Nelson <ljnel...@gmail.com> wrote: > Hello; you might also want to look at > > https://maven.apache.org/plugins/maven-dependency-plugin/go-offline-mojo.html > . > > Best, > Laird > -- > http://about.me/lairdnelson > > On Thu, Sep 10, 2015 at 4:29 PM Mark Eggers <its_toas...@yahoo.com.invalid > > > wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Andrew, > > > > I don't know if this would help: > > > > 1. Set up a repository on your local machine > > 2. Configure that repository to proxy remote repositories > > 3. Set your settings.xml to point to that local repository > > 4. Build normally > > > > Then when you're off-line, you're not really off-line. Provided that > > your local repository has pulled down all the dependencies, builds > > should work as expected. > > > > The downside of this is that it's a bit piggish on disk space. > > > > I'm also not sure how to bounce back and forth between various > > repositories, ie; > > > > 1. Connected to $work - you'll want to pull everything from that > >repository into your local repository > > 2. Connected to notwork - you'll probably want to use Central through > >your local repository > > > > Almost sounds like you would need two different environments ($work > > and notwork). This is probably best in any case. > > > > . . . just my two cents > > /mde/ > > > > On 9/10/2015 4:16 PM, Andrew Wang wrote: > > > Hi Maven experts, > > > > > > I'm trying to get a minimal set of local repository contents to be > > > able to run unit tests for a project in offline mode. The > > > dependency plugin documentation indicates that by default it's test > > > scope, which is just what I want, so I did something like this > > > (Maven 3.0.4): > > > > > > # Copy what I can from my existing local repository to my temp > > > repo mvn dependency:copy-dependencies > > > -Dmdep.useRepositoryLayout=true -DoutputDirectory=/tmp/hadoop-deps > > > -Dmdep.copyPom # Download things missed by copy:dependencies mvn > > > dependency:go-offline -Dmaven.repo.local=/tmp/hadoop-deps # Try > > > running offline unit test mvn -o surefire:test -Dtest=TestFoo > > > -Dmaven.repo.local=/tmp/hadoop-deps > > > > > > This was still missing some dependencies, so I ran this which > > > downloaded some more: > > > > > > mvn surefire:test -DskipTests -Dmaven.repo.local=/tmp/hadoop-deps > > > > > > Invoking offline maven to run TestFoo still failed though, this > > > time missing Surefire. After doing dependency:get on that, my > > > offline test finally worked. > > > > > > Is this expected behavior? I expected dependency:go-offline to be > > > sufficient for this purpose. I'm was also very surprised that > > > running `mvn surefire:test -DskipTests` did not download all the > > > required dependencies. > > > > > > If you have ideas on how better to do this, I'm also all ears :) > > > This is related to some distributed testing experiments I'm doing > > > for Apache Hadoop and HBase, which will hopefully be put into > > > broader use upstream at some point. > > > > > > Thanks, Andrew > > > > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v2 > > > > iQEcBAEBAgAGBQJV8hJDAAoJEEFGbsYNeTwtRlwH/2Yh7Xz5PwKDX+fBVhT+WAaK > > dihjGnwfs0pIXrwa2jh3Vnw2t79CR5FiJf2f9+AGK75p8N47pJQiUpN7ioADmLuJ > > dox/CloSRl0XGNME1rhp5B+wgfafjYBE5tAY0DTVfIODYAjAKigXQvFDeAlCihHs > > HI/OMg0+Q+A9UTKDU/dcd15MnRDktmX+9iCPO+KOeEEOywYCIYclW1Pg95PEJKkA > > LaJ9WnckDhWsghAO5zj4j/+V4ByBm4RKO8mX0eQwSES7Fq4R2O0Mb6Q/mcz/Ap7v > > lvHbHbr5cGoDm6Ru7tYy8If6CkoirjUEqz+f0v0NXbY5N2s6l0rHnjz2gkydPTY= > > =NU1A > > -END PGP SIGNATURE- > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Using dependency plugin to build minimal local repository to run unit tests
Hi Maven experts, I'm trying to get a minimal set of local repository contents to be able to run unit tests for a project in offline mode. The dependency plugin documentation indicates that by default it's test scope, which is just what I want, so I did something like this (Maven 3.0.4): # Copy what I can from my existing local repository to my temp repo mvn dependency:copy-dependencies -Dmdep.useRepositoryLayout=true -DoutputDirectory=/tmp/hadoop-deps -Dmdep.copyPom # Download things missed by copy:dependencies mvn dependency:go-offline -Dmaven.repo.local=/tmp/hadoop-deps # Try running offline unit test mvn -o surefire:test -Dtest=TestFoo -Dmaven.repo.local=/tmp/hadoop-deps This was still missing some dependencies, so I ran this which downloaded some more: mvn surefire:test -DskipTests -Dmaven.repo.local=/tmp/hadoop-deps Invoking offline maven to run TestFoo still failed though, this time missing Surefire. After doing dependency:get on that, my offline test finally worked. Is this expected behavior? I expected dependency:go-offline to be sufficient for this purpose. I'm was also very surprised that running `mvn surefire:test -DskipTests` did not download all the required dependencies. If you have ideas on how better to do this, I'm also all ears :) This is related to some distributed testing experiments I'm doing for Apache Hadoop and HBase, which will hopefully be put into broader use upstream at some point. Thanks, Andrew
Re: Using dependency plugin to build minimal local repository to run unit tests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew, I don't know if this would help: 1. Set up a repository on your local machine 2. Configure that repository to proxy remote repositories 3. Set your settings.xml to point to that local repository 4. Build normally Then when you're off-line, you're not really off-line. Provided that your local repository has pulled down all the dependencies, builds should work as expected. The downside of this is that it's a bit piggish on disk space. I'm also not sure how to bounce back and forth between various repositories, ie; 1. Connected to $work - you'll want to pull everything from that repository into your local repository 2. Connected to notwork - you'll probably want to use Central through your local repository Almost sounds like you would need two different environments ($work and notwork). This is probably best in any case. . . . just my two cents /mde/ On 9/10/2015 4:16 PM, Andrew Wang wrote: > Hi Maven experts, > > I'm trying to get a minimal set of local repository contents to be > able to run unit tests for a project in offline mode. The > dependency plugin documentation indicates that by default it's test > scope, which is just what I want, so I did something like this > (Maven 3.0.4): > > # Copy what I can from my existing local repository to my temp > repo mvn dependency:copy-dependencies > -Dmdep.useRepositoryLayout=true -DoutputDirectory=/tmp/hadoop-deps > -Dmdep.copyPom # Download things missed by copy:dependencies mvn > dependency:go-offline -Dmaven.repo.local=/tmp/hadoop-deps # Try > running offline unit test mvn -o surefire:test -Dtest=TestFoo > -Dmaven.repo.local=/tmp/hadoop-deps > > This was still missing some dependencies, so I ran this which > downloaded some more: > > mvn surefire:test -DskipTests -Dmaven.repo.local=/tmp/hadoop-deps > > Invoking offline maven to run TestFoo still failed though, this > time missing Surefire. After doing dependency:get on that, my > offline test finally worked. > > Is this expected behavior? I expected dependency:go-offline to be > sufficient for this purpose. I'm was also very surprised that > running `mvn surefire:test -DskipTests` did not download all the > required dependencies. > > If you have ideas on how better to do this, I'm also all ears :) > This is related to some distributed testing experiments I'm doing > for Apache Hadoop and HBase, which will hopefully be put into > broader use upstream at some point. > > Thanks, Andrew > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJV8hJDAAoJEEFGbsYNeTwtRlwH/2Yh7Xz5PwKDX+fBVhT+WAaK dihjGnwfs0pIXrwa2jh3Vnw2t79CR5FiJf2f9+AGK75p8N47pJQiUpN7ioADmLuJ dox/CloSRl0XGNME1rhp5B+wgfafjYBE5tAY0DTVfIODYAjAKigXQvFDeAlCihHs HI/OMg0+Q+A9UTKDU/dcd15MnRDktmX+9iCPO+KOeEEOywYCIYclW1Pg95PEJKkA LaJ9WnckDhWsghAO5zj4j/+V4ByBm4RKO8mX0eQwSES7Fq4R2O0Mb6Q/mcz/Ap7v lvHbHbr5cGoDm6Ru7tYy8If6CkoirjUEqz+f0v0NXbY5N2s6l0rHnjz2gkydPTY= =NU1A -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using dependency plugin to build minimal local repository to run unit tests
Just run the Job you want to run with a fresh/empty local repository. > Am 11.09.2015 um 01:16 schrieb Andrew Wang <andrew.w...@cloudera.com>: > > Hi Maven experts, > > I'm trying to get a minimal set of local repository contents to be able to > run unit tests for a project in offline mode. The dependency plugin > documentation indicates that by default it's test scope, which is just what > I want, so I did something like this (Maven 3.0.4): > > # Copy what I can from my existing local repository to my temp repo > mvn dependency:copy-dependencies -Dmdep.useRepositoryLayout=true > -DoutputDirectory=/tmp/hadoop-deps -Dmdep.copyPom > # Download things missed by copy:dependencies > mvn dependency:go-offline -Dmaven.repo.local=/tmp/hadoop-deps > # Try running offline unit test > mvn -o surefire:test -Dtest=TestFoo -Dmaven.repo.local=/tmp/hadoop-deps > > This was still missing some dependencies, so I ran this which downloaded > some more: > > mvn surefire:test -DskipTests -Dmaven.repo.local=/tmp/hadoop-deps > > Invoking offline maven to run TestFoo still failed though, this time > missing Surefire. After doing dependency:get on that, my offline test > finally worked. > > Is this expected behavior? I expected dependency:go-offline to be > sufficient for this purpose. I'm was also very surprised that running `mvn > surefire:test -DskipTests` did not download all the required dependencies. > > If you have ideas on how better to do this, I'm also all ears :) This is > related to some distributed testing experiments I'm doing for Apache Hadoop > and HBase, which will hopefully be put into broader use upstream at some > point. > > Thanks, > Andrew - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using dependency plugin to build minimal local repository to run unit tests
Hello; you might also want to look at https://maven.apache.org/plugins/maven-dependency-plugin/go-offline-mojo.html . Best, Laird -- http://about.me/lairdnelson On Thu, Sep 10, 2015 at 4:29 PM Mark Eggers <its_toas...@yahoo.com.invalid> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Andrew, > > I don't know if this would help: > > 1. Set up a repository on your local machine > 2. Configure that repository to proxy remote repositories > 3. Set your settings.xml to point to that local repository > 4. Build normally > > Then when you're off-line, you're not really off-line. Provided that > your local repository has pulled down all the dependencies, builds > should work as expected. > > The downside of this is that it's a bit piggish on disk space. > > I'm also not sure how to bounce back and forth between various > repositories, ie; > > 1. Connected to $work - you'll want to pull everything from that >repository into your local repository > 2. Connected to notwork - you'll probably want to use Central through >your local repository > > Almost sounds like you would need two different environments ($work > and notwork). This is probably best in any case. > > . . . just my two cents > /mde/ > > On 9/10/2015 4:16 PM, Andrew Wang wrote: > > Hi Maven experts, > > > > I'm trying to get a minimal set of local repository contents to be > > able to run unit tests for a project in offline mode. The > > dependency plugin documentation indicates that by default it's test > > scope, which is just what I want, so I did something like this > > (Maven 3.0.4): > > > > # Copy what I can from my existing local repository to my temp > > repo mvn dependency:copy-dependencies > > -Dmdep.useRepositoryLayout=true -DoutputDirectory=/tmp/hadoop-deps > > -Dmdep.copyPom # Download things missed by copy:dependencies mvn > > dependency:go-offline -Dmaven.repo.local=/tmp/hadoop-deps # Try > > running offline unit test mvn -o surefire:test -Dtest=TestFoo > > -Dmaven.repo.local=/tmp/hadoop-deps > > > > This was still missing some dependencies, so I ran this which > > downloaded some more: > > > > mvn surefire:test -DskipTests -Dmaven.repo.local=/tmp/hadoop-deps > > > > Invoking offline maven to run TestFoo still failed though, this > > time missing Surefire. After doing dependency:get on that, my > > offline test finally worked. > > > > Is this expected behavior? I expected dependency:go-offline to be > > sufficient for this purpose. I'm was also very surprised that > > running `mvn surefire:test -DskipTests` did not download all the > > required dependencies. > > > > If you have ideas on how better to do this, I'm also all ears :) > > This is related to some distributed testing experiments I'm doing > > for Apache Hadoop and HBase, which will hopefully be put into > > broader use upstream at some point. > > > > Thanks, Andrew > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBAgAGBQJV8hJDAAoJEEFGbsYNeTwtRlwH/2Yh7Xz5PwKDX+fBVhT+WAaK > dihjGnwfs0pIXrwa2jh3Vnw2t79CR5FiJf2f9+AGK75p8N47pJQiUpN7ioADmLuJ > dox/CloSRl0XGNME1rhp5B+wgfafjYBE5tAY0DTVfIODYAjAKigXQvFDeAlCihHs > HI/OMg0+Q+A9UTKDU/dcd15MnRDktmX+9iCPO+KOeEEOywYCIYclW1Pg95PEJKkA > LaJ9WnckDhWsghAO5zj4j/+V4ByBm4RKO8mX0eQwSES7Fq4R2O0Mb6Q/mcz/Ap7v > lvHbHbr5cGoDm6Ru7tYy8If6CkoirjUEqz+f0v0NXbY5N2s6l0rHnjz2gkydPTY= > =NU1A > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Creating local repository
Hello all, Let me start by admitting I am by no means a maven expert :). Now I have a need to create a local file-based repository to be used by maven when building my project. I need this because I have no net access from a set of VMs I and colleagues have to use . I was thinking of the following: 1) connected to the net, normally proceed and download all necessary artifacts 2) copy these jars with > cp -r Users/gkarabotsos/.m2/repository . 3) Add the following to my pom.xml localrepository file:///c:/repository/ I do know that it does not work--I am guessing my c:/repository structure does not have the correct form. I have also seen, in the net, commands such as the following: mvn install:install-file -Dfile=YOUR_JAR.jar -DgroupId=YOUR_GROUP_ID -DartifactId=YOUR_ARTIFACT_ID -Dversion=YOUR_VERSION -Dpackaging=jar -DlocalRepositoryPath=/var/www/html/mavenRepository Is this the only correct way? I have yet to try it, primarily because I have a few dozen artifacts and doing so will take me a long time. Cheers, George - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Creating local repository
George, Nor am I a Maven expert, by any stretch of the imagination! But from experience, when you want to work with Maven such that is uses only the local repository you must use the -o (the offline only) option when executing your builds. I will look at your other questions because I think there are some other things you can do as alternatives. Mike Michael Tarullo Contractor (Engility Corp) Enterprise Architect NSRR System Administrator FAA WJH Technical Center (609)485-5294 -Original Message- From: George Karabotsos [mailto:kara...@gmail.com] Sent: Friday, September 04, 2015 10:27 AM To: users@maven.apache.org Subject: Creating local repository Hello all, Let me start by admitting I am by no means a maven expert :). Now I have a need to create a local file-based repository to be used by maven when building my project. I need this because I have no net access from a set of VMs I and colleagues have to use . I was thinking of the following: 1) connected to the net, normally proceed and download all necessary artifacts 2) copy these jars with > cp -r Users/gkarabotsos/.m2/repository . 3) Add the following to my pom.xml localrepository file:///c:/repository/ I do know that it does not work--I am guessing my c:/repository structure does not have the correct form. I have also seen, in the net, commands such as the following: mvn install:install-file -Dfile=YOUR_JAR.jar -DgroupId=YOUR_GROUP_ID -DartifactId=YOUR_ARTIFACT_ID -Dversion=YOUR_VERSION -Dpackaging=jar -DlocalRepositoryPath=/var/www/html/mavenRepository Is this the only correct way? I have yet to try it, primarily because I have a few dozen artifacts and doing so will take me a long time. Cheers, George - 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: Creating local repository
How are you going to get the libraries you need to this server if you have no net access? I'm not sure if this would work, but one way might be to run the maven on a system with internet access so it populates the local repository in $HOME/.m2 Tar or zip that directory up and get it to your server. Unzip it into your $HOME/.m2 or to a common location for several developers to use. You can tell maven where to find the local repo if you aren't using the default $HOME/.m2 location. Then run maven in offline mode. This is not ideal - why doesn't the server have internet access? Could it have access to a company managed server? If so you could setup a nexus or artifactory enterprise server - that would have internet access, but could be controlled in a secure manner. On Fri, Sep 4, 2015 at 10:27 AM, George Karabotsos <kara...@gmail.com> wrote: > Hello all, > > Let me start by admitting I am by no means a maven expert :). > > Now I have a need to create a local file-based repository to be used by > maven when building my project. I need this because I have no net > access from a set of VMs I and colleagues have to use . > > I was thinking of the following: > 1) connected to the net, normally proceed and download all necessary > artifacts > 2) copy these jars with > > cp -r Users/gkarabotsos/.m2/repository . > 3) Add the following to my pom.xml > > > localrepository > file:///c:/repository/ > > > > I do know that it does not work--I am guessing my c:/repository > structure does not have the correct form. > > I have also seen, in the net, commands such as the following: > > mvn install:install-file -Dfile=YOUR_JAR.jar -DgroupId=YOUR_GROUP_ID > -DartifactId=YOUR_ARTIFACT_ID -Dversion=YOUR_VERSION -Dpackaging=jar > -DlocalRepositoryPath=/var/www/html/mavenRepository > > Is this the only correct way? I have yet to try it, primarily because I > have a few dozen artifacts and doing so will take me a long time. > > > Cheers, > George > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Gail Stewart Sr. Release Engineer AP & Payment Automation 125 Cambridgepark Drive Cambridge, MA 02140 gail.stew...@mineraltree.com 617.299.3399 x148
RE: Creating local repository
You don't really need to point to a local repository. By default Maven will use C:\Users\\.m2\respository as the local repo. (i.e. for a Windows host). If you want to specify a different location for the local repo you can use this in your settings.xml: C:\.. Finally, to populate your local repo for the first time (i.e. when you ARE connected to the net), you can execute the Maven goal archetype:create to build a "hello world" app. As long a you start with an empty local repository, wherever that happens to be i.e. the default location or somewhere else as per your settings.xml file, then Maven will attempt to get plugins and artifacts from the local repo first but since it is empty it will go to the default remote repo to get these and populate the local repo. As long as you can access the location of the local repo from your VM's there is no need to copy anything! Just one reminder, when you run Maven with the archetype:create goal DO NOT use the -o option!!! After that, when you want to use the local repo only USE the -o option. One last thought. Using Maven in offline only mode may present you with some problems down the road, depending on what "external" artifacts your application uses. If you only populate the local repo once then you will not be using updated artifacts as they become available. If you are not using any "external" artifacts (e.g. XML parsers, log file libraries, etc.) in your app, this should not be a problem. Other on the mailing list feel free to correct me if I've given George any incorrect info. Good luck! And happy building. Michael Tarullo Contractor (Engility Corp) Enterprise Architect NSRR System Administrator FAA WJH Technical Center (609)485-5294 -Original Message- From: George Karabotsos [mailto:kara...@gmail.com] Sent: Friday, September 04, 2015 10:27 AM To: users@maven.apache.org Subject: Creating local repository Hello all, Let me start by admitting I am by no means a maven expert :). Now I have a need to create a local file-based repository to be used by maven when building my project. I need this because I have no net access from a set of VMs I and colleagues have to use . I was thinking of the following: 1) connected to the net, normally proceed and download all necessary artifacts 2) copy these jars with > cp -r Users/gkarabotsos/.m2/repository . 3) Add the following to my pom.xml localrepository file:///c:/repository/ I do know that it does not work--I am guessing my c:/repository structure does not have the correct form. I have also seen, in the net, commands such as the following: mvn install:install-file -Dfile=YOUR_JAR.jar -DgroupId=YOUR_GROUP_ID -DartifactId=YOUR_ARTIFACT_ID -Dversion=YOUR_VERSION -Dpackaging=jar -DlocalRepositoryPath=/var/www/html/mavenRepository Is this the only correct way? I have yet to try it, primarily because I have a few dozen artifacts and doing so will take me a long time. Cheers, George - 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: Creating local repository
Hi Gail, The problem is that the VM is not controlled by my organization--they are controlled by a third party. As such, they are not even within our intranet. I do have access to the master VM which has access to the internet to allow me to set it up. So what you and Michael mention, to get all artifacts first, then use the -o flag from offilne VMs, should do the trick. Thank you so much! Cheers, George On Fri, Sep 4, 2015, at 10:54 AM, Gail Stewart wrote: > How are you going to get the libraries you need to this server if you > have > no net access? > > I'm not sure if this would work, but one way might be to run the maven on > a > system with internet access so it populates the local repository in > $HOME/.m2 > > Tar or zip that directory up and get it to your server. Unzip it into > your > $HOME/.m2 or to a common location for several developers to use. You can > tell maven where to find the local repo if you aren't using the default > $HOME/.m2 location. > > Then run maven in offline mode. > > This is not ideal - why doesn't the server have internet access? Could > it > have access to a company managed server? If so you could setup a nexus > or > artifactory enterprise server - that would have internet access, but > could > be controlled in a secure manner. > > > On Fri, Sep 4, 2015 at 10:27 AM, George Karabotsos <kara...@gmail.com> > wrote: > > > Hello all, > > > > Let me start by admitting I am by no means a maven expert :). > > > > Now I have a need to create a local file-based repository to be used by > > maven when building my project. I need this because I have no net > > access from a set of VMs I and colleagues have to use . > > > > I was thinking of the following: > > 1) connected to the net, normally proceed and download all necessary > > artifacts > > 2) copy these jars with > > > cp -r Users/gkarabotsos/.m2/repository . > > 3) Add the following to my pom.xml > > > > > > localrepository > > file:///c:/repository/ > > > > > > > > I do know that it does not work--I am guessing my c:/repository > > structure does not have the correct form. > > > > I have also seen, in the net, commands such as the following: > > > > mvn install:install-file -Dfile=YOUR_JAR.jar -DgroupId=YOUR_GROUP_ID > > -DartifactId=YOUR_ARTIFACT_ID -Dversion=YOUR_VERSION -Dpackaging=jar > > -DlocalRepositoryPath=/var/www/html/mavenRepository > > > > Is this the only correct way? I have yet to try it, primarily because I > > have a few dozen artifacts and doing so will take me a long time. > > > > > > Cheers, > > George > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > -- > > Gail Stewart > Sr. Release Engineer > > AP & Payment Automation > 125 Cambridgepark Drive > Cambridge, MA 02140 > gail.stew...@mineraltree.com > 617.299.3399 x148 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Creating local repository
Thank you Michael, I will give it a try and let you know how it goes. Cheers, George On Fri, Sep 4, 2015, at 10:54 AM, michael.ctr.taru...@faa.gov wrote: > You don't really need to point to a local repository. By default Maven > will use C:\Users\\.m2\respository as the local repo. (i.e. > for a Windows host). > > If you want to specify a different location for the local repo you can > use this in your settings.xml: > > C:\.. > > > Finally, to populate your local repo for the first time (i.e. when you > ARE connected to the net), you can execute the Maven goal > archetype:create to build a "hello world" app. As long a you start with > an empty local repository, wherever that happens to be i.e. the default > location or somewhere else as per your settings.xml file, then Maven will > attempt to get plugins and artifacts from the local repo first but since > it is empty it will go to the default remote repo to get these and > populate the local repo. As long as you can access the location of the > local repo from your VM's there is no need to copy anything! > > Just one reminder, when you run Maven with the archetype:create goal DO > NOT use the -o option!!! After that, when you want to use the local repo > only USE the -o option. > > One last thought. Using Maven in offline only mode may present you with > some problems down the road, depending on what "external" artifacts your > application uses. If you only populate the local repo once then you will > not be using updated artifacts as they become available. If you are not > using any "external" artifacts (e.g. XML parsers, log file libraries, > etc.) in your app, this should not be a problem. > > Other on the mailing list feel free to correct me if I've given George > any incorrect info. > > Good luck! And happy building. > > Michael Tarullo > Contractor (Engility Corp) > Enterprise Architect > NSRR System Administrator > FAA WJH Technical Center > (609)485-5294 > > > -Original Message- > From: George Karabotsos [mailto:kara...@gmail.com] > Sent: Friday, September 04, 2015 10:27 AM > To: users@maven.apache.org > Subject: Creating local repository > > Hello all, > > Let me start by admitting I am by no means a maven expert :). > > Now I have a need to create a local file-based repository to be used by > maven when building my project. I need this because I have no net access > from a set of VMs I and colleagues have to use . > > I was thinking of the following: > 1) connected to the net, normally proceed and download all necessary > artifacts > 2) copy these jars with > > cp -r Users/gkarabotsos/.m2/repository . > 3) Add the following to my pom.xml > > > localrepository > file:///c:/repository/ > > > > I do know that it does not work--I am guessing my c:/repository > structure does not have the correct form. > > I have also seen, in the net, commands such as the following: > > mvn install:install-file -Dfile=YOUR_JAR.jar -DgroupId=YOUR_GROUP_ID > -DartifactId=YOUR_ARTIFACT_ID -Dversion=YOUR_VERSION -Dpackaging=jar > -DlocalRepositoryPath=/var/www/html/mavenRepository > > Is this the only correct way? I have yet to try it, primarily because I > have a few dozen artifacts and doing so will take me a long time. > > > Cheers, > George > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Creating local repository
Hi George, We had tried this earlier in my company. The problem is you never know what is 'all' the artifacts. Challenges faced: 1.One developer adding a new third-party dependency required that the artifact should be present in all the local dev repos for proper compilation. 2.Repo grows in size. Sharing becomes difficult. Thanks, Niraj On Fri, Sep 4, 2015 at 8:51 PM, George Karabotsos <kara...@gmail.com> wrote: > Hi Gail, > > The problem is that the VM is not controlled by my organization--they > are controlled by a third party. As such, they are not even within our > intranet. > > I do have access to the master VM which has access to the internet to > allow me to set it up. So what you and Michael mention, to get all > artifacts first, then use the -o flag from offilne VMs, should do the > trick. > > Thank you so much! > > Cheers, > George > > On Fri, Sep 4, 2015, at 10:54 AM, Gail Stewart wrote: > > How are you going to get the libraries you need to this server if you > > have > > no net access? > > > > I'm not sure if this would work, but one way might be to run the maven on > > a > > system with internet access so it populates the local repository in > > $HOME/.m2 > > > > Tar or zip that directory up and get it to your server. Unzip it into > > your > > $HOME/.m2 or to a common location for several developers to use. You can > > tell maven where to find the local repo if you aren't using the default > > $HOME/.m2 location. > > > > Then run maven in offline mode. > > > > This is not ideal - why doesn't the server have internet access? Could > > it > > have access to a company managed server? If so you could setup a nexus > > or > > artifactory enterprise server - that would have internet access, but > > could > > be controlled in a secure manner. > > > > > > On Fri, Sep 4, 2015 at 10:27 AM, George Karabotsos <kara...@gmail.com> > > wrote: > > > > > Hello all, > > > > > > Let me start by admitting I am by no means a maven expert :). > > > > > > Now I have a need to create a local file-based repository to be used by > > > maven when building my project. I need this because I have no net > > > access from a set of VMs I and colleagues have to use . > > > > > > I was thinking of the following: > > > 1) connected to the net, normally proceed and download all necessary > > > artifacts > > > 2) copy these jars with > > > > cp -r Users/gkarabotsos/.m2/repository . > > > 3) Add the following to my pom.xml > > > > > > > > > localrepository > > > file:///c:/repository/ > > > > > > > > > > > > I do know that it does not work--I am guessing my c:/repository > > > structure does not have the correct form. > > > > > > I have also seen, in the net, commands such as the following: > > > > > > mvn install:install-file -Dfile=YOUR_JAR.jar -DgroupId=YOUR_GROUP_ID > > > -DartifactId=YOUR_ARTIFACT_ID -Dversion=YOUR_VERSION -Dpackaging=jar > > > -DlocalRepositoryPath=/var/www/html/mavenRepository > > > > > > Is this the only correct way? I have yet to try it, primarily because I > > > have a few dozen artifacts and doing so will take me a long time. > > > > > > > > > Cheers, > > > George > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > > > -- > > > > Gail Stewart > > Sr. Release Engineer > > > > AP & Payment Automation > > 125 Cambridgepark Drive > > Cambridge, MA 02140 > > gail.stew...@mineraltree.com > > 617.299.3399 x148 > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Update non-unique snapshots from Artifactory to local repository
Am Tue, 21 Jul 2015 23:00:12 +0300 schrieb Alex Ditu ditu.alexan...@gmail.com: I am not sure if it is a specific artifactory issue, I found this: https://www.jfrog.com/jira/browse/RTFACT-5404 if it helps Yes, if the repo does not provide the timestamps, then the policy wont work. You can purge your snapshots locally, if you dont want to delete by hand, you can use mvn dependency:purge-local-repository See https://maven.apache.org/plugins/maven-dependency-plugin/examples/purging-local-repository.html But I think deleting (with find) is pretty common (so is using timestamps). Gruss Bernd - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Update non-unique snapshots from Artifactory to local repository
Hello, I am new to maven and do not know how to solve this issue: I decided not to keep timestampped artifacts in Aritfactory but now maven is not downloading newer artifacts from Artifactory, although in metadata the versions differ. I do not want to manually delete my local copy of an artifact in order to download the latest version, it beats the hole purpose of maven. Is there an workaround for this? I can't seem to find any solution. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Update non-unique snapshots from Artifactory to local repository
Hello, not sure if you are asking about the general handling or a specific problem with Artifactory. But with mvn you can use the -U switch to force a snapshot update. Otherwise it will use the updatePolicy from your settings.xml (I think daily would be the default for snapshots repo). Gruss Bernd Am Tue, 21 Jul 2015 22:28:30 +0300 schrieb Alex Ditu ditu.alexan...@gmail.com: Hello, I am new to maven and do not know how to solve this issue: I decided not to keep timestampped artifacts in Aritfactory but now maven is not downloading newer artifacts from Artifactory, although in metadata the versions differ. I do not want to manually delete my local copy of an artifact in order to download the latest version, it beats the hole purpose of maven. Is there an workaround for this? I can't seem to find any solution. - 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: Maven does not find existing artifacts in local repository because it looks in central where they are not?
Running Maven with -x and including the relevant part of the log might help.
We are all guessing what you have screwed up.
Of course Maven has to be able to use stuff that is not in Maven Central
otherwise none of us could ever develop a library or a project with more
than one piece.
You should install a repo.
Nexus Community version is the one that I use but there are others.
Even if it is just on your workstation, it will help make Maven easier
to understand and a lot easier to use.
Free Maven Advice (http://blog.artifact-software.com/tech/?p=177) is
an article that I wrote a few years ago to help people get started.
It reflects the things that we learned as a company developing with
Maven rather than as people with inside (or very deep) knowledge about
Maven.
The people in this forum are very helpful and a lot of them really know
Maven well.
We will get you through this stage in your Maven journey :-)
Ron
On 26/03/2015 8:48 AM, Jörg Schaible wrote:
Hi Christian,
Christian Eugster wrote:
Hi
as I understand, there is a central repository for maven artifacts:
central (http://repo.maven.apache.org/maven2
http://repo.maven.apache.org/maven2) and a local one
(${user.home}/.m2/repository. What I do not understand is, why after a mvn
test maven complains about artifacts that are not in local repository. The
named artifacts are in local repository as I checked. And it says, that it
cannot download them from central. Because these artifacts are from my own
project, they are only in the local repository. Why does maven try to
download them, when they are already in local repository? Is there a wrong
setting? Does exist a reasonable documentation for beginners that is able
to explain what is going wrong?
I am thankfully for any hint!
How do you refer those artifacts? Any chance that they are included using an
import scope?
Cheers,
Jörg
-
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: Maven does not find existing artifacts in local repository because it looks in central where they are not?
Hi Christian,
Christian Eugster wrote:
Hi
as I understand, there is a central repository for maven artifacts:
central (http://repo.maven.apache.org/maven2
http://repo.maven.apache.org/maven2) and a local one
(${user.home}/.m2/repository. What I do not understand is, why after a mvn
test maven complains about artifacts that are not in local repository. The
named artifacts are in local repository as I checked. And it says, that it
cannot download them from central. Because these artifacts are from my own
project, they are only in the local repository. Why does maven try to
download them, when they are already in local repository? Is there a wrong
setting? Does exist a reasonable documentation for beginners that is able
to explain what is going wrong?
I am thankfully for any hint!
How do you refer those artifacts? Any chance that they are included using an
import scope?
Cheers,
Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Maven does not find existing artifacts in local repository because it looks in central where they are not?
Hi
as I understand, there is a central repository for maven artifacts: central
(http://repo.maven.apache.org/maven2 http://repo.maven.apache.org/maven2) and
a local one (${user.home}/.m2/repository. What I do not understand is, why
after a mvn test maven complains about artifacts that are not in local
repository. The named artifacts are in local repository as I checked. And it
says, that it cannot download them from central. Because these artifacts are
from my own project, they are only in the local repository. Why does maven try
to download them, when they are already in local repository? Is there a wrong
setting? Does exist a reasonable documentation for beginners that is able to
explain what is going wrong?
I am thankfully for any hint!
Regards Christian
Christian Eugster
Grissian 14
I-39010 Tisens
I: +39 0473 420 873
CH: +41 79 107 92 27
christian.eugs...@gmx.net
Re: Build extension not found when specifying different local repository
Are you sure the second build is using the same Maven local repo ? Jeff On Sat, Mar 7, 2015 at 2:58 PM, Pascal Rapicault pas...@rapicault.net wrote: Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T12:29:23-05:00) On 03/07/2015 02:44 AM, Jeff MAURY wrote: Which version of Maven are you using ? Jeff On Sat, Mar 7, 2015 at 12:53 AM, Pascal Rapicault pas...@rapicault.net wrote: Hi, I'm trying to do a set of builds where I'm trying to make sure I'm not getting extraneous artifacts. The first step of the build consists in building Tycho (a set of maven plugins for building OSGi / Eclipse things) and to ensure I get clean artifacts, I deleted the ~/.m2 folder and now I use the -Dmaven.repo.local parameter (I know I should not need the two but nonetheless...). The build completes and I'm happy. Now when I try to build my real project, which uses the freshly built maven plugin, here again specifying the -Dmaven.repo.local parameter, I get an error saying that Maven can't find the build extension (see error below). I tried many workarounds but none of them are working. Is this expected? Do you have any idea on how to avoid this? Thx. Unresolveable build extension: Plugin org.eclipse.tycho:tycho-maven- plugin:0.23.0-SNAPSHOT or one of its dependencies could not be resolved: Failure to find org.eclipse.tycho:tycho-maven-plugin:jar:0.23.0-SNAPSHOT in https://oss.sonatype.org/content/repositories/public/ was cached in the local repository, resolution will not be reattempted until the update interval of tycho has elapsed or updates are forced - [Help 2] Pascal - 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 -- Jeff MAURY Legacy code often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
Re: Build extension not found when specifying different local repository
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T12:29:23-05:00) On 03/07/2015 02:44 AM, Jeff MAURY wrote: Which version of Maven are you using ? Jeff On Sat, Mar 7, 2015 at 12:53 AM, Pascal Rapicault pas...@rapicault.net wrote: Hi, I'm trying to do a set of builds where I'm trying to make sure I'm not getting extraneous artifacts. The first step of the build consists in building Tycho (a set of maven plugins for building OSGi / Eclipse things) and to ensure I get clean artifacts, I deleted the ~/.m2 folder and now I use the -Dmaven.repo.local parameter (I know I should not need the two but nonetheless...). The build completes and I'm happy. Now when I try to build my real project, which uses the freshly built maven plugin, here again specifying the -Dmaven.repo.local parameter, I get an error saying that Maven can't find the build extension (see error below). I tried many workarounds but none of them are working. Is this expected? Do you have any idea on how to avoid this? Thx. Unresolveable build extension: Plugin org.eclipse.tycho:tycho-maven-plugin:0.23.0-SNAPSHOT or one of its dependencies could not be resolved: Failure to find org.eclipse.tycho:tycho-maven-plugin:jar:0.23.0-SNAPSHOT in https://oss.sonatype.org/content/repositories/public/ was cached in the local repository, resolution will not be reattempted until the update interval of tycho has elapsed or updates are forced - [Help 2] Pascal - 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
Build extension not found when specifying different local repository
Hi, I'm trying to do a set of builds where I'm trying to make sure I'm not getting extraneous artifacts. The first step of the build consists in building Tycho (a set of maven plugins for building OSGi / Eclipse things) and to ensure I get clean artifacts, I deleted the ~/.m2 folder and now I use the -Dmaven.repo.local parameter (I know I should not need the two but nonetheless...). The build completes and I'm happy. Now when I try to build my real project, which uses the freshly built maven plugin, here again specifying the -Dmaven.repo.local parameter, I get an error saying that Maven can't find the build extension (see error below). I tried many workarounds but none of them are working. Is this expected? Do you have any idea on how to avoid this? Thx. Unresolveable build extension: Plugin org.eclipse.tycho:tycho-maven-plugin:0.23.0-SNAPSHOT or one of its dependencies could not be resolved: Failure to find org.eclipse.tycho:tycho-maven-plugin:jar:0.23.0-SNAPSHOT in https://oss.sonatype.org/content/repositories/public/ was cached in the local repository, resolution will not be reattempted until the update interval of tycho has elapsed or updates are forced - [Help 2] Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Build extension not found when specifying different local repository
Which version of Maven are you using ? Jeff On Sat, Mar 7, 2015 at 12:53 AM, Pascal Rapicault pas...@rapicault.net wrote: Hi, I'm trying to do a set of builds where I'm trying to make sure I'm not getting extraneous artifacts. The first step of the build consists in building Tycho (a set of maven plugins for building OSGi / Eclipse things) and to ensure I get clean artifacts, I deleted the ~/.m2 folder and now I use the -Dmaven.repo.local parameter (I know I should not need the two but nonetheless...). The build completes and I'm happy. Now when I try to build my real project, which uses the freshly built maven plugin, here again specifying the -Dmaven.repo.local parameter, I get an error saying that Maven can't find the build extension (see error below). I tried many workarounds but none of them are working. Is this expected? Do you have any idea on how to avoid this? Thx. Unresolveable build extension: Plugin org.eclipse.tycho:tycho-maven-plugin:0.23.0-SNAPSHOT or one of its dependencies could not be resolved: Failure to find org.eclipse.tycho:tycho-maven-plugin:jar:0.23.0-SNAPSHOT in https://oss.sonatype.org/content/repositories/public/ was cached in the local repository, resolution will not be reattempted until the update interval of tycho has elapsed or updates are forced - [Help 2] Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Jeff MAURY Legacy code often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
Re: Remove old snapshots under local repository
On 19/08/2014 1:49 AM, Barrie Treloar wrote: What's wrong with just blowing away ~/.m2/repository ? If you have a local Maven Repository Manager it doesn't take very long to reseed it. (At least less time in aggregate than thinking of ways to prune snapshot files in the repository correctly...) A few days ago, I suggested just blowing away the organization's sub-folder under .m2/repository. A bit more surgical. Would that work? If you have a corporate repo (and everyone should) it does not take long to repopulate your local repo. Probably a good idea to get rid of the entire local repo every year just get rid of old version that you will never need again. I don't need to carry a 7 year history of log4j on my hard drive. Ron -- 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: Remove old snapshots under local repository
After all consideration. I use Ron's advice and create a internal plugin to clean it up. -D On Tue, Aug 19, 2014 at 6:06 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 19/08/2014 1:49 AM, Barrie Treloar wrote: What's wrong with just blowing away ~/.m2/repository ? If you have a local Maven Repository Manager it doesn't take very long to reseed it. (At least less time in aggregate than thinking of ways to prune snapshot files in the repository correctly...) A few days ago, I suggested just blowing away the organization's sub-folder under .m2/repository. A bit more surgical. Would that work? If you have a corporate repo (and everyone should) it does not take long to repopulate your local repo. Probably a good idea to get rid of the entire local repo every year just get rid of old version that you will never need again. I don't need to carry a 7 year history of log4j on my hard drive. Ron -- 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: Remove old snapshots under local repository
So not using the dependency plugin like I suggested? On 20 Aug 2014, at 10:14, Dan Tran wrote: After all consideration. I use Ron's advice and create a internal plugin to clean it up. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Remove old snapshots under local repository
the problem here is I have to enter artifactId, am I missing any thing? specially for a developer who is very clueless about Maven -D On Tue, Aug 19, 2014 at 7:09 PM, Mark Derricutt m...@talios.com wrote: So not using the dependency plugin like I suggested? On 20 Aug 2014, at 10:14, Dan Tran wrote: After all consideration. I use Ron's advice and create a internal plugin to clean it up. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Remove old snapshots under local repository
Nope, it's takes the dependencies from your project pom.xml: mvn dependency:purge-local-repository -DresolutionFuzziness=artifactId Mark On 20 Aug 2014, at 14:11, Dan Tran wrote: the problem here is I have to enter artifactId, am I missing any thing? specially for a developer who is very clueless about Maven -D On Tue, Aug 19, 2014 at 7:09 PM, Mark Derricutt m...@talios.com wrote: So not using the dependency plugin like I suggested? On 20 Aug 2014, at 10:14, Dan Tran wrote: After all consideration. I use Ron's advice and create a internal plugin to clean it up. - 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: Remove old snapshots under local repository
ah, that works with a project, in my case, i prefer not to have a project On Tue, Aug 19, 2014 at 8:07 PM, Mark Derricutt m...@talios.com wrote: Nope, it's takes the dependencies from your project pom.xml: mvn dependency:purge-local-repository -DresolutionFuzziness=artifactId Mark On 20 Aug 2014, at 14:11, Dan Tran wrote: the problem here is I have to enter artifactId, am I missing any thing? specially for a developer who is very clueless about Maven -D On Tue, Aug 19, 2014 at 7:09 PM, Mark Derricutt m...@talios.com wrote: So not using the dependency plugin like I suggested? On 20 Aug 2014, at 10:14, Dan Tran wrote: After all consideration. I use Ron's advice and create a internal plugin to clean it up. - 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: Remove old snapshots under local repository
Or delete all directories that end with -SNAPSHOT On Sun, Aug 17, 2014 at 8:18 AM, Dan Tran dant...@gmail.com wrote: sounds like a good option. Thanks -D On Sat, Aug 16, 2014 at 11:11 PM, Ron Wheeler rwhee...@artifact-software.com wrote: On 17/08/2014 1:50 AM, Dan Tran wrote: Hi I need to find a way to walk into local repository and remove all old snapshots. This is very helpful for developer to clean up his/her local rep. how safe it is by blindly remove any file with timestamp format ( ie xxx-1.0.0-20140816.071953-49.jar)? Thanks -D Easiest thing to do is to delete the entire organization or project branch (com.mycompany.project.*) from the local repo. This will not likely delete anything of great value or anything that can not be easily retrieved from your company repo. Ron -- 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 -- Adrien Rivard
Re: Remove old snapshots under local repository
I tend to use: mvn dependency:purge-local-repository when sitting in a project directory, it'll go thru and delete all the SNAPSHOTs and re-resolve. The only problem with it in the default mode, is that is _only_ deletes the `.jar`. files and doesn't rebuild any metadata, so if you're using version ranges you're kinda f**ked. However, I usually use it with the following setting: mvn dependency:purge-local-repository -DresolutionFuzziness=artifactId which will delete ALL files related to the artifact - all versions, all meta data - it doesn't mean there's more to download again but works wonderfully. MaRK On 18 Aug 2014, at 21:10, Adrien Rivard wrote: Or delete all directories that end with -SNAPSHOT On Sun, Aug 17, 2014 at 8:18 AM, Dan Tran dant...@gmail.com wrote: sounds like a good option. Thanks -D On Sat, Aug 16, 2014 at 11:11 PM, Ron Wheeler rwhee...@artifact-software.com wrote: On 17/08/2014 1:50 AM, Dan Tran wrote: Hi I need to find a way to walk into local repository and remove all old snapshots. This is very helpful for developer to clean up his/her local rep. how safe it is by blindly remove any file with timestamp format ( ie xxx-1.0.0-20140816.071953-49.jar)? Thanks -D Easiest thing to do is to delete the entire organization or project branch (com.mycompany.project.*) from the local repo. This will not likely delete anything of great value or anything that can not be easily retrieved from your company repo. Ron -- 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 -- Adrien Rivard
Re: Remove old snapshots under local repository
This would not work, since it still leave all snapshot of timestamp around -D On Mon, Aug 18, 2014 at 2:10 AM, Adrien Rivard adrien.riv...@gmail.com wrote: Or delete all directories that end with -SNAPSHOT On Sun, Aug 17, 2014 at 8:18 AM, Dan Tran dant...@gmail.com wrote: sounds like a good option. Thanks -D On Sat, Aug 16, 2014 at 11:11 PM, Ron Wheeler rwhee...@artifact-software.com wrote: On 17/08/2014 1:50 AM, Dan Tran wrote: Hi I need to find a way to walk into local repository and remove all old snapshots. This is very helpful for developer to clean up his/her local rep. how safe it is by blindly remove any file with timestamp format ( ie xxx-1.0.0-20140816.071953-49.jar)? Thanks -D Easiest thing to do is to delete the entire organization or project branch (com.mycompany.project.*) from the local repo. This will not likely delete anything of great value or anything that can not be easily retrieved from your company repo. Ron -- 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 -- Adrien Rivard
Re: Remove old snapshots under local repository
Sure it would. It's only the files that gets a timestamp; the directories are still called x.y.z-SNAPSHOT. However, be adviced that I've run into cases in the wild where the artifactId would end in -SNAPSHOT and this solution would remove such directories as well although it's could contain releases (and snapshots). Such a artifactId naming is not very good and kind of deserves to cause issues though... /Anders On Tue, Aug 19, 2014 at 7:28 AM, Dan Tran dant...@gmail.com wrote: This would not work, since it still leave all snapshot of timestamp around -D On Mon, Aug 18, 2014 at 2:10 AM, Adrien Rivard adrien.riv...@gmail.com wrote: Or delete all directories that end with -SNAPSHOT On Sun, Aug 17, 2014 at 8:18 AM, Dan Tran dant...@gmail.com wrote: sounds like a good option. Thanks -D On Sat, Aug 16, 2014 at 11:11 PM, Ron Wheeler rwhee...@artifact-software.com wrote: On 17/08/2014 1:50 AM, Dan Tran wrote: Hi I need to find a way to walk into local repository and remove all old snapshots. This is very helpful for developer to clean up his/her local rep. how safe it is by blindly remove any file with timestamp format ( ie xxx-1.0.0-20140816.071953-49.jar)? Thanks -D Easiest thing to do is to delete the entire organization or project branch (com.mycompany.project.*) from the local repo. This will not likely delete anything of great value or anything that can not be easily retrieved from your company repo. Ron -- 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 -- Adrien Rivard
Re: Remove old snapshots under local repository
What's wrong with just blowing away ~/.m2/repository ? If you have a local Maven Repository Manager it doesn't take very long to reseed it. (At least less time in aggregate than thinking of ways to prune snapshot files in the repository correctly...)
Re: Remove old snapshots under local repository
On 17/08/2014 1:50 AM, Dan Tran wrote: Hi I need to find a way to walk into local repository and remove all old snapshots. This is very helpful for developer to clean up his/her local rep. how safe it is by blindly remove any file with timestamp format ( ie xxx-1.0.0-20140816.071953-49.jar)? Thanks -D Easiest thing to do is to delete the entire organization or project branch (com.mycompany.project.*) from the local repo. This will not likely delete anything of great value or anything that can not be easily retrieved from your company repo. Ron -- 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: Remove old snapshots under local repository
sounds like a good option. Thanks -D On Sat, Aug 16, 2014 at 11:11 PM, Ron Wheeler rwhee...@artifact-software.com wrote: On 17/08/2014 1:50 AM, Dan Tran wrote: Hi I need to find a way to walk into local repository and remove all old snapshots. This is very helpful for developer to clean up his/her local rep. how safe it is by blindly remove any file with timestamp format ( ie xxx-1.0.0-20140816.071953-49.jar)? Thanks -D Easiest thing to do is to delete the entire organization or project branch (com.mycompany.project.*) from the local repo. This will not likely delete anything of great value or anything that can not be easily retrieved from your company repo. Ron -- 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
Remove old snapshots under local repository
Hi I need to find a way to walk into local repository and remove all old snapshots. This is very helpful for developer to clean up his/her local rep. how safe it is by blindly remove any file with timestamp format ( ie xxx-1.0.0-20140816.071953-49.jar)? Thanks -D
Re: local repository permissions
How can I get maven to create directories and files with world writeable permissions when it is downloading or installing to the local ~/.m2 repository ? Most likely you are attempting to do something that Maven does not want you to do - the ~/.m2 repo is not designed to be shared. Describe your use case more. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
local repository permissions
How can I get maven to create directories and files with world writeable permissions when it is downloading or installing to the local ~/.m2 repository ? -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Prevent installing archives to local repository
I have take a look, and found that each file, created with the maven assembly plugin was installed to the local repository under the project name. In my case the maven assembly plugin creates a file abc.zip that is part of the distribution, and maven install plugin installed the abs.zip to the local repository as projectName.zip and the distribution file. My idea is to skip the installation of abc.zip to the repository because it is only temporary needed, and is part of the distribution zip file. -- View this message in context: http://maven.40175.n5.nabble.com/Prevent-installing-archives-to-local-repository-tp5784848p5785132.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: Prevent installing archives to local repository
Hi, I have take a look, and found that each file, created with the maven assembly plugin was installed to the local repository under the project name. In my case the maven assembly plugin creates a file abc.zip that is part of the distribution, and maven install plugin installed the abs.zip to the local repository as projectName.zip and the distribution file. My idea is to skip the installation of abc.zip to the repository because it is only temporary needed, and is part of the distribution zip file. There is an parameter for the maven-assembly-plugin http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html which allows to suppress attaching an artifact in particular if you have intermediate results which you don't like to attach to the project.. attachfalse/attach which needs having a separate execution block... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Prevent installing archives to local repository
Thank you, it works fine. I it seems i have ignored this parameter from the documentation. It was my mistake. -- View this message in context: http://maven.40175.n5.nabble.com/Prevent-installing-archives-to-local-repository-tp5784848p5785135.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
Prevent installing archives to local repository
Hi everybody, one of my project create multiple jar and zip files during the build life cycle, and each archive was created with the maven assembly plugin. And now i see, that some of the files are installing to the local repository and some not. The files that i need are installed to the repository, but there is also a file that should not be installed. My question is how maven install plugin detect which file should be installed and which not, and is there a possibility to control this process and define that a specific file shouldn't be installed. Thank you in advance! Regards, DenisDasKind -- View this message in context: http://maven.40175.n5.nabble.com/Prevent-installing-archives-to-local-repository-tp5784848.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: Prevent installing archives to local repository
i see, that some of the files are installing to the local repository and some not. The files that i need are installed to the repository, but there is also a file that should not be installed. My question is how maven Can you be more specific about the file that should not be installed? What is special about it? install plugin detect which file should be installed and which not, and is there a possibility to control this process and define that a specific file shouldn't be installed. Perhaps share your pom so we can comment on improvements? Please don't just email it here - post to pastebin or a similar service and send us the link. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
mvn install give permission denied error for writing track file to local repository
(ProjectModelResolver.java:155) at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:817) at org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:669) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:307) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:411) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:380) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:496) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:380) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:344) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:638) at org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:587) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:230) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357) [WARNING] Failed to read tracking file /export/home/jque/.m2/repository/org/apache/apache/9/_remote.repositories ... I don't know what is the problem. Please help me to get some clue. Thanks. -- View this message in context: http://maven.40175.n5.nabble.com/mvn-install-give-permission-denied-error-for-writing-track-file-to-local-repository-tp5762801.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: local repository problem
First of all, could you enlighten us why you're doing what you're doing? It looks to me that your just making things difficult which will get you into trouble. Maven is designed to work with repositories. If you don't like that then Maven is probably not the tool for you. Secondly, you can never remove all the repos from your build. The super-pom declares central as a repo and you can't remove that. So, there will always be at least one repo declared. To answer the question about the error you run into I believe it is because Maven 3.0.x keeps track of where an artifact has been downloaded from. So if you remove the repo, this might not match although the artifact *file* actually does exist in the local repo. But please, rethink your approach as you, IMHO, are looking for problems. /Anders On Tue, Nov 20, 2012 at 12:39 PM, Levin, Ilya ilya.le...@hp.com wrote: Hi, My problem is this. I want my maven project to take the artifacts only from the local repository. The first mvn run is a regular one so that all artifact could be downloaded to the local repository. The second run is with flag -o (maven offline) . and it is in fact works - maven uses only the cache. So in that case it's logical to think that if running offline, I can REMOVE the repository name from my main pom (since all the artifact are cached). BUT the minute I do that (and still running with flag -o) maven throws this at me: Unable to find artifact. The repository system is offline but the artifact some artifact is not available in the local repository. and of course the artifact is there. When I return back the repository name to the pom, again it works. So why do I need the repository name in the pom if running offline? Thanks for the help. ilya
