You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by zuxiong lin <li...@gmail.com> on 2012/01/04 03:14:27 UTC

Could we delete old version jar in local repository by mvn ?

Is it possible?


Thanks.

Re: Could we delete old version jar in local repository by mvn ?

Posted by Jesse Farinacci <ji...@gmail.com>.
Greetings,

On Tue, Jan 3, 2012 at 9:14 PM, zuxiong lin <li...@gmail.com>wrote:

> Is it possible?
>

http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html

-Jesse

-- 
There are 10 types of people in this world, those
that can read binary and those that can not.

Re: Could we delete old version jar in local repository by mvn ?

Posted by Julien PLAQUEVENT <pl...@gmail.com>.
If I understand well, it is possible !

If you want to do it manually, go to your home directory's ".m2" hidden
folder, then remove whatever you want from the repository folder.

If you want to do it from a project pom, just use maven-clean-plugin on
${settings.localRepository}/org/.../myproject/3.0.1  in the build section
of the pom. You can also remove the root of "myproject" since your local
repository is just a workspace and the latest version will be installed by
the build after the clean phase.

If you want to do it from .m2/settings.xml you can also create a profile
doing this (not sure but I use a profile in my pom to do so, and you can
add profiles in settings.xml so I guess it is possible).

Best Regards,

Julien Plaquevent
Thales Critical Information Systems

2012/1/4 Jesse Farinacci <ji...@gmail.com>

> Greetings,
>
> On Tue, Jan 3, 2012 at 11:02 PM, zuxiong lin <linzuxiong1988@gmail.com
> >wrote:
>
> > Append
> > like:
> > repository\org\springframework\spring-core
> > -3.0.5.RELEASE
> > -3.0.6.RELEASE
> > -3.1.0.RELEASE
> >
> > I want to remove 3.0.5 and 3.0.6.
>
>
> I don't think this is possible with an existing plugin. I don't think it
> would even be advisable for non-SNAPSHOT artifacts..
>
> -Jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>

Re: Could we delete old version jar in local repository by mvn ?

Posted by Jesse Farinacci <ji...@gmail.com>.
Greetings,

On Tue, Jan 3, 2012 at 11:02 PM, zuxiong lin <li...@gmail.com>wrote:

> Append
> like:
> repository\org\springframework\spring-core
> -3.0.5.RELEASE
> -3.0.6.RELEASE
> -3.1.0.RELEASE
>
> I want to remove 3.0.5 and 3.0.6.


I don't think this is possible with an existing plugin. I don't think it
would even be advisable for non-SNAPSHOT artifacts..

-Jesse

-- 
There are 10 types of people in this world, those
that can read binary and those that can not.

Re: Could we delete old version jar in local repository by mvn ?

Posted by Ansgar Konermann <an...@googlemail.com>.
Am 05.01.2012 02:07 schrieb "zuxiong lin" <li...@gmail.com>:
>
> Because of my not enough disk space...

Then it's okay. Maven will re-download what it needs.

A.

>
> 2012/1/5 Ansgar Konermann <an...@googlemail.com>
>
> > Am 04.01.2012 05:02, schrieb zuxiong lin:
> > > Append
> > > like:
> > > repository\org\springframework\spring-core
> > > -3.0.5.RELEASE
> > > -3.0.6.RELEASE
> > > -3.1.0.RELEASE
> > >
> > > I want to remove 3.0.5 and 3.0.6.
> >
> > The local maven repository is an artifact cache. Why do you want to
> > remove anything from this cache? This does not reliably control what
> > versions maven will use to build your project.
> >
> > If your project has a dependency on any of these, maven will re-download
> > them anyway.
> >
> > If you try to restrict maven to using a specific version of spring-core,
> > use something like <version>[3.1.0]</version>
> >
> > If your project does not have 3.0.5 or 3.0.6 as a direct dependency, but
> > some other dependency pulls it in as a transitive dependency, say
> > spring-core 3.0.5.RELEASE and you want to prevent 3.0.5 being on the
> > classpath because 3.1.0.RELEASE should be used, employ Maven's
> > dependency <excludes> to control this.
> >
> > This is all well documented stuff (see [1])
> >
> > Best regards
> >
> > Ansgar
> >
> >
> >
> >
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-dependencies.html
> >
> > >
> > >
> > >
> > >
> > > 2012/1/4 zuxiong lin <li...@gmail.com>
> > >
> > >> Is it possible?
> > >>
> > >>
> > >> Thanks.
> > >>
> >
> >

