Le vendredi 29 juillet 2011, Mark Struberg a écrit :
Is it as simple as that for all SCMs?
Yes it is.
Remember the old days: this is only a fix for a 'fix'. Originally the SCM
URLs haven't been changed for child modules. This 'feature' only got
introduce later to make life easier for SVN
+1
Regards,
Hervé
Le jeudi 28 juillet 2011, Brett Porter a écrit :
On 28/07/2011, at 10:32 PM, Jason van Zyl wrote:
On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote:
mom jason.
Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which
exists in lots of DSCMs. Will do
+1
-Lukas
On 07/28/2011 04:56 PM, Stephen Connolly wrote:
Hi,
This is a patch release to fix a particularly nasty regression:
http://jira.codehaus.org/browse/MRELEASE-697
We solved 3 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=17502
You could just try with checkstyle 5.3.
there is the ability to override the dependencies of a plugin
project
build
plugins
plugin
artifactIdmaven-checkstyle-plugin/artifactId
dependencies
... insert the newer version of checkstyle (not the plugin) here
/dependencies
/plugin
/plugins
/build
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
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 solution
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
How about coming at this from a different track...
scmscm:parent:/path/in/parent/scm
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
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
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 anything
On 29 July 2011 12:35, Benson Margulies bimargul...@gmail.com 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
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 bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
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
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't
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
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
I think Herve said so.
On Jul 29, 2011, at 10:50 AM, John Casey jdca...@commonjava.org 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
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
-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
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 rfscho...@codehaus.org wrote:
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
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 jesse.mcconn...@gmail.com wrote:
From: Jesse McConnell
+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
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 the
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
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 rather do
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
Mark-
..do you have snapshots enabled false for your repository..e.g
repositories
repository
snapshots
enabledfalse/enabled
/snapshots
/repository
/repositories
Liebe GruBe
Martin
__
Verzicht und Vertraulichkeitanmerkung
Diese Nachricht
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.
29 matches
Mail list logo
