MASSEMBLY-121: fix does not work for me.

2007-01-30 Thread berndq
John Casey wrote: As for MASSEMBLY-121, could you reopen it and add a test case that is failing? I'll try to take another stab at it, if I can see what's failing. I added a test, can someone please verify if the test is valid? I can not re-open it (not priviliges for me?) Can someone do that

Re: Feature request: per-module local version in profile

2007-01-30 Thread Ralph Goers
Mark Lundquist wrote: no, of course not... nevertheless, SNAPSHOT is only meaningful in relation to a remote repository, right? I don't really understand why you'd say that. It indicates that this is an unreleased version. Whether it is in your local repository or a remote repository doesn't

Re: [Archiva] Comment on Local Repository Format Reading for DefaultMetadataDiscoverer

2007-01-30 Thread Brett Porter
would they use this against an index on their local repository, or by querying a remote archiva instance? I do think we need to index the local metadata anyway so that the code can be used from other tools. - Brett On 31/01/2007, at 3:37 PM, Ole Ersoy wrote: Hi, I'm going through the De

[Archiva] Comment on Local Repository Format Reading for DefaultMetadataDiscoverer

2007-01-30 Thread Ole Ersoy
Hi, I'm going through the DefaultMetadataDiscoverer, and noticed this todo: * @todo Note that only the remote format is supported at this time: you cannot search local repository metadata due * to the way it is later loaded in the searchers. Review code using pathOfRemoteMetadata. IS th

Re: Request Maven 2.1 New Phase - reporting-aggregate

2007-01-30 Thread Franz Allan Valencia See
Good day, * What would be the main difference between the reporting phase(s) and the site phases? the former are for reports while the latter are for the documentation? What about reports about the documentation? * As for when, maybe it should be before packaging so that users will have the optio

Re: Feature request: per-module local version in profile

2007-01-30 Thread Mark Lundquist
Hi Ralph, Ralph Goers wrote: Mark Lundquist wrote: IIUC, SNAPSHOT is concerned w/ the relationship btwn. remote and local repositories. That's not in view here. Huh? SNAPSHOT identifies an artifact as not-released. There is no requirement that it ever be published to a remote reposito

Re: [PROPOSAL] maven-build-context (Shared context for Maven components and plugins)

2007-01-30 Thread John Casey
As it stands now, I haven't made any real accommodation for scoping, beyond project-specific vs. build-global (there is no inter-build scope for embedded applications, afaik). However, right now the subject of scoping is a little undefined. That's what this thread is for. :-) -john On 1/30/07,

Re: [PROPOSAL] maven-build-context (Shared context for Maven components and plugins)

2007-01-30 Thread John Casey
That's true, this could be a vehicle for sharing toolchain information. On 1/30/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: an inmediate application would be to share JDK versions between compiler and other plugins like PMD, checkstyle,... On 1/30/07, John Casey <[EMAIL PROTECTED]> wrote: >

Re: [PROPOSAL] Standard Reporting

2007-01-30 Thread Garvin LeClaire
Joakim, I think that is a good idea. I have thought about this also when I was working on the Findbugs plug-in. I think this would faciliate a more effective way to do dashboard type reports. I was thinking about developing a Doxia JDBCWriter for Plugins to use. I would like to have the ability

Re: [PROPOSAL] Maven 2.1 assembly type.

2007-01-30 Thread Brett Porter
This sort of thing can be addressed in the assembly plugin itself (though it requires true which is a bit gross, but hopefully we can fix that in 2.1 anyway). I've thought about this before, but stumbled on the 'which type' question. I think the real solution to this is to have plugins pr

RE: [PROPOSAL] Maven 2.1 assembly type.

2007-01-30 Thread Brian E. Fox
+1. We do this a lot and fortunately we don't have a lot of cases where those zip files are actual dependencies. I believe there is already a jira filed for a "zip" packaging type. -Original Message- From: Joakim Erdfelt [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 30, 2007 6:31 PM To

Re: [PROPOSAL] Maven 2.1 element

2007-01-30 Thread Brett Porter
This has already been discussed - some stuff on this list, and stuff called 'toolchain support' on the wiki, and I think Jason even checked in some code at some point as a starting point. - Brett On 31/01/2007, at 10:25 AM, Joakim Erdfelt wrote: I'd like to see a element in the next genera

[PROPOSAL] Maven 2.1 assembly type.