Re: Could we delete old version jar in local repository by mvn ?

Posted by zuxiong lin <li...@gmail.com>.
Because of my not enough disk space...

2012/1/5 Ansgar Konermann <an...@googlemail.com>

> Am 04.01.2012 05:02, schrieb zuxiong lin:
> > Append
> > like:
> > repository\org\springframework\spring-core
> > -3.0.5.RELEASE
> > -3.0.6.RELEASE
> > -3.1.0.RELEASE
> >
> > I want to remove 3.0.5 and 3.0.6.
>
> The local maven repository is an artifact cache. Why do you want to
> remove anything from this cache? This does not reliably control what
> versions maven will use to build your project.
>
> If your project has a dependency on any of these, maven will re-download
> them anyway.
>
> If you try to restrict maven to using a specific version of spring-core,
> use something like <version>[3.1.0]</version>
>
> If your project does not have 3.0.5 or 3.0.6 as a direct dependency, but
> some other dependency pulls it in as a transitive dependency, say
> spring-core 3.0.5.RELEASE and you want to prevent 3.0.5 being on the
> classpath because 3.1.0.RELEASE should be used, employ Maven's
> dependency <excludes> to control this.
>
> This is all well documented stuff (see [1])
>
> Best regards
>
> Ansgar
>
>
>
> http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-dependencies.html
>
> >
> >
> >
> >
> > 2012/1/4 zuxiong lin <li...@gmail.com>
> >
> >> Is it possible?
> >>
> >>
> >> Thanks.
> >>
>
>

Re: Could we delete old version jar in local repository by mvn ?

Posted by Ron Wheeler <rw...@artifact-software.com>.
On 11/01/2012 8:33 AM, Stephen Connolly wrote:
> actually, no, in that case I would recommend downloading a repository
> manager and running it locally.
>
> Running Maven without a repository manager is like driving a car with
> a 24inch spike pointing out of the middle of the steering wheel
And a cactus on the driver's seat.
Not going to kill you until you hit the breaks but an ongoing source of 
pain.

>
> On 11 January 2012 12:31, Rueegg Alexander<AL...@bdal.de>  wrote:
>> Hi!
>>
>> I think you should even in this case use a different directory on your local filesystem to deploy your proprietary artifacts to. Isn't that best practise? Think of making backups of your deployed artifacts and not of the whole cached artifacts from the internet. Mixing things in the same type of repositories leads to more confusion and is not reproducable.
>>
>> Best
>> Alex
>>
>>> It's not a cache for another reason...
>>>
>>> mvn install:install-file
>>>
>>> where you install proprietary artifacts into your local repo
>>> when working on proprietary code and you don't have a proper
>>> repository manager to host them on.
>>>
>>> So you really have to know why each artifact is there and
>>> where it came from before you can just delete it at random.
>>
>> -----------------------------
>> Bruker Daltonik GmbH
>>
>> Fahrenheitstrasse 4                     Gesch?ftsf?hrer                         Sitz der Gesellschaft
>> 28359 Bremen                            Frank Laukien, Ph. D.           Bremen
>> Germany                                         Gerd H?lso
>>                                                         Sebastian Meyer-Plath
>> Bruker Daltonik GmbH            Stefan Ruge                                     Handelsregister
>> Zweigniederlassung Leipzig      Dr.Ian Sanders, Ph. D.          Amtsgericht Bremen
>>                                                         Dr. Michael Schubert            HRB 8150
>> Permoserstrasse 15                      Dr. Michael Schubert            www.bdal.de
>> 04318 Leipzig
>> Germany
>>
>>
>> Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich f?r die ordnungsgem??e, vollst?ndige und verz?gerungsfreie ?bertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend best?tigt wird.
>>
>> Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax.
>>
>>
>>
>> -----------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102



Re: Could we delete old version jar in local repository by mvn ?

Posted by Stephen Connolly <st...@gmail.com>.
I was only pointing out that silly users can do silly things, like
installing manually, so saying it is just a cache is incorrect

