On 09/08/2010 1:25 PM, Jason van Zyl wrote:
On Aug 9, 2010, at 12:57 PM, Haszlakiewicz, Eric wrote:
-Original Message-
From: Jason van Zyl [mailto:ja...@sonatype.com]
The nut of the problem is that if we had to support every optional
behavior
for a particular subset of the community
On Aug 9, 2010, at 12:57 PM, Haszlakiewicz, Eric wrote:
>> -Original Message-
>> From: Jason van Zyl [mailto:ja...@sonatype.com]
>>
>> The nut of the problem is that if we had to support every optional
> behavior
>> for a particular subset of the community the code base would likely be
>
>-Original Message-
>From: Jason van Zyl [mailto:ja...@sonatype.com]
>
>The nut of the problem is that if we had to support every optional
behavior
>for a particular subset of the community the code base would likely be
>unmaintainable. No one here is going to implement anything toward what
>-Original Message-
>From: Wayne Fay [mailto:wayne...@gmail.com]
>
>>> I rapidly browsed the thread, please excuse me if I missed
something.
>>> Isn't mvn dependency:purge-local-repository the solution?
>>
>> The issue identified by the OP is that there's no way to
(pro-actively)
>detect th
>> I rapidly browsed the thread, please excuse me if I missed something.
>> Isn't mvn dependency:purge-local-repository the solution?
>
> The issue identified by the OP is that there's no way to (pro-actively)
> detect that a release has changed.
I apologize in advance for a TERRIBLE suggestion..
On Aug 8, 2010, at 5:32 AM, Baptiste MATHUS wrote:
> Hi,
>
> I rapidly browsed the thread, please excuse me if I missed something.
> Isn't mvn dependency:purge-local-repository the solution?
The issue identified by the OP is that there's no way to (pro-actively) detect
that a release has cha
On 08/08/2010 5:32 AM, Baptiste MATHUS wrote:
Hi,
I rapidly browsed the thread, please excuse me if I missed something.
Isn't mvn dependency:purge-local-repository the solution?
Please note that I'm 100% with people saying releases must never change. And
it's so important it's not something sp
Hi,
I rapidly browsed the thread, please excuse me if I missed something.
Isn't mvn dependency:purge-local-repository the solution?
Please note that I'm 100% with people saying releases must never change. And
it's so important it's not something specific to maven world. Imagine you
release a 1.0
Eric
This is the kindest and gentlest explanation of the situation and the
best offer that you are going to get.
Ron
On 06/08/2010 8:38 PM, Jason van Zyl wrote:
The nut of the problem is that if we had to support every optional behavior for
a particular subset of the community the code bas
ail peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Subject: Re: force maven to redownload/refresh "released" dependencies
> From: kath...@kathrynhuxtable.org
> Date: Fri, 6 Aug 2010 18:28:32 -0500
On Aug 6, 2010, at 3:53 PM, Haszlakiewicz, Eric wrote:
>> -Original Message-
>> From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org]
>>
>> Eric, you're not going to win this one. It's part of the philosophy of
>> Maven. It's also good practice.
>>
>> Give it up.
>>
>> I'm not go
On Aug 6, 2010, at 6:16 PM, Ron Wheeler wrote:
> On 06/08/2010 5:56 PM, Haszlakiewicz, Eric wrote:
>>> -Original Message-
>>> From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
I'm AGREEING with you that the solution is to wipe out the local
artifact! But you can only do
On 06/08/2010 5:56 PM, Haszlakiewicz, Eric wrote:
-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
I'm AGREEING with you that the solution is to wipe out the local
artifact! But you can only do that once you know there is something
wrong. How do you detect
>-Original Message-
>From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
> On 06/08/2010 4:04 PM, Haszlakiewicz, Eric wrote:
>> Is it really going to be that much wasted bandwidth to download a few
>> checksums?
>>
>> Can a plugin hook into the existing support for detecting changes
>-Original Message-
>From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
>> I'm AGREEING with you that the solution is to wipe out the local
>> artifact! But you can only do that once you know there is something
>> wrong. How do you detect that the artifact has changed?
>If you can
On 06/08/2010 4:04 PM, Haszlakiewicz, Eric wrote:
-Original Message-
From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com]
On
On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
wrote:
You're missing the point of what I'm asking. I'm not suggesting that
maven make i
On 06/08/2010 4:01 PM, Haszlakiewicz, Eric wrote:
-Original Message-
From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com]
On
On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
wrote:
Please read the rest of the email thread. The short summary is:
Yes, I know wha
On Aug 6, 2010, at 2:58 PM, Paul Benedict wrote:
> On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
> wrote:
>
>> You're missing the point of what I'm asking. I'm not suggesting that
>> maven make it possible or easy to *create* the violation. I'm
>> suggesting that it should be able to *det
>-Original Message-
>From: Eduardo M KALINOWSKI [mailto:edua...@kalinowski.com.br]
>
>On Sex, 06 Ago 2010, "Haszlakiewicz, Eric" wrote:
>> I'm AGREEING with you that the solution is to wipe out the local
>> artifact! But you can only do that once you know there is something
>> wrong. How
On Sex, 06 Ago 2010, "Haszlakiewicz, Eric" wrote:
I'm AGREEING with you that the solution is to wipe out the local
artifact! But you can only do that once you know there is something
wrong. How do you detect that the artifact has changed?
You don't have to, because released artifacts do not c
>-Original Message-
>From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com]
On
>On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
>wrote:
>
>> You're missing the point of what I'm asking. I'm not suggesting that
>> maven make it possible or easy to *create* the violation.
So you just want to verify?
$ mvn --help
usage: mvn [options] [] []
Options:
-am,--also-makeIf project list is specified, also
build projects required by the
list
-amd,--also-make-dependents
> On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
> wrote:
>
>> You're missing the point of what I'm asking. I'm not suggesting that
>> maven make it possible or easy to *create* the violation. I'm
>> suggesting that it should be able to *detect* the violation.
>>
>> I'm baffled as to why the
>-Original Message-
>From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com]
On
>
>On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
>wrote:
>
>> Please read the rest of the email thread. The short summary is:
>> Yes, I know what *should* happen, but the world isn't perfe
On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
wrote:
> You're missing the point of what I'm asking. I'm not suggesting that
> maven make it possible or easy to *create* the violation. I'm
> suggesting that it should be able to *detect* the violation.
>
> I'm baffled as to why the maven com
>-Original Message-
>From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org]
>
>Eric, you're not going to win this one. It's part of the philosophy of
>Maven. It's also good practice.
>
>Give it up.
>
>I'm not going to fight the site generation being split out of Maven. I
>think I under
I second this! I've used Artifactory and liked it. (I somewhat prefer Nexus, at
least the last time I looked at Artifactory.)
-K
On Aug 6, 2010, at 1:47 PM, Yoav Landman wrote:
> You may want to take a look at the CI integration in Artifactory -
> http://wiki.jfrog.org/confluence/display/RTF/Bu
You may want to take a look at the CI integration in Artifactory -
http://wiki.jfrog.org/confluence/display/RTF/Build+Integration
You can get a json object with a report of all this information captured at
build time: detailed build environment information, published artifacts and
resolved dependen
On Aug 6, 2010, at 1:00 PM, Haszlakiewicz, Eric wrote:
>> -Original Message-
>> From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com]
>>
>> On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric
>> wrote:
-Original Message-
>>> I don't (yet) know much about the internals of
On Aug 6, 2010, at 12:57 PM, Kalle Korhonen wrote:
> On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric
> wrote:
>>> -Original Message-
>> I don't (yet) know much about the internals of maven, but is it really
>> that much of an impact on the code? There's already support present for
>
>>-Original Message-
>>From: Manfred Moser [mailto:manf...@mosabuam.com]
>>
>>It seems like we will not agree here. The changes necessary and the
>>additional overhead to make your suggestions work have to much of a
>>negative impact imho. I cant see your feature getting implemented by
>>an
On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
wrote:
> Please read the rest of the email thread. The short summary is:
> Yes, I know what *should* happen, but the world isn't perfect and release
> artifacts DO sometimes change. It is not absurd to be able to detect and
> recover from that
>-Original Message-
>From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com]
>
>On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric
> wrote:
>>>-Original Message-
>> I don't (yet) know much about the internals of maven, but is it really
>> that much of an impact on the code? Ther
On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric
wrote:
>>-Original Message-
> I don't (yet) know much about the internals of maven, but is it really
> that much of an impact on the code? There's already support present for
> checking for differences in snapshot versions, right? I'm
>-Original Message-
>From: Manfred Moser [mailto:manf...@mosabuam.com]
>
>It seems like we will not agree here. The changes necessary and the
>additional overhead to make your suggestions work have to much of a
>negative impact imho. I cant see your feature getting implemented by
>anybody.
> The network traffic that that would cause in a modern project with dozens of
> dependencies would create a real nuisance.
If every artifact had md5 and sha1 hashes etc, then the traffic would
merely be to check the hashes against the local artifact... which
Maven already does, and complains when
On 05/08/2010 1:13 PM, Manfred Moser wrote:
Eric,
It seems like we will not agree here. The changes necessary and the
additional overhead to make your suggestions work have to much of a
negative impact imho. I cant see your feature getting implemented by
anybody. Your only option is to implemen
On 05/08/2010 1:00 PM, Haszlakiewicz, Eric wrote:
-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
On 04/08/2010 6:3
Eric,
It seems like we will not agree here. The changes necessary and the
additional overhead to make your suggestions work have to much of a
negative impact imho. I cant see your feature getting implemented by
anybody. Your only option is to implement it yourself and see how you
fare. If you do i
>-Original Message-
>From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
>
> On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
>>> -Original Message-
>>> From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
>>>
>>> On 04/08/2010 6:34 PM, Manfred Moser wrote:
> For
On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
On 04/08/2010 6:34 PM, Manfred Moser wrote:
For everyone that says "Released artifacts MUST NOT CHANGE", that
great
if you live in an ideal world, but gue
>-Original Message-
>From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
>
> On 04/08/2010 6:34 PM, Manfred Moser wrote:
>>> For everyone that says "Released artifacts MUST NOT CHANGE", that
great
>>> if you live in an ideal world, but guess what: some of us actually
have
>>> to live
On 04/08/2010 6:34 PM, Manfred Moser wrote:
For everyone that says "Released artifacts MUST NOT CHANGE", that great
if you live in an ideal world, but guess what: some of us actually have
to live in the *real* world where things don't always follow the
guidelines. It would be nice if maven didn
> For everyone that says "Released artifacts MUST NOT CHANGE", that great
> if you live in an ideal world, but guess what: some of us actually have
> to live in the *real* world where things don't always follow the
> guidelines. It would be nice if maven didn't make it so hard to deal
> with those
>-Original Message-
>From: a.geo [mailto:aquiles@gmail.com]
>Sent: Monday, August 02, 2010 9:54 AM
>To: Maven Users List
>Subject: Re: force maven to redownload/refresh "released" dependencies
>
>mvn package -U
>
>maybe?
>
>the -U paramete
On 02/08/2010 11:00 AM, Nicola Musatti wrote:
Shan Syed wrote:
ok, thanks
basically for liability reasons for a certain project, we have to
provide
specific times of when a project was built and when/where all its
dependencies were retrieved at/from
we have to ensure a sanitary build for all
Shan Syed wrote:
no, this isn't in regard to our own published artifacts
I regret starting this thread, I apologize
I didn't mean this question to be an affront to maven conventions - I just
need to figure out a better way to capture a full log
they even want a log of how the build environment w
Shan Syed wrote:
ok, thanks
basically for liability reasons for a certain project, we have to provide
specific times of when a project was built and when/where all its
dependencies were retrieved at/from
we have to ensure a sanitary build for all these JARs and a complete log of
going from 0 to 1
mvn package -U
maybe?
the -U parameter tell to maven to refresh all dependencies required by the
artifact
2010/8/2 Arnaud Héritier
> I see only one case where it could be useful, it is when we use staging
> repositories and have to update our released binaries.
> It is a shame to have to manua
I see only one case where it could be useful, it is when we use staging
repositories and have to update our released binaries.
It is a shame to have to manually remove binaries previously downloaded (and it
is error prone).
I agree that never updating released binaries is a maven fundamental and
On 30/07/2010 5:09 PM, Paul Benedict wrote:
You can use -X for a debug log. Or you can funnel system out to a file. I
believe tools like Continuum or Hudson do such things.
Paul
On Fri, Jul 30, 2010 at 4:07 PM, Shan Syed wrote:
no, this isn't in regard to our own published artifacts
I regr
You can use -X for a debug log. Or you can funnel system out to a file. I
believe tools like Continuum or Hudson do such things.
Paul
On Fri, Jul 30, 2010 at 4:07 PM, Shan Syed wrote:
> no, this isn't in regard to our own published artifacts
>
> I regret starting this thread, I apologize
> I di
no, this isn't in regard to our own published artifacts
I regret starting this thread, I apologize
I didn't mean this question to be an affront to maven conventions - I just
need to figure out a better way to capture a full log
they even want a log of how the build environment was downloaded and
i
There is a maxim to follow when deploying: "do not redeploy a version more
than once". Once you deploy version X.Y.Z, it should never be updated, and
those who download it never need to download it again. So, back to the
original problem, are you guys doing that?
On Fri, Jul 30, 2010 at 3:57 PM, S
it only applies to our final release cuts, not our day-to-day
just once for this project really; I wanted to insert such this switch (if
existed) in our "delivery build" profile
we use archiva for everything else, and actually only make use of public
maven repositories when we up a version of our d
>> deleting the m2 works, I was just curious to see if there was a switch in
>> maven to force all downloads again
>
> This makes absolutely no sense, doesn't change your BOM, and is just
> wasteful. Consumes bandwidth unnecessarily from a resource that is being
> used by the whole Maven community.
On Jul 30, 2010, at 3:45 PM, Shan Syed wrote:
> not my organization - our client wants a log of everything that came down
> the pipe to create this build, that's all
> it's not a matter of "worry" or "concern", so no need to be overly dramatic
> some companies just want a complete audit trail of
not my organization - our client wants a log of everything that came down
the pipe to create this build, that's all
it's not a matter of "worry" or "concern", so no need to be overly dramatic
some companies just want a complete audit trail of what they paid for, which
is fine by me
I'm looking for
You could try changing the repository location property on the command line to
a fresh empty directory. That will force the download and logging of all
SNAPSHOT and release dependencies.
>mvn ... -Dmaven.repo.local=
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional
On Jul 30, 2010, at 2:21 PM, Shan Syed wrote:
> ok, thanks
> basically for liability reasons for a certain project, we have to provide
> specific times of when a project was built and when/where all its
> dependencies were retrieved at/from
> we have to ensure a sanitary build for all these JARs
Wouldn't you be better off implementing such mechanism in an SCM package?
Audit can be done with scripts either sitting on top of SCM or Unix/Linux
machine.
Added logging layer from hosting it on Linux/Unix would benefit you far more
and provide better flexibility.
Hope it helps,
Dave
On Fri, Ju
On 30/07/2010 12:57 PM, Manos Batsis wrote:
On 07/30/2010 07:16 PM, Wayne Fay wrote:
is there a way to force a project to refresh certain dependencies every
build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
Absolutely not. Released artifacts MUST NOT CHANGE.
+1, never ever
Replacing a SNAPSHOT with a non-SNAPSHOT version is equivalent to upgrading.
Jason is right in that this should never be automatically done by Maven.
Maven cannot guess or determine when you are ready to give up SNAPSHOT
versions.
However, perhaps you need an external batch process that discovers
ok, thanks
basically for liability reasons for a certain project, we have to provide
specific times of when a project was built and when/where all its
dependencies were retrieved at/from
we have to ensure a sanitary build for all these JARs and a complete log of
going from 0 to 100 for the build; s
On 07/30/2010 07:16 PM, Wayne Fay wrote:
is there a way to force a project to refresh certain dependencies every
build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
Absolutely not. Released artifacts MUST NOT CHANGE.
+1, never ever ;-)
Released artifact versioning is supposed
I was actually under the impression you could do this like this:
always
Although I've never tried this because it's a terrible idea.
If this doesn't work, someone should probably remove the corresponding
section from http://maven.apache.org/settings.html#Repositories and
http://maven
Shan,
Maven has a policy how often it checks for updated snapshots. Is that what
you are looking for?
Paul
On Fri, Jul 30, 2010 at 11:39 AM, Jason van Zyl wrote:
> Maven won't do that, and we would never make that possible. If you require
> this you have something seriously wrong with your pro
Maven won't do that, and we would never make that possible. If you require this
you have something seriously wrong with your project infrastructure. Seriously
bad project infrastructure smell.
On Jul 30, 2010, at 12:01 PM, Shan Syed wrote:
> is there a way to force a project to refresh certain
> is there a way to force a project to refresh certain dependencies every
> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
Absolutely not. Released artifacts MUST NOT CHANGE.
Wayne
-
To unsubscribe, e-mail: u
69 matches
Mail list logo