2007-01-30 Thread Joakim Erdfelt
The assembly plugin has proven to be very valuable, and used very often. Can we create a new type for "assembly" that defaults a set of values, and even provides standard artifact resolution during the normal process. Motivation is to have artifacts that are bundled/attached/assembled during you

[PROPOSAL] Maven 2.1 element

2007-01-30 Thread Joakim Erdfelt
I'd like to see a element in the next generation pom that can be used to specify the desired platform for this build. I see this working in a similar way to the element, but be more appropriate. How I see this working... Java:: 1.5 This would be a signal for the maven client to look for

Re: repository id vs repository url

2007-01-30 Thread Brett Porter
I'm just thinking about this now. I much prefer the 'specify the path' approach and was thinking of dumping the magic ID's and just referencing by name in the webapp and using an internal identifier instead. Much the same as I've been thinking of dumping from Maven itself. I'll get back

repository id vs repository url

2007-01-30 Thread Joakim Erdfelt
I'm the one responsible for the misguided repository.urlName concept. It's biting me in the butt now, but I still feel strongly enough to keep it as a concept. My justification. 1) Makes the repository snippet make sense. 2) Makes URLs nice and clean. 3) Allows future work to auto-adjust pom-int

Re: Request Maven 2.1 New Phase - reporting-aggregate