On 11 January 2012 14:34, Rueegg Alexander <AL...@bdal.de> wrote:
> Sorry, but I was confused that you suggested to run mvn install:install-file to "deploy" proprietary artifacts when you don't have a proper repository manager installed. For sure best is to use a repo manager!
>
>
>> -----Original Message-----
>> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>> Sent: Mittwoch, 11. Januar 2012 14:33
>> To: Maven Users List
>> Subject: Re: Could we delete old version jar in local
>> repository by mvn ?
>>
>> actually, no, in that case I would recommend downloading a
>> repository manager and running it locally.
>>
>> Running Maven without a repository manager is like driving a
>> car with a 24inch spike pointing out of the middle of the
>> steering wheel
>>
>> On 11 January 2012 12:31, Rueegg Alexander <AL...@bdal.de> wrote:
>> > Hi!
>> >
>> > I think you should even in this case use a different
>> directory on your local filesystem to deploy your proprietary
>> artifacts to. Isn't that best practise? Think of making
>> backups of your deployed artifacts and not of the whole
>> cached artifacts from the internet. Mixing things in the same
>> type of repositories leads to more confusion and is not reproducable.
>> >
>> > Best
>> > Alex
>> >
>> >> It's not a cache for another reason...
>> >>
>> >> mvn install:install-file
>> >>
>> >> where you install proprietary artifacts into your local repo when
>> >> working on proprietary code and you don't have a proper repository
>> >> manager to host them on.
>> >>
>> >> So you really have to know why each artifact is there and where it
>> >> came from before you can just delete it at random.
>> >
>> >
>> > -----------------------------
>> > Bruker Daltonik GmbH
>> >
>> > Fahrenheitstrasse 4                     Gesch?ftsf?hrer
>>
>> > Sitz der Gesellschaft
>> > 28359 Bremen                            Frank Laukien, Ph.
>> D.
>> > Bremen Germany                                         Gerd H?lso
>> >                                                        Sebastian
>> > Meyer-Plath Bruker Daltonik GmbH            Stefan Ruge
>>
>> > Handelsregister Zweigniederlassung Leipzig      Dr.Ian
>> Sanders, Ph. D.
>> > Amtsgericht Bremen
>> >                                                        Dr. Michael
>> > Schubert            HRB 8150 Permoserstrasse 15
>>
>> > Dr. Michael Schubert            www.bdal.de
>> > 04318 Leipzig
>> > Germany
>> >
>> >
>> > Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht
>> verantwortlich f?r die ordnungsgem??e, vollst?ndige und
>> verz?gerungsfreie ?bertragung der Nachricht. Der Inhalt der
>> E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch
>> einen Brief oder ein Fax entsprechend best?tigt wird.
>> >
>> > Exclusion from liability: Any liability of Bruker Daltonik
>> GmbH referring to the correct, complete and immediate
>> transmission of the message shall be excluded. The content of
>> the e-mail including its attachments is only legally binding
>> if confirmed by Bruker Daltonik GmbH by letter or fax.
>> >
>> >
>> >
>> > -----------------------------
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: Could we delete old version jar in local repository by mvn ?

Posted by Rueegg Alexander <AL...@bdal.de>.
Sorry, but I was confused that you suggested to run mvn install:install-file to "deploy" proprietary artifacts when you don't have a proper repository manager installed. For sure best is to use a repo manager!


> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com] 
> Sent: Mittwoch, 11. Januar 2012 14:33
> To: Maven Users List
> Subject: Re: Could we delete old version jar in local 
> repository by mvn ?
> 
> actually, no, in that case I would recommend downloading a 
> repository manager and running it locally.
> 
> Running Maven without a repository manager is like driving a 
> car with a 24inch spike pointing out of the middle of the 
> steering wheel
> 
> On 11 January 2012 12:31, Rueegg Alexander <AL...@bdal.de> wrote:
> > Hi!
> >
> > I think you should even in this case use a different 
> directory on your local filesystem to deploy your proprietary 
> artifacts to. Isn't that best practise? Think of making 
> backups of your deployed artifacts and not of the whole 
> cached artifacts from the internet. Mixing things in the same 
> type of repositories leads to more confusion and is not reproducable.
> >
> > Best
> > Alex
> >
> >> It's not a cache for another reason...
> >>
> >> mvn install:install-file
> >>
> >> where you install proprietary artifacts into your local repo when 
> >> working on proprietary code and you don't have a proper repository 
> >> manager to host them on.
> >>
> >> So you really have to know why each artifact is there and where it 
> >> came from before you can just delete it at random.
> >
> >
> > -----------------------------
> > Bruker Daltonik GmbH
> >
> > Fahrenheitstrasse 4                     Gesch?ftsf?hrer     
>                     
> > Sitz der Gesellschaft
> > 28359 Bremen                            Frank Laukien, Ph. 
> D.           
> > Bremen Germany                                         Gerd H?lso
> >                                                        Sebastian 
> > Meyer-Plath Bruker Daltonik GmbH            Stefan Ruge     
>                                 
> > Handelsregister Zweigniederlassung Leipzig      Dr.Ian 
> Sanders, Ph. D.          
> > Amtsgericht Bremen
> >                                                        Dr. Michael 
> > Schubert            HRB 8150 Permoserstrasse 15             
>          
> > Dr. Michael Schubert            www.bdal.de
> > 04318 Leipzig
> > Germany
> >
> >
> > Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht 
> verantwortlich f?r die ordnungsgem??e, vollst?ndige und 
> verz?gerungsfreie ?bertragung der Nachricht. Der Inhalt der 
> E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch 
> einen Brief oder ein Fax entsprechend best?tigt wird.
> >
> > Exclusion from liability: Any liability of Bruker Daltonik 
> GmbH referring to the correct, complete and immediate 
> transmission of the message shall be excluded. The content of 
> the e-mail including its attachments is only legally binding 
> if confirmed by Bruker Daltonik GmbH by letter or fax.
> >
> >
> >
> > -----------------------------
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Could we delete old version jar in local repository by mvn ?

