yes, I tried too and couldn't find (then chose to continue on m-site-p...), but
your conclusion is really plausible
I tried on every CI failures, fixed what I could fix, but actual failures are
really hard to fix (AFAIK, were the same on previous Sonatype's CI, then there
is really some logic i
I think I've seen a similar error come up on a few boxes of my own. I think it
has something to do with the "lastUpdated" terminator in your repository. I've
had some success removing this off of POMs that wouldn't download.
Alternatively, nuking the repository might help.
My two cents.
Andr
Mark-
..do you have snapshots enabled false for your repository..e.g
false
Liebe GruBe
Martin
__
Verzicht und Vertraulichkeitanmerkung
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten w
Hi!
Our CI is broken since a while and most of the errors are of the following kind:
[ERROR] Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT
or one of its dependencies could not be resolved: Failed to read artifact
descriptor for
org.apache.maven.plugins:maven-repositor
On 2011-07-30 00:13, Mark Struberg wrote:
> Hi Dennis!
>
> I think we could test this if we start a local jetty serving as a repo http
> server which only provides one dummy artifact. Then we need to startup a
> proxy and point maven to this proxy.
>
> Sounds like a bit more work, and I'd rathe
Hi Dennis!
I think we could test this if we start a local jetty serving as a repo http
server which only provides one dummy artifact. Then we need to startup a proxy
and point maven to this proxy.
Sounds like a bit more work, and I'd rather do that in an integration test and
not via a unit tes
Hi Mark
I spent a couple of hours debugging this earlier this week.
Unfortunately I wasn't able to crack it. But I find your conclusion very
plausible.
On 2011-07-29 16:22, Mark Struberg wrote:
> Hi!
>
> This is a sum-up of my last 5 hours of debugging.
>
> Currently there is a failing test in
+0
I think the license issue is a false problem as it is mixed with an IP issue
and in any case we'll don't get back this code inside Maven land as its
authors don't want.
The issue to control this part of code is legitimate but the only solution
is to rewrite it from scratch (again)
cheers
Arnau
Jesse, there is no private problem involved. The problem is solely that the
Maven project just cannot decide itself what it is going to fix and how it will
implement features that way.
LieGrue,
strub
--- On Fri, 7/29/11, Jesse McConnell wrote:
> From: Jesse McConnell
> Subject: Re: [VOTE] In
I know I stepped away from maven quite some time ago, jetty and other
things just don't allow the time...but I have followed this discussion
and I'll toss in my two cents.
I would be +1 on this and would come to the defense of jason and
sonatype on this because no matter what you want to argue abo
Heh Robert, thanks for sharing ;)
I actually was not 100% sure, so it took me a bit time to really understand
what this thing might be supposed to do. And that it was actually only working
by accident so far.
LieGrue,
strub
--- On Fri, 7/29/11, Robert Scholte wrote:
> From: Robert Scholte
>
-0
I don't like it, but I'm not the one doing the work. I'd accept it if there's
no better way to get the problems fixed for whoever is working to fix them. I
don't think it's good to get stuck on an old version no one is maintaining. I'm
happy to discuss ideas for alternatives.
However, I wou
I discovered the same issue. The problem didn't show itself with a dirty
target-folder, but after a "mvn clean test" it was easy to reproduce.I noticed
the test had to do with the proxy, couldn't figure out how this test should
work. Now I know: it doesn't. -Robert > Date: Fri, 29 Jul 2011 15:2
I think Herve said so.
On Jul 29, 2011, at 10:50 AM, John Casey wrote:
>
>
> On 7/29/11 7:45 AM, Benson Margulies wrote:
>> thereof? Does anyone hate it?
>>>
>>> I'm just a bit behind on mail, but need a clarification - in Maven the XSD
>>> is an end result of the model that is generated, but y
On 7/29/11 7:45 AM, Benson Margulies wrote:
thereof? Does anyone hate it?
I'm just a bit behind on mail, but need a clarification - in Maven the XSD is
an end result of the model that is generated, but you seem to describe it here
as an input. Am I misreading?
I've been assuming that the
Hi!
This is a sum-up of my last 5 hours of debugging.
Currently there is a failing test in the maven-javadoc-plugin:
JavadocReportTest#testProxy()
This test fails since the last commit but I actually think it only ever worked
by accident. It did rely on a commons-logging-1.0.4.pom which got re
thereof? Does anyone hate it?
>
> I'm just a bit behind on mail, but need a clarification - in Maven the XSD is
> an end result of the model that is generated, but you seem to describe it
> here as an input. Am I misreading?
I've been assuming that the XSD file is a manual production, but I
didn
A few more 'schematic' notes.
1) AFAIKT, the schema isn't really part of the maven core. Nothing in
maven core ever looks at it. The ancient pull parser in plexus
wouldn't know a schema if one fell on it from a height.
2) We could publish a 4.0.1 schema tomorrow on the web site (does it
need a re
We of course also should think one step further and also make a check how we
proceed from XSD-4.0.1 to 4.0.2
LieGrue,
strub
--- On Fri, 7/29/11, Benson Margulies wrote:
> From: Benson Margulies
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List"
> Date: F
On 29 July 2011 12:35, Benson Margulies wrote:
> I'm in favor of the policy (since I suggested it), that maven 3.0.X
I think that requires at least a minor bump I would not be happy with
classing those as a patch bump
> can deliver pom XSD 4.0.Y, where the changes the the XSD are proven to
> be
On 29/07/2011, at 9:35 PM, Benson Margulies wrote:
> I'm in favor of the policy (since I suggested it), that maven 3.0.X
> can deliver pom XSD 4.0.Y, where the changes the the XSD are proven to
> be harmless to popular old versions and common sense characterizes
> them as unlikely to blow anythin
I'm in favor of the policy (since I suggested it), that maven 3.0.X
can deliver pom XSD 4.0.Y, where the changes the the XSD are proven to
be harmless to popular old versions and common sense characterizes
them as unlikely to blow anything up. I submit that adding some
inheritance control attribute
How about coming at this from a different track...
scm:parent:/path/in/parent
that is an SCM that is the same as parent with a path in the parent.
the parent scm provider would look up the parent's scm and could use
some rules to derive the effective path, acting like a delegate and
giving us th
gnah sorry :(
I explicitly tested the schema validation, but obviously using a new tool (I'm
new to macs...) at 3 o clock in the morning isn't producing reliable results :/
But your idea with the XSD-4.0.1 sound really great. Almost too good to
believe!
That would probably allow us to implement
Hi,
here's a use case/convention which neither the current "append child's
artifactId" strategy nor the "static:" prefix can handle.
The parent project uses something like
/scm-root/
and the modules/children use
/scm-root/modules/${project.artifactId}
IMHO, the only fully flexible solut
Hi Hervé!
Txs for the input!
> this would be project.scm.autoModule?
dont think that properties would work in this case. They are also only fully
evaluated after the model is already built, isn't? Thats a tad to late I fear.
But I'm happy to be proven wrong if you find time to test the behaviou
You could just try with checkstyle 5.3.
there is the ability to override the dependencies of a plugin
maven-checkstyle-plugin
... insert the newer version of checkstyle (not the plugin) here
If the only change is a version bumb, then you can achieve that by
overriding with a bumped v
27 matches
Mail list logo
