Re: any ideas why 'Scanning for projects' is very slow ?
Thanks Stephen, you know i actually considered putting this link in my previous reply about why i am not using the freestyle job type :-) But there is just too much that does not work anymore in freestyle, such as - executor-local repositories - maven releases - automatic post-build deploy ... just to name a few. I am sure I could script all these things back into a freestyle job but why ? I did attempt this several times over the years, but ended up abandoning it each time because of the complexity i would need to maintain myself + the several hundreds of build jobs to migrate ... Jorg On Thu, Jun 2, 2016 at 11:25 AM Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > > http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html > > On 2 June 2016 at 07:22, Jorg Heymans <jorg.heym...@gmail.com> wrote: > > > Hi, > > > > Thanks for the suggestions. > > > > --no-snapshot-updates does not make a difference. I tried out the > profiler > > and it gives me a breakdown of timings per phase, but it does not have > any > > timings on what happened before the first phase starts, which is exactly > > where the slowdown occurs. > > > > Converting the job to a freestyle project in jenkins also solves the > issue, > > but it's not really an option for us since we rely on a lot of the > > functionality that the maven job type offers. I guess i will have to head > > back to the Jenkins side then to find out what is going on. I know > Jenkins > > is instrumenting the maven process with some extra functionality and even > > rewrites the pom internally before execution. > > > > Apart from that, is there any other way to get a bit more debug info out > of > > maven during the 'scanning for projects' phase ? > > > > Jorg > > > > On Wed, Jun 1, 2016 at 8:24 PM Karl Heinz Marbaise <khmarba...@gmx.de> > > wrote: > > > > > BTW: What also comes to my mind. > > > > > > > > > Does the same happen if you ran that project as a freestyle project > > > instead of Maven Job type (which i assume) ? > > > > > > > > > Kind regards > > > Karl Heinz Marbaise > > > On 6/1/16 8:04 PM, Karl Heinz Marbaise wrote: > > > > Hi, > > > > > > > > On 6/1/16 10:47 AM, Jorg Heymans wrote: > > > >> Hi, > > > >> > > > >> I am trying to pinpoint a performance issue we are incurring with > > maven > > > >> under Jenkins. Basically what we are seeing is that maven is taking > a > > > >> very > > > >> long time getting past the initial 'Scanning for projects' message. > As > > > >> you > > > >> can see in below snippet, more than half a minute elapses before the > > > >> first > > > >> module is starting to build. > > > >> > > > >> *00:00:11.634* Maven home: > > > >> > > > > > > /home/ci/jenkins/data/tools/hudson.tasks.Maven_MavenInstallation/maven3*00:00:11.634* > > > >> > > > >> Java version: 1.7.0_80, vendor: Oracle Corporation*00:00:11.634* > Java > > > >> home: > > > >> > /home/ci/jenkins/data/tools/hudson.model.JDK/jdk1.7/jre*00:00:11.634* > > > >> Default locale: en, platform encoding: ISO646-US*00:00:11.634* OS > > > >> name: "sunos", version: "5.10", arch: "sparc", family: "unix" > > > > > > > > > > > >> > > > >> *00:00:11.757* [INFO] Scanning for projects... > > > >> > > > >> *00:00:42.350* [INFO] > > > >>*00:00:42.350* [INFO] > > > >> > > > > > > *00:00:42.350* > > > >> > > > >> [INFO] Building Document Implementation 0.2-SNAPSHOT > > > > > > > > Is this project an Maven Tycho project ? > > > > > > > > Kind regards > > > > Karl Heinz Marbaise > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
Re: any ideas why 'Scanning for projects' is very slow ?
Hi, Thanks for the suggestions. --no-snapshot-updates does not make a difference. I tried out the profiler and it gives me a breakdown of timings per phase, but it does not have any timings on what happened before the first phase starts, which is exactly where the slowdown occurs. Converting the job to a freestyle project in jenkins also solves the issue, but it's not really an option for us since we rely on a lot of the functionality that the maven job type offers. I guess i will have to head back to the Jenkins side then to find out what is going on. I know Jenkins is instrumenting the maven process with some extra functionality and even rewrites the pom internally before execution. Apart from that, is there any other way to get a bit more debug info out of maven during the 'scanning for projects' phase ? Jorg On Wed, Jun 1, 2016 at 8:24 PM Karl Heinz Marbaise <khmarba...@gmx.de> wrote: > BTW: What also comes to my mind. > > > Does the same happen if you ran that project as a freestyle project > instead of Maven Job type (which i assume) ? > > > Kind regards > Karl Heinz Marbaise > On 6/1/16 8:04 PM, Karl Heinz Marbaise wrote: > > Hi, > > > > On 6/1/16 10:47 AM, Jorg Heymans wrote: > >> Hi, > >> > >> I am trying to pinpoint a performance issue we are incurring with maven > >> under Jenkins. Basically what we are seeing is that maven is taking a > >> very > >> long time getting past the initial 'Scanning for projects' message. As > >> you > >> can see in below snippet, more than half a minute elapses before the > >> first > >> module is starting to build. > >> > >> *00:00:11.634* Maven home: > >> > /home/ci/jenkins/data/tools/hudson.tasks.Maven_MavenInstallation/maven3*00:00:11.634* > >> > >> Java version: 1.7.0_80, vendor: Oracle Corporation*00:00:11.634* Java > >> home: > >> /home/ci/jenkins/data/tools/hudson.model.JDK/jdk1.7/jre*00:00:11.634* > >> Default locale: en, platform encoding: ISO646-US*00:00:11.634* OS > >> name: "sunos", version: "5.10", arch: "sparc", family: "unix" > > > > > >> > >> *00:00:11.757* [INFO] Scanning for projects... > >> > >> *00:00:42.350* [INFO] > >>*00:00:42.350* [INFO] > >> > *00:00:42.350* > >> > >> [INFO] Building Document Implementation 0.2-SNAPSHOT > > > > Is this project an Maven Tycho project ? > > > > Kind regards > > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
any ideas why 'Scanning for projects' is very slow ?
Hi, I am trying to pinpoint a performance issue we are incurring with maven under Jenkins. Basically what we are seeing is that maven is taking a very long time getting past the initial 'Scanning for projects' message. As you can see in below snippet, more than half a minute elapses before the first module is starting to build. *00:00:11.634* Maven home: /home/ci/jenkins/data/tools/hudson.tasks.Maven_MavenInstallation/maven3*00:00:11.634* Java version: 1.7.0_80, vendor: Oracle Corporation*00:00:11.634* Java home: /home/ci/jenkins/data/tools/hudson.model.JDK/jdk1.7/jre*00:00:11.634* Default locale: en, platform encoding: ISO646-US*00:00:11.634* OS name: "sunos", version: "5.10", arch: "sparc", family: "unix" *00:00:11.757* [INFO] Scanning for projects... *00:00:42.350* [INFO] *00:00:42.350* [INFO] *00:00:42.350* [INFO] Building Document Implementation 0.2-SNAPSHOT This is a very small project we're building, containing only one maven module. In this case it's half a minute, we have seen other maven builds where it takes 2-3 minutes or more. Can anyone tell me what maven is doing in this 'Scanning for projects' that is potentially very slow ? If i run the build in offline mode the problem disappears, but that is not an option for us. Note that developers executing builds locally do not see the same performance issue. Thanks, Jorg PS the thread on the jenkins forum https://groups.google.com/forum/#!topic/jenkinsci-users/3s2MeImr2eY
Re: Why is Julia Antonova/Tumlare subscribed
On Fri, Jul 9, 2010 at 7:55 AM, Ralph Goers ralph.go...@dslextreme.comwrote: According to MarkMail the only posts she has ever made are those to inform us she is out of the office. Lurking is a constitutional right of the interwebs Ralph :-) Jorg
Re: Trouble trying to get 1000 consecutive concurrent green builds
On Fri, Feb 19, 2010 at 11:29 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: It turns out that the biggest blocker in achieving /any/ reliable concurrent building within maven is the java file system, which is basically seems limited to single threaded visibility of file updates; I'm still trying to figure out what the rules /are/ in this context and I'm hoping someone here knows ;) (for the gory details as far as I've gotten you can check out this post http://incodewetrustinc.blogspot.com/2010/02/concurrency-in-maven.html). Essentially this problem affects both the parallel mode and weave mode. Weave mode has higher concurrency and is hit harder. It seems like the only solution to this problem is aggressive forking; since this seems to delegate the whole issue to the OS. This may also mean that reliable concurrent building will only be available on OS'es that support reliable concurrent file visibility (modern linuxes do this very well, don't know about the others). Just to illustrate; on the C2D build box, my primary test build fails about once every 3-400 times with problems of this kind. Running the same build on the i7 box fails 1 in 5 times (the C2D is 32 bit JVM whilst the i7 is 64 bit vm (server) - which may also be relevant) - but it's file visibility issues that's the cause of the failure. I'm still trying to understand what rules actually apply or what it is actually possible to trust in this regard. If I turn on full paranoia, it seems to me like even the current parallel artifact download mechanism can be hit by this problem, since the files are not being written to disk by the thread that later consumes them. It seems to me like the only reliable way to do this (that is also future proof) is to run every module single-threaded until package-phase, in regular reactor order (using just 1 thread *total*). Then you can fork test for all reactor modules and thereafter complete the rest of the reactor on the same 1 thread you had initially. I'm probably overly paranoid. Anyone have any thoughts/experience with this subject ? Plz send me da codez ;) I'm wondering how Eclipse IDE gets around this. If you have say 40 java projects interconnected through project dependencies, and you do a full clean of all projects it rebuilds them in concurrent fashion taking the project dependency graph into account. And since projects use each others' class files during compilation (or so it seems) i'm thinking that at some point for large projects you would get the same issue every now and then. So maybe somebody over there could explain you their approach and how they solved it (maybe they're not using javac at all ??) HTH Jorg
Re: [VOTE] Release Apache Maven 3.0-alpha-5
On Thu, Dec 3, 2009 at 7:44 PM, Brian Fox bri...@infinity.nu wrote: Something like duplicate dependencies likely means you have a real problem you didn't know about in your poms. I think failing is appropriate in this case. I fail to grok what you just said there. So if i have in my pom dependency groupIdjavax.persistence/groupId artifactIdpersistence-api/artifactId version1.0/version /dependency and then 25 other dependencies and then again the one above (due to a copy-paste oversight let's say) then I have a real problem in my build you say. How is it different from unused and declared dependencies, or used and undeclared ? For me these all fit in the same boat ie 'potential build optimizations' Jorg PS how about a dependency:scan-duplicates then ? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG-3004/MNG-2802 - Achieving massive parallelity ?
On Tue, Dec 1, 2009 at 9:49 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I am pleased to announce that the weave mode now does a mvn clean install of a fairly regular project with any number of threads, and at great speed improvement - 2-4x is not uncommon. There are still issues to be sorted out, and I'd be really grateful for any reports of problems. See http://github.com/krosenvold/maven3 for a *lot* more details on problems issues and how to test this out on your builds. Looks incredibly promising ! I would be more than happy to give you test feedback if you could supply a binary dist with this feature. Or is it not yet ready to be tested by the 'masses' ? Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Jorg Heymans wrote: [ERROR] The project build-tools:1-SNAPSHOT (D:\src\myproject\pom.xml) has 1 error [ERROR] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: junit:junit:jar - duplicate declaration of version 3.8.2 Shall i log an issue for this or is this a known feature ? The error itself is by design and is part of overall stricter POM validation. If the cause isn't present in the current POM, it must be present in one of its parents. mvn ... -e should tell more but I will look into improving the message for the next release. I can understand the need for stricter pom validation, but is it really necessary to fail a build completely just because a dependency is declared twice ? It seems a bit harsh. A big [WARNING] seems more appropriate. Will m3 also fail builds for this one then: [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent! IMO most knowledgeable people react on warnings more positive, so more like ah cool m3 spotted a potential hazard so lets go and fix this instead of why the heck is m3 not able to build my project, lets revert to m2. Debatable, but that's how i see it. Cheers, Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
On Thu, Dec 3, 2009 at 11:10 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 2009/12/3 Jorg Heymans jorg.heym...@gmail.com On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Jorg Heymans wrote: [ERROR] The project build-tools:1-SNAPSHOT (D:\src\myproject\pom.xml) has 1 error [ERROR] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: junit:junit:jar - duplicate declaration of version 3.8.2 Shall i log an issue for this or is this a known feature ? The error itself is by design and is part of overall stricter POM validation. If the cause isn't present in the current POM, it must be present in one of its parents. mvn ... -e should tell more but I will look into improving the message for the next release. I can understand the need for stricter pom validation, but is it really necessary to fail a build completely just because a dependency is declared twice ? It seems a bit harsh. Actually, I'm liking this build failing on double dependencies. Any particular reason or do you get a kick out of scanning 60+ module reactor builds for duplicates ? :-P Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
Tried it out on our project, and i'm getting this:
[ERROR] The project build-tools:1-SNAPSHOT
(D:\src\myproject\pom.xml) has 1 error
[ERROR]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: junit:junit:jar - duplicate declaration of version
3.8.2
I can understand what this is trying to say, but the pom in question
is only a module pom that has no dependencies declared:
parent
groupIdmy.group/groupId
artifactIdparent/artifactId
version19-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
artifactIdbuild-tools/artifactId
packagingpom/packaging
version1-SNAPSHOT/version
modules
moduleant/module
modulemaven/module
/modules
Shall i log an issue for this or is this a known feature ? The output
of -e does not reveal anything useful besides lots of expression
${pom.version} is deprecated. Please use ${project.version} instead,
wierd thing is i'm never actually using expressions in my project.
Jorg
On Mon, Nov 23, 2009 at 11:04 PM, Igor Fedorenko i...@ifedorenko.com wrote:
+1
--
Regards,
Igor
Benjamin Bentmann wrote:
Hi,
We solved some more issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=14952
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500status=1
Staging repo:
https://repository.apache.org/content/repositories/maven-018/
Staged source and binary distros:
https://repository.apache.org/content/repositories/maven-018/org/apache/maven/apache-maven/3.0-alpha-5/
Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html
Vote open for 72 hours.
[ ] +1
[ ] +0
[ ] -1
+1 from me
Benjamim
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal after-the-fact: Experimental multithreading support
Hi Dan, Would the multithreading feature make it easier or harder to implement something like [1], ie distribute the different modules of a reactor build across different machines ? Or is it completely unrelated you think ? Thanks, Jorg Heymans [1] http://n4.nabble.com/New-plugin-to-distribute-maven-jobs-steps-td585138.html#a585138 On Tue, Nov 10, 2009 at 4:02 AM, Dan Fabulich d...@fabulich.com wrote: On Friday I was playing cowboy with my experimental thread support, but here's a more formal proposal around parallel project support in Maven 3.0. OUTSTANDING ISSUES In my earlier revision 833566, I attempted to fix MNG-3004: Allow build lifecycle to execute projects in parallel http://jira.codehaus.org/browse/MNG-3004 The general consensus around this bug (which has 25 votes) is that multithreading support can't work correctly right now because of MNG-2802: Concurrent-safe access to local Maven repository http://jira.codehaus.org/browse/MNG-2802 Several people have remarked in comments to MNG-3004 that it's appropriate to try to fix MNG-3004 (parallel projects) without fixing MNG-2802 (thread-safe local repo). In doing so, we'll allow users to optionally enable building multiple projects simultaneously. This is worth doing, because it can be tested in the wild, and because for some users, it will be immediately useful (e.g. especially if you use --offline mode). I agree with these comments, and attempted to implement them in revision 833566. MY PROPOSAL I attempted to check in the code in time for 3.0-alpha-3 a few days ago. That code was rolled back over the weekend and now lives in the MNG-3004 branch, because it broke integration tests. All integration tests now pass on my machine with the MNG-3004 branch, so I'd like to land it back in trunk again and re-cut 3.0-alpha-3 with this additional feature. As I stated on Friday, using the MNG-3004 branch, you can now do this: mvn install -Dmaven.threads.experimental=4 It works on my machine. If it works for you great; if it doesn't, we can figure out what's wrong together. WHY ALPHA-3? I'd like to land it back in alpha-3 because: * alpha-2 was in February; I don't want to wait for even four months to start testing this in the wild * I did check it in before alpha-3 was released, but it was rolled back quickly before the release vote was called * Otherwise I'd want to try to release alpha-4 immediately after alpha-3, which seems wasteful A NOTE ABOUT DEFAULTS Currently the code defaults to maven.threads.experimental=1. This fires up a single executor thread who does all work; the main thread joins to wait for it to finish. It's also possible to set maven.threads.experimental=0, in which case everything is done on the main thread, just like in alpha-2. If there is consensus, I'd be happy to set the default value to 0, though that increases the risk that the multithreaded code will get less coverage in the wild. I think leaving the value at 1 is a good compromise between avoiding complex threading issues and exercising tricky code. WHAT'S IN THE FUTURE? Post alpha-3 I'm keen on implementing a settings.xml option allowing users to configure their local repository layout. This will allow users to choose an alternate implementation that is thread-safe. Additionally, I think that this feature needs more tooling to make parallel projects understandable. The logger should be enhanced to identify which projects are logging which messages, and the final output of Maven should report more clearly which projects had warning/error messages, and how many such messages were reported. What do you say? -Dan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Idea: maven uri's
On Wed, May 27, 2009 at 3:55 PM, Christian Edward Gruber christianedwardgru...@gmail.com wrote: Anyway, I'm +1 on this. It is clear, unambiguous, and terse. Those work for me. My thoughts exactly ! Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Maven Release Plugin 2.0-beta-9 Released
On Wed, Apr 1, 2009 at 9:24 AM, Olivier Lamy ol...@apache.org wrote: Hi, Is it a release of a project which doesn't have a scm element and use a released parent project which has one ? That's the exact situation yes. Is this no longer an accepted situation perhaps ? Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Maven Release Plugin 2.0-beta-9 Released
Hi, beta-9 seems to have introduced something which my project cannot grok. I'm trying to do a release of my project's main pom: $mvn release:prepare -N -Darguments=-N [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: Path 'http://server/svn/project/tags/myparent-4/myproject' does not exist in revision 8100 I reverted to beta-8 and it's fine again. Is there any output i should provide to help troubleshoot this ? Thanks, Jorg On Sun, Mar 29, 2009 at 1:40 AM, Niall Pemberton niall.pember...@gmail.com wrote: On Sat, Mar 28, 2009 at 10:53 PM, Brian E. Fox bri...@reply.infinity.nu wrote: All set. Thanks Niall -Original Message- From: Niall Pemberton [mailto:niall.pember...@gmail.com] Sent: Saturday, March 28, 2009 5:52 PM To: Maven Developers List Subject: Re: [ANN] Maven Release Plugin 2.0-beta-9 Released The parent pom doesn't seem to have found its way to the public repo yet, is it on its way? http://repo1.maven.org/maven2/org/apache/maven/release/maven-release/ Niall On Sat, Mar 28, 2009 at 5:36 PM, Olivier Lamy ol...@apache.org wrote: Hi, The Maven team is pleased to announce the release of the Maven Release Plugin, version 2.0-beta-9. http://maven.apache.org/plugins/maven-release-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.0-beta-9/version /plugin Release Notes - Maven 2.x Release Plugin - Version 2.0-beta-9 ** Bug * [MRELEASE-273] - Regression: NullPointerException at end of standalone release:perform * [MRELEASE-375] - release plugin does not work with subversion 1.5.0 * [MRELEASE-379] - return results after performing a release * [MRELEASE-381] - url syntax not good enough for the git scm provider * [MRELEASE-386] - Sneaky bug in DefaultReleaseManager.perform() * [MRELEASE-393] - NoSuchMethodError when using InvokerMavenExecutor with cmd line arg --quiet * [MRELEASE-405] - Wrong branch-name parameter ** Improvement * [MRELEASE-385] - Upgrade to last scm version (1.2) * [MRELEASE-392] - Align release-parent, release-manager and release-plugin versions * [MRELEASE-427] - Add a mojo parameter for using the new remote tagging for svn scm provider (to prevent issue with svn 1.5.0) * [MRELEASE-429] - Support for a [token]-SNAPSHOT in addition to [number]-SNAPSHOT ** Task * [MRELEASE-390] - Add VSS dependency Have Fun! -- The Maven Team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Maven Release Plugin 2.0-beta-9 Released
On Wed, Apr 1, 2009 at 9:33 AM, Olivier Lamy ol...@apache.org wrote: Try mvn help:effective-pom I'm not sure the scm information is correct. I don't know what to make from the scm info, in any case it points to a non-existing tag: scm connectionscm:svn:http://server/svn/project/tags/myparent-4/myproject/connection developerConnectionscm:svn:http://server/svn/project/tags/myparent-4/myproject/developerConnection /scm The myproject at the end seems bad. In any case somehow beta-8 was able to cope with this, wierd. btw : can you test with http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#remoteTagging set to false ? yep, added -DremoteTagging=false and now it works. Should i file an issue for this ? Thanks, Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PLEASE TEST] Maven 2.1.0-RC1
On Mon, Mar 9, 2009 at 5:00 PM, John Casey jdca...@commonjava.org wrote: Hi everyone, I've rolled the first release candidate for Maven 2.1.0. It's available at: http://tinyurl.com/maven-2-1-0-RC1 (https://repository.apache.org/content/repositories/maven-staging-4e4fa48c70323f/org/apache/maven/apache-maven/2.1.0/) Works fine (and a tad bit faster) for my project builds. FWIW I don't see any of the [WARNING] messages Daniel is seeing. Regards, Jorg Heymans - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PLEASE TEST] Maven 2.1.0-M1-RC17
On Wed, Sep 10, 2008 at 5:32 AM, John Casey [EMAIL PROTECTED] wrote: Hi, I've fixed MNG-3748, where illegal elements in the settings.xml were not triggering build failure. Anyway, this release candidate includes a fix for that issue: http://people.apache.org/~jdcasey/stage/current-maven-RC/http://people.apache.org/%7Ejdcasey/stage/current-maven-RC/ migrated our Hudson instance from RC-12 to RC-17, all still working fine ! Thanks, Jorg
Re: Go Hudson!
On Fri, May 9, 2008 at 10:34 AM, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, For those not at JavaOne I just wanted to mention that Kohsuke along with the Hudson community won a Duke award. I think Hudson is awesome and Kohsuke has done a great job supporting the community (just read the mailing list to see how supportive he is) and Hudson as a tool is just fantastic. +100, a big big thanks to Kohsuke for doing such a great project and congratulations with the Duke award !! Way to go Kohsuke and thanks for providing an awesome CI tool! Kohsuke has primarily worked on Hudson as his hobby and he does so because he just loves working on it and he definitely deserves our thanks. Well hobby project or not, i find it pretty amazing when a project does 100+ quality releases in one year ! At first I thought Kohsuke was working on Hudson full time, only later I realized how many other hobby projects on dev.java.net he is involved in :-D Jorg
Re: [2.0.9 RC6]
Just used it to build and release about 10 modules in my project, worked fine. Thanks for the consistence in quality btw, the RC process is really a step up from what was done before. Jorg On Tue, Apr 1, 2008 at 11:34 PM, Brian E. Fox [EMAIL PROTECTED] wrote: We made a minor tweak to the dependency order processing. See http://jira.codehaus.org/browse/MNG-3494 for more details. RC6 is staged at: http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apache-maven/ --Brian
Re: [pre vote take 3] 2.0.9-RC3
same here, no apparent issues with RC4 on my projects.
On Thu, Mar 27, 2008 at 9:27 AM, nicolas de loof [EMAIL PROTECTED] wrote:
+1
Tested with my local projects with no issue.
2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]:
+1 the bundle worked fine to build
the archetype plugin.
Raphaël
2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]:
+1 for the new process.
not yet tested the bundle.
Raphaël
2008/3/26, Brian E. Fox [EMAIL PROTECTED]:
We fixed the regressions identified last week with the plugin tools
and
reporting impl. The new 2.0.9 is staged at
http://people.apache.org/~brianf/staging-repository/org/apache/maven/apahttp://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
che-maven/2.0.9-RC3/
You'll notice that this one has an RC qualifier attached to it.
Since
what I've actually been staging hasn't been for an official vote,
it
makes more sense to have actual deterministic numbers on them
instead of
continuously rolling back and forth between .10 and .9.
The other significant reason it has a qualifier is that I want to
solicit feedback from the users list without potentially getting
multiple versions out there called 2.0.9. My new mantra for the
maven
release is no more regressions. To that end, what I intend to do
is
let the RC sit here for a day. If no one turns up anything new (it
should be good since this is really attempt #3), then I'll email
the
user list to solicit feedback. Naturally we'll probably get a slew
of
can you fix xyz but the only thing that we will consider at this
point
would be a regression from 2.0.8 to the current RC. If something
is
identified then we should consider fixing it and re-releasing RC4.
I
think that having the users more involved in testing the RCs is
the
only
way to really identify and eliminate regressions. If someone
identifies
a regression after the fact and didn't speak up or try it, well
that's
unfortunate but it'll have to wait.
The RC can sit with the users for 3 days. If nothing turns up,
then
I'll
restage with a final release tag and we can do a formal vote.
Assuming
this is all successful, then I'll document a more formal Core
release
procedure that we can follow going forward.
Here's the list of issues fixed in the latest RC:
Release Notes - Maven 2 - Version 2.0.9
** Bug
* [MNG-1412] - dependency sorting in classpath
* [MNG-1914] - Wrong url in error message when using a mirror
* [MNG-2123] - NullPointerException when a dependency uses
version
range and another uses an actual version incompatible with that
range
* [MNG-2145] - Plugins' dependencies are not always checked
* [MNG-2178] - incorrect M2_HOME guess in mvn.bat
* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored
when
profiles section is missing or empty
* [MNG-2339] - ${project.*} are interpreted in the wrong place
* [MNG-2744] - checksum comparison should be case-insensitive
* [MNG-2809] - Can't activate a profile by checking for the
presence
of a file in ${user.home}
* [MNG-2848] - Environment variables in profile activation not
working
* [MNG-2861] - NullPointerException in DefaultArtifactCollector
for
relocated resolvedArtifacts with different version ranges and
available
versions.
* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo
()
if
there's no mojo in pom.xml
* [MNG-2928] - Null pointer exeception when introducing version
range [major.minor.build-SNAPSHOT,)
* [MNG-2972] - Ignores version of plugin dependency specified
in
my
pom
* [MNG-3086] - NullPointerException in
ResolutionNode.getTrail(ResolutionNode.java:136)
* [MNG-3099] - Profiles ignored when working with non-projects
(such
as archetype:create)
* [MNG-3111] - Classpath order incorrect
* [MNG-3156] - NullPointerException with mvn dependency:sources
* [MNG-3221] - Infinite loop in DefaultLifecycleExecutor
* [MNG-3259] - Regression: Maven drops dependencies in
multi-module
build
* [MNG-3286] - execution.inherited field is ignored
* [MNG-3288] - Invalid systemPath allows build to
continue--failing
in later phase.
* [MNG-3296] - mvn.bat looses error code on windows NT type
platforms
* [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not
set
* [MNG-3316] - Barfs at attribues named
Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-1
(sorry for hijacking the vote thread for this) Hi Raphaël, Can you give us some pointers to list threads, proposals or specs that explain the basics of the new architecture and how to use it ? I'm very keen to try it out and give you all the feedback you want, but if it means grepping the sources to find out how things work i'll hold off until alpha-2. Thanks! Jorg On Feb 2, 2008 1:25 AM, Raphaël Piéroni [EMAIL PROTECTED] wrote: Hi, Here comes the time for calling the first release of the Maven Archetype plugin version 2.0-alpha-1. Staging repo: http://people.apache.org/~rafale/staging-repo/maven-archetype-plugin/http://people.apache.org/%7Erafale/staging-repo/maven-archetype-plugin/ Staging site: No staging site now, the new documentation is not yet written. Its is planed for version 2.0-alpha-2. Vote open for 96 hours. [ ] +1 [ ] +0 [ ] -1 Regards, Raphaël
Re: [VOTE] preparing the release of archetypeng
+1000, thanks Raphaël ! Jorg On Jan 8, 2008 11:58 PM, Raphaël Piéroni [EMAIL PROTECTED] wrote: Hello, I would like to prepare the alpha-1 release of the archetypeng stuff. Preparing that release will need to do these things: 1. move the current archetype code (svn.apache.org/repos/asf/maven/archetype/trunk) to a branch (.../branches/archetype-1.0.x) 2. move the current archetypeng (svn.apache.org/repos/asf/maven/sandbox/trunk/archetypeng) to to the old archetype trunk This vote is open for at least 72 hours Regards, Raphaël
Re: Request help on MCLIRR-7
On Jan 8, 2008 11:02 PM, Tom Huybrechts [EMAIL PROTECTED] wrote: Take a look at the developer cookbook ( http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook ) It would make sense to create a link from http://maven.apache.org/guides/plugin/guide-java-plugin-development.html to this page. I did not know about its existence until now (thanks Tom), mainly because Google does not list it on any mojo related search. Jorg
Re: Interactivity for Maven Archetype plugins
FYI a release seemed to be eminent a while ago [1], but it never materialized somehow :-( Jorg (another eager archetypeNG customer) [1] http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.devel/82488 On Jan 4, 2008 1:04 AM, Brian E. Fox [EMAIL PROTECTED] wrote: The archetypeNG plugin has the interactivity you're been reading about...but it's not released yet. -Original Message- From: sgargan [mailto:[EMAIL PROTECTED] Sent: Thursday, January 03, 2008 5:27 PM To: dev@maven.apache.org Subject: Interactivity for Maven Archetype plugins Hi, I have seen discussion on the mailing list about adding interactivity to Archetype plugin, so that users can customize how a project is created at the creation time e.g. by being asked questions at the console or otherwise. Has anything been decided on this front and if so is there an api available or interactive archetypes that serve as good examples? If not, is there likely to be interactivity for archetypes going forward or will the -D property set method remain the only mechanism? What are the main objections to interactivity? rgds, stephen -- View this message in context: http://www.nabble.com/Interactivity-for-Maven-Archetype-plugins-tp146068 18s177p14606818.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-dependency-tree 1.1
I guess the dependency plugin itself now needs another release before I can do mvn dependency:tree on a project ? Regards Jorg On Dec 17, 2007 10:07 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Carlos, What's the scoop on this release? Add my +1 to it, I see it's still in your staging repo but isn't out on central yet. I need this to do a dependency plugin release. Thanks, Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Thursday, November 29, 2007 2:14 AM To: Maven Developers List Subject: [VOTE] Release maven-dependency-tree 1.1 It has many improvements related to resolution event handling, using the latest fixes in Maven 2.0.8 Release is staged in http://people.apache.org/~carlos/staging-repo/http://people.apache.org/%7Ecarlos/staging-repo/ -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-dependency-tree 1.1
PING Is this release missing PMC votes perhaps ? It still hasn't appeared on repo1. Thanks Jorg On Dec 6, 2007 12:25 PM, Mark Hobson [EMAIL PROTECTED] wrote: I see this got released (thanks) but hasn't appeared on the central repo, any reason for this? Cheers, Mark On 30/11/2007, Vincent Siveton [EMAIL PROTECTED] wrote: +1 Vincent 2007/11/29, Carlos Sanchez [EMAIL PROTECTED]: It has many improvements related to resolution event handling, using the latest fixes in Maven 2.0.8 Release is staged in http://people.apache.org/~carlos/staging-repo/http://people.apache.org/%7Ecarlos/staging-repo/ -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ping] archetypeng release ?
On Nov 22, 2007 6:35 PM, Jason van Zyl [EMAIL PROTECTED] wrote: I have two things to check: - Make sure that when run in the context of Maven (the embedder) that http proxying works - Make sure that everything works offline well (I've removed the wiki slurping as it proved to be entirely unreliable) Give it a week and I think we can cut a release. OK cool, looking forward to give it a spin then ! Cheers, Jorg
[ping] archetypeng release ?
Hi, Any news on the release of this plugin ? Looking at [1] it seems that the code was more than ready at the time ... and jira doesn't list anything major either for 2.0-alpha-1. I'd say just get it out there and start gathering real user feedback ! Regards Jorg [1] http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.devel/81757
Re: [ping] archetypeng release ?
Hi Raphaël, On Nov 22, 2007 11:41 AM, Raphaël Piéroni [EMAIL PROTECTED] wrote: There is currently a refactoring around the way archetypes are known to the plugin and how they are deployed into repositories. Thanks, do you have any threads I can look at to understand better what is the blocking issue here ? Is this new deployment mechanism core to the plugin's inner workings ? After that, the last main problem i see is documentation. Then i think we could release. Any one has toughs on this schedule ? As it will be alpha i wouldn't bother too much with the docs. As long as there is one basic and one complicated example to learn from we will get by for the first releases :-) Regards Jorg
Re: [VOTE] release maven-changes-plugin 2.0-beta-3
Stephane Nicoll wrote: Hi, I'd like to release maven-changes-plugin 2.0-beta-3. Significant fixes are available in trunk and the latest release is almost one year old. ping Is this still on track to be released anytime soon ? Thanks jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mirror woes
Aaron Digulla wrote: Since a few months, some European mirrors have become increasingly unreliable. For example, maven.sateh.com is missing some packages which were distributed in June, mirrors.dotsrc.org is missing some dated from February (for example, asm/asm/3.0)! Any particular reason why you're using a mirror ? We've been using repo1 extensively for over a year now (after it migrated to contegix) and have been extremely happy with its responsiveness since. Cheers, Jorg PS we're based in Europe, and IIRC repo1 is somewhere on the westcoast of the US - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What can possibly go wrong with Maven
Jason van Zyl wrote: Anyone have anything else? I'm not trying to consider everything that Any chance that mvn could indicate the exact pom.xml locations of duplicated projects ? So instead of this: [INFO] Project 'testgroup:testartifactA' is duplicated in the reactor [INFO] something like: [INFO] Project 'testgroup:testartifactA' is duplicated in the reactor [INFO] This project is defined by following poms: [INFO] - /tmp/project/module1/pom.xml [INFO] - /tmp/project/module2/pom.xml Regards Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Central Repository for Maven 2.0.6
Thierry Barnier wrote: Hi Jaish, I would recommend you the following maven proxies -AbstractHorizon Proximity http://proximity.abstracthorizon.org/ -Apache Archiva http://maven.apache.org/archiva/ -Mergere Maestro http://www.mergere.com/ -Maven proxy http://maven-proxy.codehaus.org/ You left out the one i consider to be the best for the moment: Artifactory (jfrog.org) Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.6
Jason van Zyl wrote: The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/ Staging repository: http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/org/apache/maven/maven-core/2.0.6/ A non-binding but therefor not less whole-hearted +1 ! Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.6 Pre flight check
Jason van Zyl wrote: Before I staged the release I just wanted to get some people to a build first: http://idisk.maven.org/jvanzyl/Public/maven/ Brian, Jason Dillon, and Dan Kulp have tried their builds and I just wanted to get a little more feedback. Cocoon and Excalibur trunk build fine with this snapshot. Regards, Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] MNG-1577 as the default behavior
Eric Redmond wrote: +1 for patching 2.0.6 I have yet to hear a single convincing argument for maintaining broken behavior. Who cares if people depend on it being broken? Don't upgrade. It's a defect, not a feature change. Pushing this to a major version is way overkill. +1 Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invalid link on Maven site
Related: The page http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html looks messed up. In fact most of the pages for that plugin seem to suffer from the same problem Jorg Julien HENRY wrote: Hi, On this page : http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html The link : Check out the Guide to Configuring Maven if necessary. is invalid. ++ Julien ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.5 (take 2)
Jason van Zyl wrote: Hi, The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/maven-core/2.0.5/ Excalibur builds fine with this release, no apparent probs spotted. Thanks, Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven.repo.local needs to be absolute or canonical (was Re: server/branches/1.2 build failing due to surefire not finding junit?!)
Jason Dillon wrote: When I was building locally and on remote systems, I was using -Dmaven.repo.local=repository to use a specific repository directoy. But it looks like something inside of Maven or Surefire is not happy if this value is not absolute or canonical. While most of Maven is happy with the relative path downloading a ton of artifacts into the correct directory, something gets screwy when going to launch tests. I've fixed my harness to make this path canonical, but my guess is that Maven should always resolve maven.repo.local to a canonical file before attempting to use it for sanity. Any Maven peeps out there know if this is a known issue? FWIW i can confirm this, had the same problem when building Cocoon with a relative repository set in settings.xml. Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and JDK 1.6
mraible wrote: Here's the issue I discovered with 2.0.4 and JDK 6. AppFuse 2.x users have reported other issues (i.e. plugins not firing) when using JDK 6. http://jira.codehaus.org/browse/MNG-2709 http://article.gmane.org/gmane.text.xml.cocoon.devel/69786 It seems that maven builds a different compilation classpath under 1.6 and 1.5. Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] building eclipse:eclipse trunk - proxy issues?
Barrie Treloar wrote: Overall for test results for maven-eclipse-plugin r472779 Tests run: 30, Failures: 0, Errors: 22, Skipped: 0 Some example warning messages: [ maven embedder WARNING] repository metadata for: 'artifact org.apache.maven.plugins:maven-eclipse-plugin' could not be retrieved from repository: central due to an error: Error transferring file [ maven embedder INFO] Repository 'central' will be blacklisted In AbstractEclipsePluginTestCase I can see: this.maven = new MavenEmbedder(); this.maven.setClassLoader( Thread.currentThread().getContextClassLoader() ); this.maven.setLogger( new MavenEmbedderConsoleLogger() ); this.maven.setLocalRepositoryDirectory( localRepositoryDir ); this.maven.setOffline( true ); this.maven.setInteractiveMode( false ); this.maven.start(); which looks like it is trying to put the MavenEmbedder in offline mode, so why is it attempting to download files? Has anyone else experienced this problem, or know what I need to do to get this working? Cheers The offline mode for some reason is not really 'offline' in the common understanding of the word. Perhaps one of the developers can clarify the semantics of the offline mode in a maven build? See also http://jira.codehaus.org/browse/MNG-2433 Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: src/main/config
Erik Drolshammer wrote: Hi! What is the difference between src/main/config and src/main/resources? Anything you want to be included in the classpath of your application should go in src/main/resources. Other config files that are not needed at runtime by your application (eg checkstyle*.xml) should go to src/main/config. HTH Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven.apache.org on mac os x
Hi, The navigation on the top right and the last published date on the top left are hardly readable with firefox/safari on Mac OS X (opera displays it fine). screenshot at http://www.domek.be/smalltext.png Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuum behind SSL, any progress on this
Hi Reinhard, Reinhard Poetz wrote: - install mod_proxy_html and load it within your Apache configuration - add following lines to your Apache configuration file: ProxyRequests Off ProxyPass/ http://localhost:8082/ ProxyPassReverse / http://localhost:8082/ SetOutputFilter proxy-html ProxyHTMLURLMap http://localhost:8082 https://[your-domain.org] i tried enabling this on our zone, but i'm getting Invalid command 'ProxyHTMLURLMap', perhaps mis-spelled or defined by a module not included in the server configuration The module is loaded though, is there anything else that is needed to get this to work? Thanks Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuum behind SSL, any progress on this
Carlos Sanchez wrote: I think this is already fixed for 1.1 Are you guys planning on releasing a first 1.1 snapshot anytime soon? Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPIR-21) no a href generated for archive URL
[ http://jira.codehaus.org/browse/MPIR-21?page=comments#action_55925 ] Jorg Heymans commented on MPIR-21: -- I just updated to 2.0.2 snapshot and maven-site-plugin-2.0-20060106.225541-3.jar , the behaviour is still there. no a href generated for archive URL -- Key: MPIR-21 URL: http://jira.codehaus.org/browse/MPIR-21 Project: Maven 2.x Project Info Reports Plugin Type: Bug Versions: 2.0-beta-3 Reporter: Jorg Heymans Add below mailinglist configuration to a project, and run mvn site:site . Then look at the page and you'll see that only a tdhttp://marc.theaimsgroup.com/?l=xml-cocoon-dev/td section is generated for the second otherArchive. mailingList nameCocoon User List/name subscribe[EMAIL PROTECTED]/subscribe unsubscribe[EMAIL PROTECTED]/unsubscribe postusers@cocoon.apache.org/post archivehttp://mail-archives.apache.org/mod_mbox/cocoon-users/archive otherArchives otherArchivehttp://www.mail-archive.com/users@cocoon.apache.org//otherArchive !-- THE URL BELOW IS NOT RENDERED PROPERLY FOR SOME REASON -- otherArchivehttp://marc.theaimsgroup.com/?l=xml-cocoon-user/otherArchive otherArchivehttp://news.gmane.org/gmane.text.xml.cocoon.user/otherArchive /otherArchives /mailingList When i remove everything from the questionmark onwards it works again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1823) dependencies with classifier mask transitive dependencies of same dependency without classifier
dependencies with classifier mask transitive dependencies of same dependency without classifier --- Key: MNG-1823 URL: http://jira.codehaus.org/browse/MNG-1823 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0.1 Reporter: Jorg Heymans A module in cocoon has following dependencies : dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-core/artifactId version2.2.0-SNAPSHOT/version classifiertests/classifier scopetest/scope /dependency dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-core/artifactId version2.2.0-SNAPSHOT/version /dependency The first dependency is created by the core module using : plugin artifactIdmaven-jar-plugin/artifactId executions execution goals goaltest-jar/goal /goals /execution /executions /plugin Now i would like the module to depend on the jar with classifier tests during the testing phase ie cocoon-core-2.2.0-SNAPSHOT-tests.jar, and during the normal compilation phase it should just use cocoon-core-2.2.0-SNAPSHOT.jar. IMO above dependencies express exactly this. The problem is that maven somehow removes all transitive dependencies from cocoon-core-2.2.0-SNAPSHOT.jar when both dependencies are in place, breaking compilation. When i remove the dependency with the classifier, then all is fine (but ofcourse my tests can't run) I hope above is clear, otherwise just ping me on irc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (ARCHETYPE-19) archetype creation broken
archetype creation broken - Key: ARCHETYPE-19 URL: http://jira.codehaus.org/browse/ARCHETYPE-19 Project: Maven Archetype Type: Bug Components: maven-archetype-plugin Reporter: Jorg Heymans Assigned to: Jason van Zyl - when creating an archetype ie doing archetype:create, the template substitution routines mangle characters like © . - binary files are also searched through for substitution this often results in exceptions and failed creation. I think the archetype desperately needs a way of switching off template substitution for anything else but pom.xml. It's hardly useable for us in it's present form. I can create a testcase if necessary, just ask. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (ARCHETYPE-18) fileset support
fileset support --- Key: ARCHETYPE-18 URL: http://jira.codehaus.org/browse/ARCHETYPE-18 Project: Maven Archetype Type: Improvement Components: maven-archetype-plugin Reporter: Jorg Heymans Assigned to: Jason van Zyl it would be great if the descriptor supported filesets of some sort, as it's currently a pain creating descriptors for archetypes that contain a large amount of files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1670) using archetypes not deployed on central or one of it's mirrors
[ http://jira.codehaus.org/browse/MNG-1670?page=comments#action_51914 ] Jorg Heymans commented on MNG-1670: --- thinking about it, this effectively makes it impossible to have say company-wide archetypes. I would like to up the priority of this but it seems that i haven't got the rights to do so. using archetypes not deployed on central or one of it's mirrors --- Key: MNG-1670 URL: http://jira.codehaus.org/browse/MNG-1670 Project: Maven 2 Type: New Feature Versions: 2.0 Reporter: Jorg Heymans Assignee: John Casey Priority: Minor I have an archetype deployed on cvs.apache.org/maven-snapshot-repository. There is no way for users to use this archetype without creating a dummy pom first so that the configuration in settings.xml (where i defined this repository) kicks in. IRC log : jorg does the archetype plugin take settings.xml in account ? I've defined it as http://rafb.net/paste/results/8ajh7v15.html , but when looking for the archetype it doesn't even go to that server jorg or maybe it's a pluginRepository instead ... trying jdcasey jorg: I think the active profiles in the settings.xml are only applied to the current project, so if you're executing without a current project I dunno that it will use them jorg oh drats jorg so i'll give the users a dummy pom + settings.xml to execute against.. jdcasey jorg: it might be nice to have in the future though... jdcasey it could modify the instance of the super-project that's loaded in memory jorg might be nice yes .. i don't see any other way jorg (unless your archetype is published to the primary download site or one of it's mirrors ofcourse) jdcasey file it, if you like jorg :) jdcasey :) so unless you've got your stuff on ibiblio nobody can easily use your archetype. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1678) missing element does not trigger any warning
missing element does not trigger any warning Key: MNG-1678 URL: http://jira.codehaus.org/browse/MNG-1678 Project: Maven 2 Type: Improvement Versions: 2.0 Reporter: Jorg Heymans spot the subtle error in below pom : ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdorg.my.project/groupId artifactIdmyProject/artifactId version0.1/version nameThe Project/name packagingjar/packaging repositories repository idapache-maven2-snapshot/id nameApache Maven2 Snapshot Repository/name urlhttp://cvs.apache.org/maven-snapshot-repository/url /repository /repositories dependencies groupIdorg.apache.cocoon/groupId artifactIdcocoon-core/artifactId version2.2.0-SNAPSHOT/version /dependencies /project The dependency element is missing inside dependencies. Maven did not give any warning or error though. Note that in my actual project, the dependency was not needed for compilation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1656) xml-apis relocation wrong
[ http://jira.codehaus.org/browse/MNG-1656?page=comments#action_51752 ] Jorg Heymans commented on MNG-1656: --- I have verified with an SVN build as of a few minutes ago, the issue seems to have been fixed. xml-apis relocation wrong - Key: MNG-1656 URL: http://jira.codehaus.org/browse/MNG-1656 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0 Reporter: Jorg Heymans Assignee: John Casey Priority: Critical Fix For: 2.0.1 Attachments: log.txt Original Estimate: 3 hours Time Spent: 3 hours Remaining: 0 minutes During my build, i get this multiple times : [WARNING] This artifact has been relocated to xml-apis:xml-apis:1.0.b2. Even though i have directly specified xml-apis:xml-apis:1.3.02 in my pom, maven insists on using 1.0.b2, making my build fail. Steps to reproduce 1) svn co http://svn.apache.org/repos/asf/cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/ testbug 2) edit settings.xml to point to a clean repo 3) mvn -N -s settings.xml install 4) cd cocoon-core 5) mvn -s ..\settings.xml -Dmaven.test.skip=true compile This should fail with : [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java :[26,19] cannot resolve symbol symbol : class DOMConfiguration location: package dom C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java :[39,19] cannot resolve symbol symbol : class UserDataHandler location: package dom C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java :[914,11] cannot resolve symbol symbol : class DOMConfiguration location: class org.apache.cocoon.xml.dom.DocumentWrapper C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java :[1012,56] cannot resolve symbol symbol : class UserDataHandler location: class org.apache.cocoon.xml.dom.DocumentWrapper The interfaces it can't find are effectively in 1.3.02 , but not in 1.0.b2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1666) PluginParameterExpressionEvaluator, StringIndexOOBE
PluginParameterExpressionEvaluator, StringIndexOOBE --- Key: MNG-1666 URL: http://jira.codehaus.org/browse/MNG-1666 Project: Maven 2 Type: Bug Components: Plugin API Versions: 2.0.1 Environment: SunOS cocoon.zones.apache.org 5.10 Generic_118844-08 i86pc i386 i86pc Reporter: Jorg Heymans Priority: Critical Attachments: exception.log, parentpom.xml, pom.xml doing package/install i get : java.lang.StringIndexOutOfBoundsException: String index out of range: 1 at java.lang.String.charAt(String.java:558) at java.util.regex.Matcher.appendReplacement(Matcher.java:704) at java.util.regex.Matcher.replaceAll(Matcher.java:806) at java.lang.String.replaceAll(String.java:2000) at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:145) at org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.fromExpression(AbstractConfigurationConverter.java:167) at org.codehaus.plexus.component.configurator.converters.basic.AbstractBasicConverter.fromConfiguration(AbstractBasicConverter.java:57) at org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration(CollectionConverter.java:177) at org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56) at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1031) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:576) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:390) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) The compile target does not suffer from this. I have attached the pom and parent pom. Output of maven -X is also attached -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1670) using archetypes not deployed on central or one of it's mirrors
using archetypes not deployed on central or one of it's mirrors --- Key: MNG-1670 URL: http://jira.codehaus.org/browse/MNG-1670 Project: Maven 2 Type: New Feature Versions: 2.0 Reporter: Jorg Heymans Priority: Minor I have an archetype deployed on cvs.apache.org/maven-snapshot-repository. There is no way for users to use this archetype without creating a dummy pom first so that the configuration in settings.xml (where i defined this repository) kicks in. IRC log : jorgdoes the archetype plugin take settings.xml in account ? I've defined it as http://rafb.net/paste/results/8ajh7v15.html , but when looking for the archetype it doesn't even go to that server jorgor maybe it's a pluginRepository instead ... trying jdcasey jorg: I think the active profiles in the settings.xml are only applied to the current project, so if you're executing without a current project I dunno that it will use them jorgoh drats jorgso i'll give the users a dummy pom + settings.xml to execute against.. jdcasey jorg: it might be nice to have in the future though... jdcasey it could modify the instance of the super-project that's loaded in memory jorgmight be nice yes .. i don't see any other way jorg(unless your archetype is published to the primary download site or one of it's mirrors ofcourse) jdcasey file it, if you like jorg:) jdcasey :) so unless you've got your stuff on ibiblio nobody can easily use your archetype. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1670) using archetypes not deployed on central or one of it's mirrors
[ http://jira.codehaus.org/browse/MNG-1670?page=comments#action_51834 ] Jorg Heymans commented on MNG-1670: --- http://jira.codehaus.org/browse/ARCHETYPE-1 seems like this was filed before. using archetypes not deployed on central or one of it's mirrors --- Key: MNG-1670 URL: http://jira.codehaus.org/browse/MNG-1670 Project: Maven 2 Type: New Feature Versions: 2.0 Reporter: Jorg Heymans Assignee: John Casey Priority: Minor I have an archetype deployed on cvs.apache.org/maven-snapshot-repository. There is no way for users to use this archetype without creating a dummy pom first so that the configuration in settings.xml (where i defined this repository) kicks in. IRC log : jorg does the archetype plugin take settings.xml in account ? I've defined it as http://rafb.net/paste/results/8ajh7v15.html , but when looking for the archetype it doesn't even go to that server jorg or maybe it's a pluginRepository instead ... trying jdcasey jorg: I think the active profiles in the settings.xml are only applied to the current project, so if you're executing without a current project I dunno that it will use them jorg oh drats jorg so i'll give the users a dummy pom + settings.xml to execute against.. jdcasey jorg: it might be nice to have in the future though... jdcasey it could modify the instance of the super-project that's loaded in memory jorg might be nice yes .. i don't see any other way jorg (unless your archetype is published to the primary download site or one of it's mirrors ofcourse) jdcasey file it, if you like jorg :) jdcasey :) so unless you've got your stuff on ibiblio nobody can easily use your archetype. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1656) xml-apis relocation wrong
xml-apis relocation wrong - Key: MNG-1656 URL: http://jira.codehaus.org/browse/MNG-1656 Project: Maven 2 Type: Bug Components: maven-artifact Versions: 2.0 Reporter: Jorg Heymans Priority: Critical During my build, i get this multiple times : [WARNING] This artifact has been relocated to xml-apis:xml-apis:1.0.b2. Even though i have directly specified xml-apis:xml-apis:1.3.02 in my pom, maven insists on using 1.0.b2, making my build fail. Steps to reproduce 1) svn co http://svn.apache.org/repos/asf/cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/ testbug 2) edit settings.xml to point to a clean repo 3) mvn -N -s settings.xml install 4) cd cocoon-core 5) mvn -s ..\settings.xml -Dmaven.test.skip=true compile This should fail with : [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java :[26,19] cannot resolve symbol symbol : class DOMConfiguration location: package dom C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java :[39,19] cannot resolve symbol symbol : class UserDataHandler location: package dom C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java :[914,11] cannot resolve symbol symbol : class DOMConfiguration location: class org.apache.cocoon.xml.dom.DocumentWrapper C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java :[1012,56] cannot resolve symbol symbol : class UserDataHandler location: class org.apache.cocoon.xml.dom.DocumentWrapper The interfaces it can't find are effectively in 1.3.02 , but not in 1.0.b2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1656) xml-apis relocation wrong
[ http://jira.codehaus.org/browse/MNG-1656?page=comments#action_51657 ] Jorg Heymans commented on MNG-1656: --- http://jira.codehaus.org/browse/MEV-216 and http://jira.codehaus.org/browse/MEV-222 are related xml-apis relocation wrong - Key: MNG-1656 URL: http://jira.codehaus.org/browse/MNG-1656 Project: Maven 2 Type: Bug Components: maven-artifact Versions: 2.0 Reporter: Jorg Heymans Priority: Critical During my build, i get this multiple times : [WARNING] This artifact has been relocated to xml-apis:xml-apis:1.0.b2. Even though i have directly specified xml-apis:xml-apis:1.3.02 in my pom, maven insists on using 1.0.b2, making my build fail. Steps to reproduce 1) svn co http://svn.apache.org/repos/asf/cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/ testbug 2) edit settings.xml to point to a clean repo 3) mvn -N -s settings.xml install 4) cd cocoon-core 5) mvn -s ..\settings.xml -Dmaven.test.skip=true compile This should fail with : [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java :[26,19] cannot resolve symbol symbol : class DOMConfiguration location: package dom C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java :[39,19] cannot resolve symbol symbol : class UserDataHandler location: package dom C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java :[914,11] cannot resolve symbol symbol : class DOMConfiguration location: class org.apache.cocoon.xml.dom.DocumentWrapper C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java :[1012,56] cannot resolve symbol symbol : class UserDataHandler location: class org.apache.cocoon.xml.dom.DocumentWrapper The interfaces it can't find are effectively in 1.3.02 , but not in 1.0.b2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1644) parent pom = child pom results in stack overflow error
parent pom = child pom results in stack overflow error -- Key: MNG-1644 URL: http://jira.codehaus.org/browse/MNG-1644 Project: Maven 2 Type: Improvement Versions: 2.0 Reporter: Jorg Heymans Though it's a stupid thing to do, if you define project parent groupIdexcalibur/groupId artifactIdexcalibur/artifactId version1.0/version /parent modelVersion4.0.0/modelVersion groupIdexcalibur/groupId artifactIdexcalibur/artifactId version1.0/version nameExcalibur Components/name packagingpom/packaging modules .. ... /project you get : d:\src\excalibur-trunkmvn [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.StackOverflowError [INFO] [INFO] Total time: 1 second [INFO] Finished at: Mon Nov 21 18:29:03 CET 2005 [INFO] Final Memory: 1M/4M [INFO] A better error message would be nice here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1601) wagon-ssh or deploy plugin sometimes uses scp instead of configured pscp
wagon-ssh or deploy plugin sometimes uses scp instead of configured pscp - Key: MNG-1601 URL: http://jira.codehaus.org/browse/MNG-1601 Project: Maven 2 Type: Bug Components: maven-deploy-plugin Reporter: Jorg Heymans Even though i've specified pscp and plink in settings.xml, the deploy plugin still seems to use scp , this is only the case for retrieving previous metadata though, the deploy executes successfully otherwise. [INFO] Retrieving previous metadata from [EMAIL PROTECTED] Executing command: scp -i . removed parameters for safety reasons/ [WARNING] project information for avalon-logkit 2.1 could not be retrieved from repository : [EMAIL PROTECTED] due to an error: Exit code: 1 - 'scp' is not recognized as an internal or external command,operable program or batch file. [INFO] Repository '[EMAIL PROTECTED]' will be blacklisted I'm using a snapshot version of wagon-ssh-external : wagon-ssh-external-1.0-alpha-6-20051116.003838-3.jar The whole process is also incredibly slow, 2.5 minutes to deploy a 40k artifact. (windows xp), I'll test it on linux with native ssh. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1602) deploy plugin leaves unnecessary information in the deployed pom.xml
deploy plugin leaves unnecessary information in the deployed pom.xml Key: MNG-1602 URL: http://jira.codehaus.org/browse/MNG-1602 Project: Maven 2 Type: Improvement Components: maven-deploy-plugin Reporter: Jorg Heymans ideally, during deployment, the deployed pom should be stripped of elements like build and distributionManagement IRC log : jorgCan someone enlighten me here : when i deploy an artifact (m2), why does the deployed plugin contain the build and distributionmanagement elements ? jorgs/plugin/artifact/ jorgsurely these elements are only relevant to the deployer ? jesse in the pom that is in the jar? jorgno the one that is deployed alongside the jar jorgshall I jira this ? jesse hm, I think that is a bug similar to the one with stuff in the META-INF/maven file too jorgyeah that's what i figured too jesse might as well bug it jdcasey jorg: we're not cleaning up that pom at all, just sending it on...but it's a good point jorgjdcasey: you mean about the maven version ? jdcasey I mean about the build/distributionManagement stuff...or anything that makes it into the POM that's deployed jorgoh ok , yup i think the pom should be stripped of anything not dependency related jorgi'm using deploy plugin v2.0 jdcasey I think I agree that it should be stripped of the functional parts of the POM, but not the informational stuff...it will allow us to make a richer map of project info if we leave that stuff in jorgjdcasey: yes thinking of it that's what i meant .. anything build or deploy related can go jdcasey don't ask *how this got here, it just did. ;-) jorghehe exactly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1543) pom.xml information automatically included in META-INF during jar
pom.xml information automatically included in META-INF during jar
--
Key: MNG-1543
URL: http://jira.codehaus.org/browse/MNG-1543
Project: Maven 2
Type: Improvement
Components: maven-jar-plugin
Versions: 2.0
Reporter: Jorg Heymans
The jar plugin automatically adds a pom.xml in META-INF, which makes sense. But
this pom.xml also contains local paths ie
build
sourceDirectoryd:\src\excalibur-trunk\framework\api\src\java/sourceDirectory
scriptSourceDirectorysrc/main/scripts/scriptSourceDirectory
testSourceDirectoryd:\src\excalibur-trunk\framework\api\src\test/testSourceDirectory
outputDirectoryd:\src\excalibur-trunk\framework\api\target\classes/outputDirectory
testOutputDirectoryd:\src\excalibur-trunk\framework\api\target\test-classes/testOutputDirectory
resources
resource
targetPathMETA-INF/targetPath
directoryd:\src\excalibur-trunk\framework\api\..\../directory
includes
includeLICENSE.txt/include
includeNOTICE.txt/include
/includes
/resource
/resources
testResources
testResource
directoryd:\src\excalibur-trunk\framework\api\src\test\resources/directory
I don't see how this information could be useful to anyone else, and i'ld
rather not have my local paths in distribution jars - call me paranoid :)
Conversation log from IRC :
jorgis there a way to tell maven not to include the pom.xml in
META-INF when creating jars ?
jesse hm, not that I know of
jesse might be a boolean to control it in there somewhere
jorgi looked at the jar plugin config .. didn't seem like it
jorgit's not a real problem, just funny that this is done by default
jesse I don't know, it makes it easier down the road to have
automated things interrogate the jar for dependencies of the things inside
trygvis yeah, you're right there jesse
jorgmmm well yes that makes sense ...
jorgthanks !
trygvis jorg: it's useful for the application itself
trygvis like reading out the version number from pom.properties
jorgtrygvis: yes, but the pom also had my local paths in it for
sourceDirectory and stuff, that's why i found it a bit strange
trygvis makes it easier making versioning-aware application and gives a
thigh integration with your project management tool (aka maven)
trygvis hm
trygvis that should possibly be changed indeed
trygvis File properties should be made relative to ${basedir} again
trygvis when writing out the pom that is
jorgi can understand about the dependencies , but the build
configuration probably shouldn't be in there
jorg
directoryd:\src\excalibur-trunk\framework\api\..\../directory
trygvis jorg: file an issue, it should be relative to ${basedir} if
there at all
trygvis IMO the build parts of a pom could be stripped from the repo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1428) svn authentication fails during release:prepare
svn authentication fails during release:prepare --- Key: MNG-1428 URL: http://jira.codehaus.org/browse/MNG-1428 Project: Maven 2 Type: Bug Components: maven-release-plugin Versions: 2.0 Reporter: Jorg Heymans I have a problem getting maven to authenticate against the SVN repository. The pom i try to execute is here : http://svn.apache.org/repos/asf/cocoon/whiteboard/maven2/cocoon-flat-layout/pom.xml command output : [INFO] [release:prepare] [INFO] What tag name should be used? 2.2.0 [INFO] Verifying there are no local modifications ... [INFO] Checking lineage for snapshots ... [INFO] Checking dependencies for snapshots ... [INFO] Checking plugins for snapshots ... [INFO] What is the release version for 'apache-cocoon:cocoon'? [2.2] 2.2.1 [INFO] Checking in modified POMs Provider message: The svn command failed. Command output: svn: Commit failed (details follow): svn: CHECKOUT of '/repos/asf/!svn/ver/330830/cocoon/whiteboard/maven2/cocoon-flat-layout/p om.xml': authorization failed (https://svn.apache.org) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An error is occurred in the checkin process. Embedded error: Error! [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 27 seconds [INFO] Finished at: Fri Nov 04 17:03:32 CET 2005 [INFO] Final Memory: 3M/6M [INFO] I have write access to the repository, I can commit using commandline svn without having to give username or password. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1429) release.properties should be removed between (failed) release runs
release.properties should be removed between (failed) release runs -- Key: MNG-1429 URL: http://jira.codehaus.org/browse/MNG-1429 Project: Maven 2 Type: Bug Components: maven-release-plugin Versions: 2.0 Reporter: Jorg Heymans I spent too much time trying to find out why maven wasn't accepting my scm urls : 1) enter invalid scm url in pom 2) run maven release:prepare, it fails - release.properties is created nevertheless 3) correct scm url in pom 4) rerun maven release:prepare - updated pom values are ignored. the solution is to manually delete release.properties to force a reread of the pom. If you don't realize this file is being created , you're in for a long and frustrating search :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1276) warning too verbose for invalid poms
[ http://jira.codehaus.org/browse/MNG-1276?page=comments#action_49889 ] Jorg Heymans commented on MNG-1276: --- minor nitpick - does not appear to be valid could be shortened to is invalid I don't know why you insist on the newlines here : getLogger().debug( \n\nReason: + e.getMessage() + \n\n ); thanks for looking into this. warning too verbose for invalid poms Key: MNG-1276 URL: http://jira.codehaus.org/browse/MNG-1276 Project: Maven 2 Type: Improvement Versions: 2.0 Reporter: Jorg Heymans Assignee: Edwin Punzalan Fix For: 2.0.1 Attachments: MNG-1276-maven-project.patch Basically , per module we get about 10-15 of these flying by : [WARNING] POM for: 'avalon-logkit:avalon-logkit:pom:2.1' does not appear to be valid. Its will be ignored for artifact resolution. Reason: Invalid POM (not v4.0.0 modelVersion) We have 65 modules, i'm sure you get the picture :-) see also http://article.gmane.org/gmane.comp.jakarta.turbine.maven.user/28826 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1329) duplicate project references
duplicate project references Key: MNG-1329 URL: http://jira.codehaus.org/browse/MNG-1329 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0 Reporter: Jorg Heymans eclipse:eclipse generates duplicate project references for following pom dependencies dependency groupIdapache-cocoon/groupId artifactIdcocoon-core/artifactId version2.2-SNAPSHOT/version /dependency dependency groupIdapache-cocoon/groupId artifactIdcocoon-core/artifactId version2.2-SNAPSHOT/version classifiertests/classifier /dependency The classifier should be taken into account. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1330) direct support for mock classes
direct support for mock classes --- Key: MNG-1330 URL: http://jira.codehaus.org/browse/MNG-1330 Project: Maven 2 Type: New Feature Versions: 2.0 Reporter: Jorg Heymans a mockSourceDirectory element of some sort would allow projects to easily deal with mock classes. At the moment you would have to create a separate module myproject-mocks and include it as a dependency in your project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1331) dealing with licenses
dealing with licenses - Key: MNG-1331 URL: http://jira.codehaus.org/browse/MNG-1331 Project: Maven 2 Type: New Feature Versions: 2.0 Reporter: Jorg Heymans Priority: Minor maven could offer a configurable way to include project licenses in the jar, briefly discussed on IRC today jorgdoes m2 have anything built-in to deal with library licenses ? just wondering ... kenney license tag in the pom is all I think jorgah yep, i knew I saw something about it somewhere, tnx kenney kenney and just distribute poms for non-freely-distributable jars (like the sun ones), stating where you can download/purchase them jorgmmm Typically the licenses listed for the project are that of the project itself, and not of dependencies. jorgok so unless all our dependencies are good maven citizens this won't really work ... jorgno prob, we'll just include them ourselves then kenney do you have to? kenney if people distribute a jar/pom without a license, it's their fault jorgwell we (cocoon) have always done so jorgthat's true though , it's up to them to include them trygvis I think people are a bit slack when it comes to adding that information jorgdefinitely kenney what about the bundle upload system? jorgthat's why i was hoping for maven to be able enforce something trygvis we should probably start to enumerate the various licenses and give them IDs instead kenney bundles have to have a LICENSE file.. where does that go? trygvis not sure, ask carlos kenney yeah or maybe extend the license tag to name the license (ASL-2.0) and the online-url, or alternatively list the license content itself.. or just add a bla-X-LICENSE.txt on ibiblio per project jorgsomething like that yeah, and perhaps offering a configurable way of having the license file included in the jar ? jorgor is that a hairy legal thing maven shouldn't get into ? trygvis kenney: the name there (ASL-2.0) would be the id trygvis jorg: good idea jorgit would certainly advocate , albeit rather enforced, correct usage of libraries -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1315) Inheritance guid
Inheritance guid Key: MNG-1315 URL: http://jira.codehaus.org/browse/MNG-1315 Project: Maven 2 Type: Improvement Components: documentation Versions: 2.0 Reporter: Jorg Heymans Priority: Minor It would be nice to have a guide on pom inheritance : - what is inheritance and when to use it. - explains the difference between a pom as dependency and as parent. - note the pom elements that are inherited from the parent to the child, as not all of them are -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1276) warning too verbose for invalid poms
[ http://jira.codehaus.org/browse/MNG-1276?page=comments#action_49221 ] Jorg Heymans commented on MNG-1276: --- I'ld be happy with a -DWarnInvalidPoms=false of some sort. Alternatively, you could create a separate logging category for this and redirect it to invalidpoms.log, that way people can more easily report them by just sending you guys this file. warning too verbose for invalid poms Key: MNG-1276 URL: http://jira.codehaus.org/browse/MNG-1276 Project: Maven 2 Type: Improvement Versions: 2.0 Reporter: Jorg Heymans Assignee: Edwin Punzalan Fix For: 2.0.1 Basically , per module we get about 10-15 of these flying by : [WARNING] POM for: 'avalon-logkit:avalon-logkit:pom:2.1' does not appear to be valid. Its will be ignored for artifact resolution. Reason: Invalid POM (not v4.0.0 modelVersion) We have 65 modules, i'm sure you get the picture :-) see also http://article.gmane.org/gmane.comp.jakarta.turbine.maven.user/28826 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1282) configured directory permissions ignored
configured directory permissions ignored Key: MNG-1282 URL: http://jira.codehaus.org/browse/MNG-1282 Project: Maven 2 Type: Bug Components: maven-deploy-plugin Versions: 2.0 Reporter: Jorg Heymans I've specified directoryPermissions0775/directoryPermissions in settings.xml for a server. However during deployment, maven creates them with 0755, which is the default for that directory. Filepermissions (eg filePermissions0664/filePermissions) on the other hand are honoured. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1282) configured directory permissions ignored
[ http://jira.codehaus.org/browse/MNG-1282?page=comments#action_49060 ] Jorg Heymans commented on MNG-1282: --- forgot to say : scp is used as provider configured directory permissions ignored Key: MNG-1282 URL: http://jira.codehaus.org/browse/MNG-1282 Project: Maven 2 Type: Bug Components: maven-deploy-plugin Versions: 2.0 Reporter: Jorg Heymans I've specified directoryPermissions0775/directoryPermissions in settings.xml for a server. However during deployment, maven creates them with 0755, which is the default for that directory. Filepermissions (eg filePermissions0664/filePermissions) on the other hand are honoured. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1276) warning too verbose for invalid poms
warning too verbose for invalid poms Key: MNG-1276 URL: http://jira.codehaus.org/browse/MNG-1276 Project: Maven 2 Type: Improvement Versions: 2.0 Reporter: Jorg Heymans Basically , per module we get about 10-15 of these flying by : [WARNING] POM for: 'avalon-logkit:avalon-logkit:pom:2.1' does not appear to be valid. Its will be ignored for artifact resolution. Reason: Invalid POM (not v4.0.0 modelVersion) We have 65 modules, i'm sure you get the picture :-) see also http://article.gmane.org/gmane.comp.jakarta.turbine.maven.user/28826 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1234) binary resources
binary resources Key: MNG-1234 URL: http://jira.codehaus.org/browse/MNG-1234 Project: Maven 2 Type: Bug Components: maven-archetype-plugin Versions: 2.0 (RC) Environment: xp Reporter: Jorg Heymans As described here http://article.gmane.org/gmane.comp.jakarta.turbine.maven.user/28710 , the archetype plugin fails to recognize binary files from text files for template substitution. [ERROR] ResourceManager.getResource() parse exception: org.apache.velocity.exception.ParseErrorException: Lexical error: org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 44, column 36. Encountered: EOF after : Is defining binary resources disallowed ? I can upload the created archetype if necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