Posted by Stephen Connolly <st...@gmail.com>.
actually, no, in that case I would recommend downloading a repository
manager and running it locally.

Running Maven without a repository manager is like driving a car with
a 24inch spike pointing out of the middle of the steering wheel

On 11 January 2012 12:31, Rueegg Alexander <AL...@bdal.de> wrote:
> Hi!
>
> I think you should even in this case use a different directory on your local filesystem to deploy your proprietary artifacts to. Isn't that best practise? Think of making backups of your deployed artifacts and not of the whole cached artifacts from the internet. Mixing things in the same type of repositories leads to more confusion and is not reproducable.
>
> Best
> Alex
>
>> It's not a cache for another reason...
>>
>> mvn install:install-file
>>
>> where you install proprietary artifacts into your local repo
>> when working on proprietary code and you don't have a proper
>> repository manager to host them on.
>>
>> So you really have to know why each artifact is there and
>> where it came from before you can just delete it at random.
>
>
> -----------------------------
> Bruker Daltonik GmbH
>
> Fahrenheitstrasse 4                     Gesch?ftsf?hrer                         Sitz der Gesellschaft
> 28359 Bremen                            Frank Laukien, Ph. D.           Bremen
> Germany                                         Gerd H?lso
>                                                        Sebastian Meyer-Plath
> Bruker Daltonik GmbH            Stefan Ruge                                     Handelsregister
> Zweigniederlassung Leipzig      Dr.Ian Sanders, Ph. D.          Amtsgericht Bremen
>                                                        Dr. Michael Schubert            HRB 8150
> Permoserstrasse 15                      Dr. Michael Schubert            www.bdal.de
> 04318 Leipzig
> Germany
>
>
> Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich f?r die ordnungsgem??e, vollst?ndige und verz?gerungsfreie ?bertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend best?tigt wird.
>
> Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax.
>
>
>
> -----------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: Could we delete old version jar in local repository by mvn ?

Posted by Rueegg Alexander <AL...@bdal.de>.
Hi!

I think you should even in this case use a different directory on your local filesystem to deploy your proprietary artifacts to. Isn't that best practise? Think of making backups of your deployed artifacts and not of the whole cached artifacts from the internet. Mixing things in the same type of repositories leads to more confusion and is not reproducable.

Best
Alex

> It's not a cache for another reason...
>
> mvn install:install-file
>
> where you install proprietary artifacts into your local repo
> when working on proprietary code and you don't have a proper
> repository manager to host them on.
>
> So you really have to know why each artifact is there and
> where it came from before you can just delete it at random.


-----------------------------
Bruker Daltonik GmbH

Fahrenheitstrasse 4                     Gesch?ftsf?hrer                         Sitz der Gesellschaft
28359 Bremen                            Frank Laukien, Ph. D.           Bremen
Germany                                         Gerd H?lso
                                                        Sebastian Meyer-Plath
Bruker Daltonik GmbH            Stefan Ruge                                     Handelsregister
Zweigniederlassung Leipzig      Dr.Ian Sanders, Ph. D.          Amtsgericht Bremen
                                                        Dr. Michael Schubert            HRB 8150
Permoserstrasse 15                      Dr. Michael Schubert            www.bdal.de
04318 Leipzig
Germany


Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich f?r die ordnungsgem??e, vollst?ndige und verz?gerungsfreie ?bertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend best?tigt wird.

Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax.



