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
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
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
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
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
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
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,
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:
>
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
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
+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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
--
---
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
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
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
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
...
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
--
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
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
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.
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
51 matches
Mail list logo