2007-01-30 Thread Jason Dillon
Maybe for consistency having: generate-reports (for all those that haven't executed yet) process-reports (could aggregate them here) ... just before the package phase? (Or maybe later, before install, after integration test). I think moving more towards having these as part of a standard bu

[PROPOSAL] Standard Reporting

2007-01-30 Thread Joakim Erdfelt
There are many reports and plugins now that generate reports against the code. I'd like to see an entire framework built around the concept of Standardized Reporting. The components of this framework... maven-reporting-datapoint This would provide an API that various reporting plugins (checks

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Stephen Duncan
Yep, I've had it work with dav:https:// using Apache mod_webdav -Stephen On 1/30/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: Graham Leggett a écrit : > On Tue, January 30, 2007 3:49 pm, Aaron Digulla wrote: > >> I'm using wagon-webdav 1.0-beta-2 with maven-deploy-plugin 2.3 >> together wi

Re: Request Maven 2.1 New Phase - reporting-aggregate

2007-01-30 Thread Brett Porter
I think that makes sense. I wouldn't go with post-reporting, though, as there is no 'reporting' phase - they happen when it's appropriate (process-sources, test, etc). Maybe for consistency having: generate-reports (for all those that haven't executed yet) process-reports (could aggregate the

Request Maven 2.1 New Phases - pre-test and post-test

2007-01-30 Thread Joakim Erdfelt
A set of phases I really would have liked to have seen when working on cobertura is the ability to hook into testing process before and after. pre-test being the most important. I think these phases could be useful for any plugin that monitors / instruments the testing process. What do you think?

Request Maven 2.1 New Phase - reporting-aggregate

2007-01-30 Thread Joakim Erdfelt
I'd like to see a discussion start on adding the possibility of a new phase into the default lifecycle. A reporting-aggregate that executes at the end of all standard reports. (Could also call it post-reporting) I can see the Dashboard Report, QA Labs, and even a standard reporting framework util

Re: [PROPOSAL] maven-build-context (Shared context for Maven components and plugins)

2007-01-30 Thread Carlos Sanchez
an inmediate application would be to share JDK versions between compiler and other plugins like PMD, checkstyle,... On 1/30/07, John Casey <[EMAIL PROTECTED]> wrote: One important thing to remember is that this is a build-time context, not a database or other type of persistent storage. If you w

Re: [PROPOSAL] maven-build-context (Shared context for Maven components and plugins)

2007-01-30 Thread Scott Lewis
I think this is a very useful proposal...particularly for supporting use cases around runtime construction/modification of model (Wendell's comments). But is there any scoping mechanism in plexus and/or maven? Or would the shared context always be 'global' for all of maven + plugins? I'm of

Re: Piping commons-logging into Maven log

2007-01-30 Thread Mark Hobson
Hi Aaron, On 30/01/07, Aaron Digulla <[EMAIL PROTECTED]> wrote: This should be an FAQ but I couldn't find anything: How do I connect a dependency of a mojo which uses commons-logging to the Maven logging? In my case, I'm using the jasperreports mojo which uses the jasperreports JARs which depen

Re: [PROPOSAL] maven-build-context (Shared context for Maven components and plugins)

2007-01-30 Thread John Casey
Sorry, Brian...my comment was aimed at Jason Dillon. :-) Yes, I agree that the plugin in charge of something like compilation should be able to inform the rest of the build as to whether or not that action really took place. I think that sort of thing could lead to a build short-circuiting and st

Re: [PROPOSAL] maven-build-context (Shared context for Maven components and plugins)

2007-01-30 Thread Jesse McConnell
yep, I like the way that train of thought is going...:) On 1/30/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: Yes, understood. However, only the compiler plugin would be able to know if during this run anything was actually compiled. If it communicated that somewhere, then other plugins could make

RE: [PROPOSAL] maven-build-context (Shared context for Maven components and plugins)

2007-01-30 Thread Brian E. Fox
Yes, understood. However, only the compiler plugin would be able to know if during this run anything was actually compiled. If it communicated that somewhere, then other plugins could make decisions. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 30,

Re: Confirm: Webdav and SSL works

2007-01-30 Thread Emmanuel Venisse
http://docs.codehaus.org/display/HAUSMATES/WebDAV or with the InstallCert class : http://blogs.sun.com/andreas/entry/no_more_unable_to_find Emmanuel Joakim Erdfelt a écrit : Thanks! Do you happen to know of a URL that demonstrates how to add the CA or SSL certs to teh cacerts keystore, I'd li

Re: Extending the notion of "parent pom"

2007-01-30 Thread John Casey
Hi Aaron, While I can't say you're the first person I've heard mention mixins in connection with Maven, I'd really like to hear more about the environment you've put together. For starters, you seem to have two "type-specific" POMs - one for webapps, one for libraries - that presumably setup the

Re: Confirm: Webdav and SSL works

2007-01-30 Thread Thomas Recloux
Hello all, Do you happen to know of a URL that demonstrates how to add the CA or SSL certs to teh cacerts keystore, I'd like to get that documented, and link to the 'how-to' documents for that process. Is this doc OK ? http://maven.apache.org/guides/mini/guide-repository-ssl.html -- Thomas Rec

Re: [PROPOSAL] maven-build-context (Shared context for Maven components and plugins)

2007-01-30 Thread John Casey
One important thing to remember is that this is a build-time context, not a database or other type of persistent storage. If you wanted to detect farthest-progress between builds, you'd have to look in some other place (maybe a file, or just a timestamp comparison of the end-product artifact vs. t

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Joakim Erdfelt
There is plenty of work done to create the collections (one at a time, in order) in order to perform a PUT request. What dav server are you using when you got this error? The HTTP Response 500 is the likely culprit here. - Joakim Graham Leggett wrote: > Hi all, > > As a test I have configured t

Re: Confirm: Webdav and SSL works

2007-01-30 Thread Joakim Erdfelt
Thanks! Do you happen to know of a URL that demonstrates how to add the CA or SSL certs to teh cacerts keystore, I'd like to get that documented, and link to the 'how-to' documents for that process. - Joakim Graham Leggett wrote: > Hi all, > > In the source file at > https://svn.apache.org/repos

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Emmanuel Venisse
Graham Leggett a écrit : On Tue, January 30, 2007 3:49 pm, Aaron Digulla wrote: I'm using wagon-webdav 1.0-beta-2 with maven-deploy-plugin 2.3 together with Archiva (SVN SNAPSHOT build). Before 1.0-beta-2/2.3, this was pretty unstable (every 3rd deploy would fail) but now, it works pretty goo

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Graham Leggett
On Tue, January 30, 2007 3:49 pm, Aaron Digulla wrote: > I'm using wagon-webdav 1.0-beta-2 with maven-deploy-plugin 2.3 > together with Archiva (SVN SNAPSHOT build). Before 1.0-beta-2/2.3, > this was pretty unstable (every 3rd deploy would fail) but now, it > works pretty good (even though I still

Confirm: Webdav and SSL works

2007-01-30 Thread Graham Leggett
Hi all, In the source file at https://svn.apache.org/repos/asf/maven/wagon/tags/wagon-1.0-beta-2/wagon-providers/wagon-webdav/src/main/java/org/apache/maven/wagon/providers/webdav/WebDavWagon.java, the following comment is present: TODO: webdav https server is not tested I have tested the wagon

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Aaron Digulla
Quoting Graham Leggett <[EMAIL PROTECTED]>: Can anyone confirm whether this plugin has ever worked for them, and if so, what DAV server is being used? I am using httpd v2.0.52 as shipped default with RHEL4. I'm using wagon-webdav 1.0-beta-2 with maven-deploy-plugin 2.3 together with Archiva

Extending the notion of "parent pom"

2007-01-30 Thread Aaron Digulla
Hello, My POMs have two parents: The one in the parent directory and the one which supplies them with the build defaults. Out of necessity, they can't be the same POM. The ../pom.xml just specifies the build order. The POM specified with the element supplies the build config (for example

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Graham Leggett
On Tue, January 30, 2007 3:08 pm, Aaron Digulla wrote: > The simple workaround would be to create the directories manually > until the bug is fixed. I created each directory manually, up to and including the version number. Once all the directories existed, the return code from wagon-webdav was

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Graham Leggett
On Tue, January 30, 2007 3:08 pm, Aaron Digulla wrote: > You do see the correct version in the output of Maven? I saw maven download the v1.0-beta-2 jars and dependencies. > The simple workaround would be to create the directories manually > until the bug is fixed. Unfortunately the end result

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Graham Leggett
On Tue, January 30, 2007 3:09 pm, Aaron Digulla wrote: > Which version of the maven-deploy-plugin do you use? Have you tried 2.3? Yes (both natively as it's the latest release, and explicitly by adding it to the pom) - made no difference. Regards, Graham -- ---

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Aaron Digulla
Quoting Graham Leggett <[EMAIL PROTECTED]>: Have you tried with 1.0-beta-2 of wagon-webdav? This solved some problems for me. Which version of the maven-deploy-plugin do you use? Have you tried 2.3? Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limi

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Aaron Digulla
Quoting Graham Leggett <[EMAIL PROTECTED]>: On Tue, January 30, 2007 1:55 pm, Aaron Digulla wrote: Have you tried with 1.0-beta-2 of wagon-webdav? This solved some problems for me. Added the 1.0-beta-2 of wagon-webdav like this: org.apache.maven.wagon wagon-we

deploy:deploy-file target and DAV

2007-01-30 Thread Graham Leggett
Hi all, As a test I have configured the maven deploy:deploy-file goal to deploy to a WebDAV server. The login and ssl part works fine, but the attempt to PUT the file fails with a 403 response code (but not because of auth failure according to the logs). It looks like the plugin is not making an

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Graham Leggett
On Tue, January 30, 2007 1:55 pm, Aaron Digulla wrote: > Have you tried with 1.0-beta-2 of wagon-webdav? This solved some > problems for me. Added the 1.0-beta-2 of wagon-webdav like this: org.apache.maven.wagon wagon-webdav 1.0-beta-2 ...

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Graham Leggett
On Tue, January 30, 2007 1:55 pm, Aaron Digulla wrote: > Have you tried with 1.0-beta-2 of wagon-webdav? This solved some > problems for me. Dumb question... how do you override the dependency of a plugin? Regards, Graham --

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Graham Leggett
On Tue, January 30, 2007 1:55 pm, Aaron Digulla wrote: > Have you tried with 1.0-beta-2 of wagon-webdav? This solved some > problems for me. Not yet - I am trying to do this without a pom file (the artifacts are ultimately matlab generated). Seems creating a pom is the way to go. Will try it and

Piping commons-logging into Maven log

2007-01-30 Thread Aaron Digulla
Hello, This should be an FAQ but I couldn't find anything: How do I connect a dependency of a mojo which uses commons-logging to the Maven logging? In my case, I'm using the jasperreports mojo which uses the jasperreports JARs which depend on commons-logging. Since nothing is specified, c

Re: deploy:deploy-file target and DAV

2007-01-30 Thread Aaron Digulla
Quoting Graham Leggett <[EMAIL PROTECTED]>: It looks like the plugin is not making an attempt to create the directories in the repository before trying to upload the file to the repository, thus the failure: Have you tried with 1.0-beta-2 of wagon-webdav? This solved some problems for me.

deploy:deploy-file target and DAV

2007-01-30 Thread Graham Leggett
Hi all, As a test I have configured the deploy:deploy-file goal to deploy to a WebDAV server. The login and ssl part works fine, but the attempt to PUT the file fails with a 403 response code (but not because of auth failure according to the logs). It looks like the plugin is not making an attemp