-----------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Could we delete old version jar in local repository by mvn ?

Posted by Stephen Connolly <st...@gmail.com>.
On 5 January 2012 13:41, Mark H. Wood <mw...@iupui.edu> wrote:
> On Wed, Jan 04, 2012 at 10:19:15PM +0100, Ansgar Konermann wrote:
>> Am 04.01.2012 05:02, schrieb zuxiong lin:
>> > I want to remove 3.0.5 and 3.0.6.
>>
>> The local maven repository is an artifact cache. Why do you want to
>> remove anything from this cache? This does not reliably control what
>> versions maven will use to build your project.
>
> Because it is not a cache; it is a dumping ground for every artifact
> Maven has ever fetched, whether or not that artifact will ever again

It's not a cache for another reason...

mvn install:install-file

where you install proprietary artifacts into your local repo when
working on proprietary code and you don't have a proper repository
manager to host them on.

So you really have to know why each artifact is there and where it
came from before you can just delete it at random.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Could we delete old version jar in local repository by mvn ?

Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Wed, Jan 04, 2012 at 10:19:15PM +0100, Ansgar Konermann wrote:
> Am 04.01.2012 05:02, schrieb zuxiong lin:
> > Append
> > like:
> > repository\org\springframework\spring-core
> > -3.0.5.RELEASE
> > -3.0.6.RELEASE
> > -3.1.0.RELEASE
> >
> > I want to remove 3.0.5 and 3.0.6.
> 
> The local maven repository is an artifact cache. Why do you want to
> remove anything from this cache? This does not reliably control what
> versions maven will use to build your project.

Because it is not a cache; it is a dumping ground for every artifact
Maven has ever fetched, whether or not that artifact will ever again
be called for.  Proper caches are limited by age, size, or both, but
the local Maven repository grows without limit.  Some people would
like to evict probably-useless artifacts from the "cache" and reclaim
the storage they occupy as well as the time spent rummaging through
all those directory entries.

[All together now: "storage is cheap!"  Storage is not free, and the
time and effort to put through a requisition, take delivery, schedule
a machine down, rip it open, install more storage, close it up, test
it, and return it to service is definitely not free and often far from
cheap.  A reasonably tidy system does more and costs less.]

That said, I think I wouldn't bother cleaning out any 3.x until 4.1
ships, or until they're at least 12 months old.  Too-aggressive cache
trimming is much more costly than no trimming at all.

Can Maven log artifact fetches and cache hits in a way that would be
useful for developing statistics on artifacts' useful lifetimes, so we
could concoct well-thought-out cache maintenance strategies?

Or maybe it would be easier to just write a script to clobber anything
with an atime more than 180 days in the past.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.

Re: Could we delete old version jar in local repository by mvn ?

Posted by Ansgar Konermann <an...@googlemail.com>.
Am 04.01.2012 05:02, schrieb zuxiong lin:
> Append
> like:
> repository\org\springframework\spring-core
> -3.0.5.RELEASE
> -3.0.6.RELEASE
> -3.1.0.RELEASE
>
> I want to remove 3.0.5 and 3.0.6.

The local maven repository is an artifact cache. Why do you want to
remove anything from this cache? This does not reliably control what
versions maven will use to build your project.

If your project has a dependency on any of these, maven will re-download
them anyway.

If you try to restrict maven to using a specific version of spring-core,
use something like <version>[3.1.0]</version>

If your project does not have 3.0.5 or 3.0.6 as a direct dependency, but
some other dependency pulls it in as a transitive dependency, say
spring-core 3.0.5.RELEASE and you want to prevent 3.0.5 being on the
classpath because 3.1.0.RELEASE should be used, employ Maven's
dependency <excludes> to control this.

This is all well documented stuff (see [1])

Best regards

Ansgar


http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-dependencies.html

>
>
>
>
> 2012/1/4 zuxiong lin <li...@gmail.com>
>
>> Is it possible?
>>
>>
>> Thanks.
>>


Re: Could we delete old version jar in local repository by mvn ?

Posted by zuxiong lin <li...@gmail.com>.
Append
like:
repository\org\springframework\spring-core
-3.0.5.RELEASE
-3.0.6.RELEASE
-3.1.0.RELEASE

I want to remove 3.0.5 and 3.0.6.




2012/1/4 zuxiong lin <li...@gmail.com>

> Is it possible?
>
>
> Thanks.
>