> We are also working on Maven 4, so today the plugin should be possible to
> > use with the next Maven major version.
> > As I remember nexus-staging-plugin can not be used with Maven 4.
> > Can a new plugin be used with Maven 4?
> >
> >
> > śr., 1 maj 2024 o
Hey all. Thanks Romain for pointing out the thread for me.
One issue is that Central publishers is a much larger set of folks than the
Maven Dev group. Obviously there's lots of overlap, but as Romain said,
creating a plugin is a thing that can be done independently.
As we've been working towards
th 3.x.x.
> > Elliotte gave a good reason for this: There are two camps now (read:
> > ALREADY).
> > There is no reason to not go with either of them.
> >
> > Am Do., 22. Feb. 2024 um 19:56 Uhr schrieb Brian Fox >:
> > >
> > > We dumped 30 days b
:
> > >
> > > > Howdy,
> > > >
> > > > Maven UA is created like this:
> > > >
> > > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessio
Hi everyone. I haven't caught up on this thread but Tamas pinged me to get
some usage data from Central. Attached are the Maven versions and JDK
Version counts as reported by User Agent by distinct IP for the last 30
days:
On Wed, Feb 21, 2024 at 4:15 PM Hunter C Payne
wrote:
> I also want
Hi Sebastian,
The challenge is that CPE as a coordinate system doesn’t have enough
specificity to match artifacts. It has organization/product/version and
therefore doesn’t have the ability to capture sub module. This is what
leads to most of the mismatch issues seen in CVE based tools (but not al
Apache Maven may follow repositories that are defined in a
dependency’s Project Object Model (pom) which may be surprising to
some users, resulting in potential risk if a malicious actor takes
over that repository or is able to insert themselves into a position
to pretend to be that repository. Mav
I'm +1. If the worst thing we can find to worry about is the version
number 3.7, 3.8, then it seems like we're close enough.
On Wed, Mar 24, 2021 at 3:11 AM Romain Manni-Bucau
wrote:
>
> +0 cause of the versioning which is unexpected (but you know what? since it
> is a git tag we can drop it and
The CVE is for documentation and the hardening of default behavior,
it's not your typical zero day.
On Mon, Mar 22, 2021 at 10:53 PM Gary Gregory wrote:
>
> You are acknowledging a CVE _before_ a release?
>
> Gary
>
>
> On Mon, Mar 22, 2021, 15:40 Robert Scholte wrote:
>
> > Hi,
> >
> > For the
y to maintain some oss stuff.
> Moreover, I initially thought that OSSRH timeout was not 'just' a Sonatype
> issue even if Sonatype is the operator of central & OSSRH (and I thank you
> for that). I saw it as a community problem and thus I just wanted to have
> some feedback
Hi Matthieu, I think continuing the conversation on your existing
ossrh ticket is the right place to resolve this. While it seems like
you're having recurring issues, it's not occurring across the entire
system so we need to figure out what the unique issue is.
--Brian
Cofounder & CTO Sonatype
On
l with #2
>
> #2 can't be done w/o careful planning. That's clear.
> Who's the right contact at Sonatype? Brian Fox?
>
>
> > On 31-5-2020 16:58:58, Michael Osipov wrote:
> > Folks,
> >
> > I have been recently (indirectly) approached by Mark Thom
Last year, we deprecated old and insecure TLS protocols on Central to
make access more secure. This year, we're moving things forward again
by deprecating and later removing access to insecure by default HTTP
access.
Right now this affects less than 20% of the traffic hitting Central.
To find out
it along and we will include that as well.
https://central.sonatype.org/articles/2018/May/04/discontinue-support-for-tlsv11-and-below/
--Brian Fox
Apache Maven PMC
CTO, Sonatype
-
To unsubscribe, e-mail: dev-unsubscr
On Fri, Dec 1, 2017 at 3:19 AM, Andreas Sewe <
s...@st.informatik.tu-darmstadt.de> wrote:
> Olivier Lamy wrote:
> > probably no issues for sure.
> > I just don't know if we will be able to still download the index from
> > central and use it with this new version
> > TBH I haven't done any testing
Eyeballing the list, most of the changes seem irrelevant to the central use
case. Is there anything in here that matters for Central (and if so, what
are the backwards compat implications?)
On Thu, Nov 30, 2017 at 2:07 AM, Olivier Lamy wrote:
> +1
>
> I'm not clear if this new version will be us
All set.
On Sat, Oct 28, 2017 at 9:48 AM, Robert Scholte
wrote:
> Hi,
>
> I'd like to prepare an alpha release of the Maven JDeprScan Plugin
> It is a wrapper around the jdeprscan tool[1], available since Java 9.
>
> You use the jdeprscan tool as a static analysis tool that scans a jar
> file
2017 at 7:53 AM, Benedikt Ritter wrote:
> Hello Brain,
>
> > Am 26.09.2017 um 23:10 schrieb Brian Fox :
> >
> > On Mon, Sep 25, 2017 at 2:10 PM, Benedikt Ritter
> wrote:
> >
> >> Hello Brian,
> >>
> >>> Am 20.09.2017 um 23:16 schrieb Bria
On Mon, Sep 25, 2017 at 2:10 PM, Benedikt Ritter wrote:
> Hello Brian,
>
> > Am 20.09.2017 um 23:16 schrieb Brian Fox :
> >
> > It's been a really long time, but I recall that there were issues getting
> > the dependencies of plugins bound to the lifecycle. Th
It's been a really long time, but I recall that there were issues getting
the dependencies of plugins bound to the lifecycle. This looks to be the
same problem. I think the documentation talked about a way to do this
effectively.
On Wed, Sep 20, 2017 at 4:48 PM, Benedikt Ritter wrote:
> Hi,
>
>
Cool. I'll be there as well.
On Sat, Jul 29, 2017 at 5:58 AM, Robert Scholte
wrote:
> Hi,
>
> Both my talk and the BOF have been accepted for JavaOne 2017.
> I will host the BOF session together with Manfred Moser.
> All are invited to join.
>
>
> thanks,
> Robert
>
> ---
I'm getting index out of bounds exceptions with 3.5 that don't occur with
3.3.9. I haven't debugged it yet, but wondering if this is already known?
Fwiw reproducible with the DependencyCheck 2.0-snapshot master.
[ERROR] 13978
java.lang.ArrayIndexOutOfBoundsException: 13978
at org.codehaus.plexus
Even more than redefining what Central does, you're effectively describing
a new, unofficial java class packaging and distribution mechanism. This
seems like it will violate signatures etc and make tracking of what you
actually have a nightmare.
On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY
wrot
Robert and I wrote a bit previously [1] about the issues with the
automodules in jigsaw (hint: they use only the filename to default a module
which we've demonstrated is a terrible idea). There was a happy medium
which would have allowed library developers to select a name before full
modularizatio
in the future. Maybe it would be good if all Apache project and
> others
> > that are going to publish modules start with using the full namespace in
> > the module name. Problem is of course that the examples I saw so far all
> do
> > NOT do that so we will end up with a mes
ild up the right practices before jigsaw takes off.
>
> --
> Regards,
> Igor
>
> On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
> > I generally agree the concerns were mostly ignored. Specifically the
> > dangers in not carefully approaching and setting best practices
ise
> > Date: Thu, 16 Feb 2017 17:48:27 +0100
> >
> > This note is in reply to the concerns about automatic modules raised by
> > Robert Scholte and Brian Fox [1], and by Stephen Colebourne and others
> > [2]. I've collected my conclusions here rather than in
I looked a little closer, the servers are up and your key 843ddb767188601c
is not there. Make sure you've published your key to the pgp servers and
that you can search it from here: http://pool.sks-keyservers.net:11371/
On Thu, May 26, 2016 at 6:15 PM, Brian Fox wrote:
> When this happe
When this happens, it's a failure in the pgp key server ring and despite
the fact that the ring is meant to distribute load, they all seem to go
down at the same time. There isn't actually anything we can do on the rao
side to make this work besides drop the staging rule that checks the key. I
thin
Added simpligility to maven-dev
On Wed, Jun 24, 2015 at 12:38 AM, Barrie Treloar wrote:
> I've pinged Brian to have a look.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@mav
+1
--mobile
> On May 13, 2015, at 2:55 AM, Hervé BOUTEMY wrote:
>
> Hi,
>
> I'd like to introduce Manfred Moser as committer for the Apache Maven
> project.
>
> He's working on Android Maven plugin for years, has great discussions both on
> users and dev MLs, has a great attitude.
> And he
d.
>
> The POMs for plexus currently points to OSSRH. Can anyone who has done
> a release of a plexus component lately shed some light on where they
> go? Either nexus.codehaus.org och OSSRH.
>
>
> On Tue, Mar 10, 2015 at 6:28 PM, Brian Fox wrote:
>> The current plan is t
The current plan is to continue running nexus.codehaus.org and then
move stuff over to ossrh as needed. The ssl cert was just renewed and
Bob said the DNS isn't going away immediately. We figure projects have
enough other stuff to scurry around changing, Nexus doesn't have to be
part of it at the s
On Sat, Mar 7, 2015 at 10:04 AM, Robert Scholte wrote:
> Mercury? I guess some of it is now part of Aether,
Mercury predates Aether. It was an attempt to update the artifact apis
that was abandoned. (Unless the name is being reused as something new)
--
+1
On Thu, Mar 5, 2015 at 8:16 AM, Igor Fedorenko wrote:
> This is chicken-and-egg situation. We won't use java 7 features unless
> the code targets java 7.
>
> Try-with-resources and multi-exception catch are the too features I'd
> like to start using throughout the code. Although not "critical"
+1 close em...
On Tue, Nov 25, 2014 at 4:22 PM, Jason van Zyl wrote:
> I don't agree. This is a project, not a product and if no one looks at
> something for 2 years then no one cares. We are not erasing the issues and if
> someone does care enough to ask to reopen an issue then that's great. B
Herve and I discussed moving the repos before splitting them, but it
made sense to just go ahead and split it first because that was easier
and quicker to pull off. If we can get them into an Apache repo, that
makes sense.
On Tue, Sep 2, 2014 at 3:48 AM, Benson Margulies wrote:
> Note that we rec
+1
I did a few tests of various cases related to the new url for central
and interactions with repo managers, everything looks ok.
On Mon, Aug 11, 2014 at 5:24 PM, Jason van Zyl wrote:
> +1
>
> Analyzer...
>
> stagingUrl: https://repository.apache.org/content/repositories/maven-1046
> groupId: o
nd defaulting it later on? I think I'd be down
>> for just switching cold turkey.
>>
>> On 11 Aug 2014, at 13:28, Brian Fox wrote:
>>
>>> https://repo.maven.apache.org is up now so we can flip to ssl when
>>> ready. Is the consensus to get this into 3.2.3 or
https://repo.maven.apache.org is up now so we can flip to ssl when
ready. Is the consensus to get this into 3.2.3 or to wait for more
time to test?
We may want to consider switching the repository.apache.org url in our
poms as well.
Hi Herve, this is all set. I didn't split any code but the new repos
are available and added to the plexus team in github.
We should have a discussion on where the proper hosting location for
this really is. If we want to move this to the maven project, I would
support that.
On Fri, Aug 1, 2014 a
We are already in the process of making this open for free to
everyone. Way back in 2012 the CDN situation was different but we just
renewed the contract and and ssl is part of it. Once this is setup, we
should consider changing the superpom to use ssl by default.
Obviously doing something to vali
n 2014-06-18, 9:13, Jason van Zyl wrote:
>>
>> Two times during the one hour window that I was trying to release that the
>> service was not available. It was an Apache page but I assume Nexus wasn't
>> running behind it or not responding.
>>
>> On Jun 18, 20
https://issues.apache.org/jira/browse/INFRA-7915
On Wed, Jun 18, 2014 at 9:01 AM, Arnaud Héritier wrote:
> When I noticed it was down on my side it was 503 errors
>
>
> On Wed, Jun 18, 2014 at 2:57 PM, Brian Fox wrote:
>
>> I haven't received any alerts that it'
I haven't received any alerts that it's been down although there are
sporadic reports of timeouts. Did you receive a timeout, 502 or
something else?
Nexus is on shared vm hosts and shared disks and I suspect that some
other guest is occasionally bursting and screwing up the io
throughput.
On Tue,
On Fri, Apr 11, 2014 at 5:50 PM, Benson Margulies wrote:
> On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
> wrote:
> > On 11 April 2014 22:10, Benson Margulies wrote:
> >
> >> >
> >> > Fwiw, I don't recall the dependency plugin actually injecting stuff
> into
> >> > the project class path but
> My proposal is strictly to prohibit a plugin from modifying a project's
> classpath implicitly. That this become fully explicit such that I can
> remove some of the convoluted logic in the core to account for this.
>
>
Not allowing plugins to randomly inject new dependencies makes sense. I see
so
On Sat, Nov 23, 2013 at 11:47 PM, Igor Fedorenko wrote:
> The way I see it, what is deployed describes how the artifact needs to
> be consumed. This is artifact's "public API", if you will, it will be
> consumed by wide range of tools that resolve dependencies from Maven
> repositories and descrip
Hi Laurent, this does look like an handy plugin. I could actually
imagine these goals being added to the existing clean plugin and also
think this could be pretty popular. What do others think?
On Wed, Aug 7, 2013 at 2:39 AM, labtech.dev wrote:
> Hi there,
>
> Please first excuse my poor english.
rds making it "official"
>
> Everyone else,
>
> Time to shout out if you have any issues / suggested improvements on the
> content
>
> - Stephen
>
> On Friday, 2 August 2013, Stephen Connolly wrote:
>
>> On 2 August 2013 16:07, Brian Fox > 'cvml',
On Aug 2, 2013, at 12:30 PM, Paul Benedict wrote:
> I've stated from the beginning of this thread that it's impossible to
> prevent someone from developing outside of Apache. I stand by that still.
> That can't be prevented and any attempt will fail since it's not practical.
>
> If my words today
On Fri, Aug 2, 2013 at 12:10 PM, Stephen Connolly
wrote:
> So anyway, I now have this ultra whizzbang high performance logging API and
> I am aware of some deficit in the logging performance of Maven, so I spin
> up a private fork (it could be a hidden private fork, or it could be a
> public one..
I think the bulk of this is pretty good. On the fork section, specifically:
"
As soon as changes in that
fork are identified which should be brought back to the project those
changes should be introduced into at least a branch hosted on the Apache Maven
source control in order to facilitate the ea
>
> There is at least one Maven Committer who has been maintaining a fork of
> Maven for perhaps the greater part of a year.
Is it really a fork? Or is it a superset? I think people throw around
fork but is that really true?
-
To
Chris, we can add this right to the apache nexus and it will be synced
to Central. No need to do a one-off upload. Do you have a list of the
exact files that are missing?
On Thu, Jul 11, 2013 at 1:57 AM, Chris Graham wrote:
> ok, cool. I will go and have a look. Thanks!
>
> -Chris
>
>
> On Thu,
You mean releases that don't go to the standard release repo? Yes it's
technically possible but it becomes a dangerous thin line between
official release and one that bypasses the usual asf process.
--mobile
On Jun 22, 2013, at 8:07 PM, sebb wrote:
> On 23 June 2013 01:00, Olivier Lamy wrote:
+1
On Sat, Jun 1, 2013 at 9:13 AM, Jason van Zyl wrote:
> Here are the release bits for 3.1.0-alpha-1:
>
> Release notes:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-046/
>
> S
Yes that should do it.
On Fri, May 3, 2013 at 3:20 AM, Mirko Friedenhagen
wrote:
> Hello Hervé,
>
> as an enduser, I just define this as a dependency to e.g. the
> maven-dependency-plugin, right?
>
> Regards Mirko
> --
> Sent from my mobile
> On May 3, 2013 2:04 AM, "Hervé BOUTEMY" wrote:
>
>>
+1
On Mon, Mar 11, 2013 at 1:04 PM, Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:
> +1 to release.
>
> Thanks,
> Henning
>
>
>
>
> On Mon, Mar 11, 2013 at 9:44 AM, John Casey
> wrote:
>
> > Bump...
> >
> > Has this vote failed, then, or are we saying that all the +1's from the
I don't think we should move to 4.0 because of this. The primary consumer
of our systems are the end users and this change doesn't represent "api"
breakage to them. If we make what appears to be such a large version
change, that could scare off or confuse people who are just now warming up
to 3.x.
ot have this property
> and did set permissions, so the new default is a backwards incompatible
> change. Also this new property is not documented in the release notes:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18926&styleName=Text&projectId=11214
>
> -dai
discussion following this message was related to a
> different issue, unless I'm missing something in the issue details...
>
> What do we need to do to move forward with another vote?
>
>
> On 3/6/13 3:22 PM, Brian Fox wrote:
>
>> -1 based on dain's discovery on permi
I don't know for sure this field fixed the original issue. If it does,
the go ahead and close it
--mobile
On Mar 6, 2013, at 5:37 PM, Olivier Lamy wrote:
> 2013/3/6 Brian Fox :
>> MDEP-391 introduced this problem, just committed a fix for it.
> why not closing the issue ?
MDEP-391 introduced this problem, just committed a fix for it.
On Wed, Mar 6, 2013 at 4:22 PM, Brian Fox wrote:
> -1 based on dain's discovery on permissions.
>
>
> On Wed, Mar 6, 2013 at 10:15 AM, Olivier Lamy wrote:
>
>> +1
>>
>> 2013/3/5 John Casey :
&
-1 based on dain's discovery on permissions.
On Wed, Mar 6, 2013 at 10:15 AM, Olivier Lamy wrote:
> +1
>
> 2013/3/5 John Casey :
> > Hi,
> >
> > This vote is for the Maven dependency plugin version 2.7, which also
> > requires the release of Maven shared dependency analyzer version 1.4.
> >
> >
+1
On Sun, Mar 3, 2013 at 5:34 AM, Hervé BOUTEMY wrote:
> +1
>
> Regards,
>
> Hervé
>
> Le samedi 2 mars 2013 07:18:51 Benson Margulies a écrit :
> > Based on the sentiment on the discussion thread, I call a formal vote
> > to end support for Maven 1.x. This is a vote to:
> >
> > 1: Remove mave
On Wed, Feb 27, 2013 at 10:56 AM, Benson Margulies wrote:
> If someone else
> wants to support it, they are welcome to do so elsewhere.
>
Or here through active participation. But while we don't have active
committers supporting it, we should say so. Nothing stops us from doing
more than the offi
+1 and take if off the dist site.
On Wed, Feb 27, 2013 at 10:42 AM, Benson Margulies wrote:
> Are there any readers on this list who are prepared to respond to any
> issues on Maven 1.x, especially, for example, security issues? Does
> anyone know how to make a release? Unless that set is non-em
Just wanted to bring this to the users list and ensure that those reading
the release notes see the security alert for 3.0.4:
CVE-2013-0253 Apache Maven
Severity: Medium
Vendor: The Apache Software Foundation
Versions Affected:
- Apache Maven 3.0.4
- Apache Maven Wagon 2.1, 2.2, 2.3
Descripti
epository to encourage not to
> use it.
>
> WDYT?
>
> Robert
>
>
> Op Tue, 05 Feb 2013 00:02:47 +0100 schreef Hervé BOUTEMY <
> herve.bout...@free.fr>:
>
>
> good idea
>>
>> any objection?
>>
>> Regards,
>>
>> Hervé
>&
i'm on the fence about if this is good or not, but I think the option if
provided should be simple-local-repository without the manager part. People
already get confused about what's a local repo vs what's a repository
manager and the mixing of these concepts here will make that worse.
On Sat, Fe
The enforcer plugin uses a static array to hold data between executions.
On Wed, Jan 30, 2013 at 2:15 PM, Aaron Dixon wrote:
> I am developing a plugin with "start" and "stop" goals to be executed
> typically in pre-integration-test and post-integration-test phases,
> respectively.
>
> For exam
+1
On Tue, Jan 1, 2013 at 6:42 AM, Anders Hammar wrote:
> +1
> I think we should keep the old left-hand menu, like what we've done over at
> Mojo.
>
> /Anders
>
>
> On Sat, Dec 29, 2012 at 5:09 PM, Jesse Farinacci wrote:
>
> > Greetings,
> >
> > On Fri, Dec 28, 2012 at 11:21 PM, Kristian Rosen
On Sun, Dec 23, 2012 at 10:26 AM, Henk P. Penning wrote:
> On Sun, 23 Dec 2012, Benson Margulies wrote:
>
> Date: Sun, 23 Dec 2012 15:26:18 +0100
>> From: Benson Margulies
>> To: Henk P. Penning
>> Cc: Maven Developers List ,
>> "infrastruct...@apache.org"
>>
>> Subject: Re: Getting Maven
Further to that, no one will ever consume maven plugins from a random dist
folder anyway, so a policy that requires this is a paper policy only and
would have no basis in the reality of how these particular projects are
consumed.
On Fri, Dec 21, 2012 at 1:18 PM, Brian Fox wrote:
> The l
The last discussion of this required the production of proper source
bundles for voting, which we created at that time. I don't recall there
being any requirement that everything go onto dist.
On Fri, Dec 21, 2012 at 10:57 AM, Benson Margulies wrote:
> Dear fellow community members,
>
> The curr
Great summary Benson, I agree with your assessments here.
On Sun, Dec 16, 2012 at 12:16 PM, Benson Margulies wrote:
> Since not much has been heard on the 'pick a logger' question for some
> time, I'm going to stick my neck out and try to summarize some
> aspects, in the hopes of discovering how
On Tue, Dec 11, 2012 at 5:07 PM, Benson Margulies wrote:
>
> If we ever got that far, I would argue pretty strenuously against a
> PMC-level rejection of something just based on being EPL. A class-B
> license is a perfectly legitimate dependency.
As would I. If we were talking about binding our
Didn't it used to be that way? (separate)
On Tue, Nov 27, 2012 at 4:09 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> On 27 November 2012 08:41, Olivier Lamy wrote:
>
> > 2012/11/27 Brett Porter :
> > >
> > > On 27/11/2012, at 10:34 AM, Arnaud Héritier
> wrote:
> > >
> > >> O
+1
On Tue, Nov 20, 2012 at 2:15 PM, Tamás Cservenák wrote:
> Hi,
>
> we'd like to release Maven Indexer 5.1.0.
>
> We fixed 7 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112&version=18972
>
> Staging repository:
> https://repository.apache.org/content/repositories/ma
I'm +1
On Tue, Sep 11, 2012 at 1:39 PM, Robert Scholte wrote:
> I don't think it's IF we should move to git, but WHEN and now seems to be
> the right time.
> +1
>
> Robert
>
> Op Tue, 11 Sep 2012 14:49:46 +0200 schreef Paul Gier :
>
>
> +1, and I'm willing to volunteer if you still need more peo
There are lots of tests that are trying to use file based repositories
for certain conditions. This is why in 2.0.9 I had added the
external:* :
external:* matches all repositories except those using localhost or
file based repositories. This is used in conjunction with a repository
manager when y
On Wed, Jul 25, 2012 at 4:19 PM, Brett Porter wrote:
> On 26/07/2012, at 3:46 AM, Brian Fox wrote:
>
> > On Tue, Jul 24, 2012 at 7:16 PM, Brett Porter wrote:
> >
> >>
> >> My understanding is that unfortunately Sonatype are not allowing anyone
> >>
On Tue, Jul 24, 2012 at 7:16 PM, Brett Porter wrote:
>
> My understanding is that unfortunately Sonatype are not allowing anyone
> else to mirror the content directly any more.
>
Ibiblio disabled the rsync on their own accord because it was thrashing
their disks.
Central is now on a CDN so para
Just over a year ago we evolved the Central architecture to be globally
load balanced with 2 servers in the US and 2 more in the UK. This year,
we've gone even futher to increase reliability and delivery performance.
We evaluated several options and ultimately settled with Edgecast as the
delivery
Niclas, I'm told it's working now. Can you confirm?
On Tue, Jul 10, 2012 at 1:11 PM, Brian Fox wrote:
> The network team confirmed that this is only Unicom with the issue. They
> are looking at alternate routes that would hopefully work.
>
>
> On Mon, Jul 9, 2012 a
for that service and don't have it.
>
>
> Cheers
> Niclas
>
> On Tue, Jul 10, 2012 at 1:58 AM, Brian Fox wrote:
> > Niclas,
> > We are seeing a lot of traffic to Central from China, so this certainly
> > isn't a case of the Great Firewall blocking ever
Niclas,
We are seeing a lot of traffic to Central from China, so this certainly
isn't a case of the Great Firewall blocking everything, rather it seems a
little more localized. Can you send more more info about your source ip and
geo location that we could use to see what's up? Possibly we can get
Has anyone considered making an rpm/deb bundle that essentially
contains a script which can fetch the associated tar.gz from the
apache site and unpack it?
It seems like this would be the best of both worlds. Hardly anything
ever changes in the package, people get easy access to "sudo apt get
inst
On Wed, Mar 21, 2012 at 4:35 AM, Sascha Scholz wrote:
> Hi,
>
> On Tue, Mar 20, 2012 at 11:28 PM, Olivier Lamy wrote:
>> BTW do we consider adding a warning in 3.0.5 if id != host and fail in 3.0.6
>> or fail directly in 3.0.5
>
> Why not deprecate the id entry then instead of forcing users to se
On Tue, Mar 20, 2012 at 6:28 PM, Olivier Lamy wrote:
> 2012/3/20 Brian Fox :
>> On Tue, Mar 20, 2012 at 5:07 PM, Olivier Lamy wrote:
>>> 2012/3/20 Brian Fox :
>>>> On Tue, Mar 20, 2012 at 12:58 PM, Olivier Lamy wrote:
>>>>
>>>>> Hell
On Tue, Mar 20, 2012 at 5:07 PM, Olivier Lamy wrote:
> 2012/3/20 Brian Fox :
>> On Tue, Mar 20, 2012 at 12:58 PM, Olivier Lamy wrote:
>>
>>> Hello Folks,
>>>
>>> The default preemptive on for GET is probably a bad idea.
>>> Im
On Tue, Mar 20, 2012 at 12:58 PM, Olivier Lamy wrote:
> Hello Folks,
>
> The default preemptive on for GET is probably a bad idea.
> Imagine the following case, in your settings you have:
>
>
> olamy
> reallycomplicatedpassword
> foo.org
>
>
> During dependencies resolution
The second one looks right to me, this is what I've always used as reference[1]
[1]
http://www.sonatype.com/people/2008/05/maven-code-how-to-detect-if-you-have-a-snapshot-version/
On Mon, Feb 27, 2012 at 6:41 PM, Robert Scholte
wrote:
> A couple of issues of the release-plugin have to do with S
>
> If Ant is their primary build tool, then I would suggest helping them
> set up Ant to use Maven Ant Tasks as a starting point. That is a great
> way of enabling an Ant build to deploy the artifacts into a Maven-style
> repository.
>
I would second that. In fact Ant/Ivy both already deploy to Ne
30 minutes is a high enough value that I think we'll be ok. Thanks Olivier.
On Tue, Dec 13, 2011 at 8:53 AM, Olivier Lamy wrote:
> 2011/12/13 Brett Porter :
>>
>> On 13/12/2011, at 7:38 PM, Olivier Lamy wrote:
>>
>>> Le 13 décembre 2011 09:35, Arnaud Héritier a écrit :
Olivier increased it
> Agree.
> I will add it in release and complete documentation here:
> http://maven.apache.org/guides/mini/guide-http-settings.html
This seems like a pretty big change and not enough people will read
that and start to freak out. If maven worked all this time with no
read timeout, why change it no
> Again I start a release process and produce a "candidate for release"
> build with a naming 3.0.4 for 5 days vote.
> Something failed, so it has been fixed and I restarted a vote with a
> second "candidate for release" called 3.0.4 for 5 days vote.
> (retagging etc )
>
> What is the differenc
On Sun, Dec 4, 2011 at 3:37 AM, Olivier Lamy wrote:
> Hello,
> The vote is cancelled due to the issue found by Dan.
>
> I will restart a vote when a fix will be available.
An RC candidate I hope...
>
>
>
> 2011/12/1 Olivier Lamy :
>> Hello,
>>
>> I'd like to release Apache Maven 3.0.4 (take 2).
The RCs were started for a very specific reason, to improve the
quality of our releases. Just breezing through this thread, there are
clearly issues with memory and some other stuff here that may be
bigger than we understand in this small testing surface. An RC build
will get more eyes and either c
1 - 100 of 670 matches
Mail list logo
