He's referring to downloads that state they are JARs when in fact the
file contains a blob of html. I've seen this a couple times.
Torsten, is it the error response in the file? What's the content
exactly?
Well, in this case the POM is actually ok ...but has the wrong checksum.
It's hard to bel
I'm not exactly sure what problem you are saying is happening here.
Well, two things are wrong
* the repository needs to be fixed
* maven should not use (and store) files with the wrong checksum
Known defects ...I just wanted check the state of affairs as I am
slowly drifting into the Sylvain
[INFO] [surefire:test]
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/surefire/surefire-providers/2.0/surefire-providers-2.0.pom
1K downloaded
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'0e7abda11e7aa94e3ba5ad1f1a052ebeb3d0f1a6'; remote =
'a68923172d8f1bb03d
Sorry, for the cross-post ...but it seems we need a dialog here
somehow. We now have two threads on two different mailing
lists/communities that really should talk to each other.
I propose to commit again all JARs into, say, cocoon/trunk/m2repo
and then tell Maven at build time to use that direc
FYI
-- Forwarded message --
From: Bertrand Delacretaz <[EMAIL PROTECTED]>
Date: Jun 30, 2006 5:58 PM
Subject: [RANT] This Maven thing is killing us
To: dev@cocoon.apache.org
Hi gang,
It's Friday, I'm tired and a bit depressed after losing about two more
hours unsuccessfully
Great, thanks :)
On 6/13/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
yep all apache was synced
On 6/12/06, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> Could you also sync
>
> http://www.apache.org/dist/maven-repository/org/apache/bcel/bcel/
>
> cheers
> --
&g
Could you also sync
http://www.apache.org/dist/maven-repository/org/apache/bcel/bcel/
cheers
--
Torsten
On 6/13/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
done
On 6/11/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> I've just deployed Lucene Core 1.9.1 and 2.0.0 to the ASF M2 repo:
>
> http
> ...why? Could you elaborate?
> I find the current behaviour counter-intuitive.
I think if you were building a jar that had , 9/10 people would
expect the modules to be included in some way.
Hm... the whole point of modules is to be modular - and not be part of the whole
thing. So of course it
multi-module
ok ...multi-module it is from now on :)
> I meant: why shouldn't also the parent pom have a src directory and
> generate a jar? I don't understand the concept of this distinction
> that forces me to have all my code in modules.
It would be counter-intuitive unless it were aggrega
On 5/17/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
tmatesoft JavaSVN is the problem, not SVN per se
http://tmate.org/svn/licensing/index.html
Ah, thought the previous post was referring to JavaSVN.
Maybe still worth talking to them.
Please join legal discussion if you want to discuss the l
Where is the license problem? With JavaSVN or SVN? According to
tigris.org, svn is using an apache compatible license.
Maybe they are not aware that it is not?
Maybe this can be resolved by talking to them ...so they might fix that.
cheers
--
Torsten
---
> First thought: Why "modules"? Everyone talks about
> "multi-projects" and "artifacts"
I try to avoid calling it multiproject for this reason.
So how do you call it then? ;)
> When I tried to build the (main) project I got told off that packaging
> was meant to be "pom" not "jar" ...ok - but
You can already do this with false.
Hm... I have
maven-project-info-reports-plugin
false
in the parent pom and still get the reports generated for the childs.
What am I missing?
Can you cite a use case where this would be useful for something other
than
On 5/6/06, Torsten Curdt <[EMAIL PROTECTED]> wrote:
On 5/6/06, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> > The technique in JXR and Javadoc is going to be similar to PMD and
> > taglist. Same for checkstyle too.
>
> Ok ...here is number one:
>
> htt
Check out the surefire project from
https://svn.apache.org/repos/asf/maven/surefire/trunk
and mvn install that.
ah ..so plugins are pretty much just wrappers around the
"real" surefire. Alright
Thanks, works now
--
Torsten
-
T
On 5/6/06, Brett Porter <[EMAIL PROTECTED]> wrote:
You seem to have an older snapshot of the surefire plugin 2.2 installed.
I'd either update, or remove it to go back to 2.1.3.
Nope ...latest trunk (from apache not mojo)
Rebuild and installed the surefire plugin and report-plugin just a few
sec
When I am trying to run the tests on maven-project-info-reports-plugin
in trunk I get:
Missing:
--
1) org.apache.maven.surefire:surefire-junit:jar:2.0-SNAPSHOT
What is that meant to be ...surefire-junit??
Where is it?
cheers
--
Torsten
--
Alright guys! You know I love maven - I harass you on IIRC often
enough. But let me give some ...let's call it "user feedback".
I have to say I am impressed how much documentation is actually
available on the website! And the book is awesome! Congrats!
Unfortunately both are missing out on multi-
[ http://jira.codehaus.org/browse/CONTINUUM-266?page=comments#action_44161
]
Torsten Curdt commented on CONTINUUM-266:
-
ups ...missed that. but if that's the case, a retry count would
make sense for the usual counting as well ...don't
[
http://jira.codehaus.org/browse/MAVENUPLOAD-474?page=comments#action_44116 ]
Torsten Curdt commented on MAVENUPLOAD-474:
---
...but IIUC it's already available for M2 and I am talking about M1.
According to your statement it should be removed
[
http://jira.codehaus.org/browse/MAVENUPLOAD-474?page=comments#action_44114 ]
Torsten Curdt commented on MAVENUPLOAD-474:
---
I used the same bundle.
Well, *ideally* they'd have a seperrate release for it.
..but I assume that will not happe
[ http://jira.codehaus.org/browse/CONTINUUM-266?page=comments#action_44108
]
Torsten Curdt commented on CONTINUUM-266:
-
Hm ...why? The user only cares about is his revision - not the
more or less internal counting of continuum.
Revision plus try
[
http://jira.codehaus.org/browse/MAVENUPLOAD-474?page=comments#action_44107 ]
Torsten Curdt commented on MAVENUPLOAD-474:
---
well ...we need it for maven1 projects
> new jdtcore version 3.1
> ---
>
> Key:
, sun jdk 1.4 (not important)
Reporter: Torsten Curdt
Fix For: 1.0-alpha-3
Currently a failed update from the scm and a broken build are being treated the
same.
IMO it would be better just to set a warning state for that project and retry
building
with the next trigger. Whether the warning
new jdtcore version 3.1
---
Key: MAVENUPLOAD-474
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-474
Project: maven-upload-requests
Type: Task
Reporter: Torsten Curdt
please update to this latest stable release
--
This message is
...OSGi by default doesn't do any dependency resolution. Either by
package, or by 'block'. In which case, if we use Maven for it at
build time, we're still stuck with a need for it at deploy time,
which seems a little odd...
I don't think we should use Maven for runtime dependency
resol
26 matches
Mail list logo