On 5 July 2017 at 04:31, wrote:
> Repository: maven-wagon
> Updated Branches:
> refs/heads/master 3464da867 -> dfadb0b78
>
>
> [WAGON-488] Upgrade WebDAV Wagon to a more recent HttpClient version
> Fix checkstyle reported errors
>
>
> Project: http://git-wip-us
Github user michael-o commented on the issue:
https://github.com/apache/maven-wagon/pull/18
One could also consider merging both and differentiate only by the URL, if
this is possible.
---
If your project is set up for it, you can reply to this email and have your
reply appear on Git
Github user michael-o commented on the issue:
https://github.com/apache/maven-wagon/pull/18
Is this a complete replacement for Jackrabbit for the Wagon provider?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your pro
Subject says it all. Deployment fails PUTting to non-existent
directories with HTTP 409. Is it correct that deploying to a WebDAV
enabled Apache httpd can only be done by updating the local Maven
installation adding support for WebDAV like
$ ls -lah lib/ext/
total 1492
drwxr-xr-x 2 schulte
ut instead DAV Wagon threw CNFEx... (but it
> did kick in).
>
> Actually, this is in line with maven 3.0.4, as it behaves the same.
>
> In both cases commons logging LogFactory class was missing, but I have no
> clue from where it should come, as from wagon-webdav POM it's se
Hi Arnaud,
I could not reproduce this, but instead DAV Wagon threw CNFEx... (but it
did kick in).
Actually, this is in line with maven 3.0.4, as it behaves the same.
In both cases commons logging LogFactory class was missing, but I have no
clue from where it should come, as from wagon-webdav
Hi,
I tried to use the wagon-webdav-jackrabbit 2.5 instead of 2.4 and Maven
(3.1.0) doesn't like it
org.apache.maven.wagon
wagon-webdav-jackrabbit
${version.wagon}
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @
maven-paren
It also covers
> all the PGP concerns people have and the WebDAV client is also built
> in. I'll bring this up on a separate thread. I've made branches for
> trunk and 2.2, but if we're going to be debugging and fixing things we
> might as well do it with what
If we are just tossing in brand new technology into 2.1 I think we
should just put Mercury into 2.1. It has a _lot_ of tests and is
actively being worked on by 5 people in the community. It also covers
all the PGP concerns people have and the WebDAV client is also built
in. I'll bring
Sorry, that bug is my fault. Ill try to get this fixed for milestone 2.
James
On Thu, 2008-09-25 at 12:54 -0400, John Casey wrote:
> Ugh. I guess we knew this was a risk when we decided to go with wagon
> beta-4...it's a good thing this was just a milestone release, eh? :-)
>
> I posted a comme
Ugh. I guess we knew this was a risk when we decided to go with wagon
beta-4...it's a good thing this was just a milestone release, eh? :-)
I posted a comment, but it's probably more procedural than anything,
since many of the same people are involved between the wagon project and
the deploy-p
Hi there,
Thought I'd best highlight a regression I've found with 2.1.0-M1 after
all the hard work John put in to mitigate them:
http://jira.codehaus.org/browse/MDEPLOY-85
Cheers,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTE
2.0.10-RC branch to
using 1.0-beta-2 of wagon, including the user-agent changes. I also
tried to enable (and make work) the IT for MNG-3599 using wagon 1.0-
beta-2 and wagon-webdav (instead of the jackrabbit impl), but I'm
running into trouble.
The problem seems to be in the way
to enable (and make work) the IT for MNG-3599 using wagon 1.0-beta-2
and wagon-webdav (instead of the jackrabbit impl), but I'm running
into trouble.
The problem seems to be in the way slide is using httpclient[1].
Brett, did this work before we changed things to use 1.0-beta-3
2.0.10-RC branch to using
1.0-beta-2 of wagon, including the user-agent changes. I also tried to
enable (and make work) the IT for MNG-3599 using wagon 1.0-beta-2 and
wagon-webdav (instead of the jackrabbit impl), but I'm running into
trouble.
The problem seems to be in the way slide is usi
Hi everyone (and maybe especially Brett),
I took some time today and rolled back the 2.0.10-RC branch to using
1.0-beta-2 of wagon, including the user-agent changes. I also tried to
enable (and make work) the IT for MNG-3599 using wagon 1.0-beta-2 and
wagon-webdav (instead of the jackrabbit
>Unfortunately I think this has an unwanted side effect. Because you
>can only load an extension once in the build, it would mean if you
>wanted to override it, it would have to be in the root of the reactor
>build (or a parent of that). If you happen to declare it in the child,
>the super
On 29/03/2008, at 2:04 AM, John Casey wrote:
Here's a question:
Could we specify the wagon-webdav in the super-POM as a build
extension? Even if there are no project POMs in the current build,
the super POM should be built, right? Also, I would think (though
I'd have to inve
Hrm, if it allows overrides and still works for deploy:deploy-file, this
might be the safest approach.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Friday, March 28, 2008 11:04 AM
To: Maven Developers List
Subject: Re: Wagon changes and WebDAV
Here's a que
Here's a question:
Could we specify the wagon-webdav in the super-POM as a build
extension? Even if there are no project POMs in the current build,
the super POM should be built, right? Also, I would think (though I'd
have to investigate to be sure) that respecifying the wa
On 28/03/2008, at 9:41 PM, Brett Porter wrote:
I've taken a look at the code and found two problems:
a) the wagon in core was reverted to beta-1, which is probably the
root of James' problems. beta-2 corrects the redirects and has been
stable for some time. I presume this was an accident a
d
all its deps, or make your own shaded JAR which would be a pain in
the
ass.
(see full thread here:
http://www.nabble.com/Wagon-changes-and-WebDAV-td15743343s177.html)
So the above captures exactly the problem we are seeing now. James has
an issue with webdav that may require a fix. This is
and
>
> >all its deps, or make your own shaded JAR which would be a pain in the
>
> >ass.
>
> (see full thread here:
> http://www.nabble.com/Wagon-changes-and-WebDAV-td15743343s177.html)
>
> So the above captures exactly the problem we are seeing now. James ha
the
>ass.
(see full thread here:
http://www.nabble.com/Wagon-changes-and-WebDAV-td15743343s177.html)
So the above captures exactly the problem we are seeing now. James has
an issue with webdav that may require a fix. This is probably an
existing issue and is not core so it shouldn't
On 01/03/2008, at 11:30 AM, Jason van Zyl wrote:
Yes, I'm generally in favour of the proposal - it is how we've
always wanted it to work.
I'm just chucking out ideas.
Yep, I just meant in reference to not needing to distribute stuff in
the core.
- I don't see any point of putting
On 29-Feb-08, at 3:40 PM, Brett Porter wrote:
On 01/03/2008, at 9:02 AM, Jason van Zyl wrote:
Here's the direction I would like to go in:
http://docs.codehaus.org/display/MAVEN/URL-based+dynamic+loading+of+providers+for+artifact+retrieval+and+deployment
Full support for all types of transp
On 01/03/2008, at 9:02 AM, Jason van Zyl wrote:
Here's the direction I would like to go in:
http://docs.codehaus.org/display/MAVEN/URL-based+dynamic+loading+of+providers+for+artifact+retrieval+and+deployment
Full support for all types of transport for retrieval and deployment
in a standard
haded JAR which would be a pain
in the ass.
On 29-Feb-08, at 12:22 PM, Brian E. Fox wrote:
+1 to putting in on the url, that's a muuuch better solution and
works
for all wagons, not just webdav.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, February
On 29-Feb-08, at 12:22 PM, Brian E. Fox wrote:
+1 to putting in on the url, that's a muuuch better solution and works
for all wagons, not just webdav.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, February 29, 2008 2:25 PM
To: Maven Developers List
S
+1 to putting in on the url, that's a muuuch better solution and works
for all wagons, not just webdav.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, February 29, 2008 2:25 PM
To: Maven Developers List
Subject: Re: Wagon changes and WebDAV
On 28-F
se case is for deploy:deploy-file,
so (1) is not an option.
Dynamic collections have been there for a while. And why is
deploy:deploy-file a concern, and for webdav. This will be the case
for all providers. FTP deploy doesn't work out of the box either,
should be start adding everythi
On 28-Feb-08, at 4:04 PM, Brett Porter wrote:
I'm fine removing whatever you want from core once you can show me
the same use case working without it.
Not a problem, I'll roll it back and use the dynamic collections. I
don't want the core getting bloated out when it's not required.
>
> Plain PUT does not work if the directory doesn't exist yet. (That's part
> of the HTTP spec).
> You need something to create the directory (or "Collection" in WebDAV
> Terms), this is the MKCOL method.
>
> While it is true that FTP is also a provider,
an option.
Dynamic collections have been there for a while. And why is
deploy:deploy-file a concern, and for webdav. This will be the case
for all providers. FTP deploy doesn't work out of the box either,
should be start adding everything because they need a POM to use
deploy file with FT
On 29/02/2008, at 10:47 AM, Jason van Zyl wrote:
On 28-Feb-08, at 2:06 PM, Brett Porter wrote:
On 29/02/2008, at 8:45 AM, Jason van Zyl wrote:
Dynamic collections have been there for a while. And why is
deploy:deploy-file a concern, and for webdav. This will be the
case for all
On 28-Feb-08, at 2:06 PM, Brett Porter wrote:
On 29/02/2008, at 8:45 AM, Jason van Zyl wrote:
Dynamic collections have been there for a while. And why is
deploy:deploy-file a concern, and for webdav. This will be the case
for all providers. FTP deploy doesn't work out of the box e
On 29/02/2008, at 8:45 AM, Jason van Zyl wrote:
Dynamic collections have been there for a while. And why is
deploy:deploy-file a concern, and for webdav. This will be the case
for all providers. FTP deploy doesn't work out of the box either,
should be start adding everything be
ollections have been there for a while. And why is
deploy:deploy-file a concern, and for webdav. This will be the case
for all providers. FTP deploy doesn't work out of the box either,
should be start adding everything because they need a POM to use
deploy file with FTP. Probably not.
king before the
first alpha so that there's no regression in functionality.
3) Merging webdav into the main Wagon is a bad idea. Leave the
simple provider alone and the more complicated ones are easy to add
as dependencies or be loaded dynamically.
I assume you are referring to Joak
In general I think merging wagons together isn't a good idea. Lets keep
them simple and easy to support. The last thing we need is more unused
dependencies or worse, bugs in webdav affecting plain ol http.
--Brian
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
with the dynamic collections so
that's also not necessary to bind them in there.
3) Merging webdav into the main Wagon is a bad idea. Leave the simple
provider alone and the more complicated ones are easy to add as
dependencies or be loaded dynamically.
For 2.0.x I don't ca
On 7/8/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
On 7/8/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> that could be post 1.0 to mitigate risk
Please have a look at the proposed changes before considering it a risk.
I just meant that if it were a risk (as you said it changed the whole
s
On 7/8/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
that could be post 1.0 to mitigate risk
Please have a look at the proposed changes before considering it a risk.
Thanks,
Jochen
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manip
will depend on what changes are in the other ones. If we want to
shoot for 1.0 (that I think we should) then it's good to push the rc1,
but keeping in mind that 1.0 should follow in a couple of weeks if no
critical bugs are found
IMO, wagon-webdav is almosu unusable without proxy support. W
On 7/8/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
I'd like to see wheter it's feasible to release this wagon provider
separately as rc1, or wheter we have to release the entire wagon
stack.
IMO, wagon-webdav is almosu unusable without proxy support. Which
requires that W
Hi,
I recently fixed 2 bugs in wagon-webdav rc1-snapshot
that make it possible to use it with maven 2.1 and 2.0.6/2.0.7.
One bug was the addition of the omitted and required plexus-utils
dependency - the code directly uses it. Since 2.0.6, plexus-utils
is shaded and plugins and extensions are
Second is the assumption that "GET" requests are not webdav requests.
Some WebDav client implementations improperly use the "GET" request to
obtain file/folder information. (they should be using the various
xml/propget requests to obtain that list.)
We could likely make
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&#
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
> 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 against
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
On 26/01/2007, at 1:25 PM, Stephen Duncan wrote:
Brett, can I assume that setting the extension in a profile at least
prevent the issue from occurring when the profile is inactive?
Yes. I've also made some changes to 2.0.5 to put the dependencies in
a separate loader/container so it should
in 2.1 where the classloaders behave better.
- Brett
On 26/01/2007, at 10:27 AM, Stephen Duncan wrote:
> Any reason not to? I only see one webdav specific issue open:
> http://jira.codehaus.org/browse/WAGON-49 which doesn't seem to be a
> blocker to me. I'm using it as
There is an issue in MNG to include it, and I included in there the
reasons why we shouldn't.
We can probably do it in 2.1 where the classloaders behave better.
- Brett
On 26/01/2007, at 10:27 AM, Stephen Duncan wrote:
Any reason not to? I only see one webdav specific issue open:
Any reason not to? I only see one webdav specific issue open:
http://jira.codehaus.org/browse/WAGON-49 which doesn't seem to be a
blocker to me. I'm using it as a build extension currently, and it
works fine, and I plan to use webdav as our production distribution
tool soon. In order
On 04/01/2007, at 9:45 PM, Trygve Laugstøl wrote:
Brett Porter wrote:
The first time anyone fixes/changes anything in archiva, this will
start getting harder to keep in sync, so we should do it sooner
rather than later.
I'll try to get some time to do it sooner than later, but can't
pro
Brett Porter wrote:
The first time anyone fixes/changes anything in archiva, this will start
getting harder to keep in sync, so we should do it sooner rather than
later.
I'll try to get some time to do it sooner than later, but can't promise
anything.
One question though - if it was based o
wrote:
Hi
I wrote a Plexus webdav component based on some code from Archiva
that handles webdav requests which should be pretty much directly
usable in Archiva. I don't have the time to put it back in Archiva
right now but *might* get around to do it in the future, but I do
hope you&#x
We use http and https based repositories with wagon-webdav already.
I have no access to a proxy that does https to test that specific
functionality.
Can you assist?
If you mean a proxy serving an https webdav server => Yes
--
Thomas Recloux a.k.a Karmelitre
http://karmelitre.tartachuc.
We use http and https based repositories with wagon-webdav already.
I have no access to a proxy that does https to test that specific
functionality.
Can you assist?
- Joakim
Thomas Recloux wrote:
> Hello,
>
> I did not test this provider, but I'll soon have to use it.
>
> Do
Hello,
I did not test this provider, but I'll soon have to use it.
Does it support http/s proxy ?
Thomas
2006/12/7, Joakim Erdfelt <[EMAIL PROTECTED]>:
It's been a few months now, I would like to release Wagon WebDAV 1.0-beta-2.
There are some URL baseline bugs with creatio
+1
On 7 Dec 06, at 2:39 PM 7 Dec 06, Joakim Erdfelt wrote:
It's been a few months now, I would like to release Wagon WebDAV
1.0-beta-2.
There are some URL baseline bugs with creation of collections
present in
1.0-beta-1 that have been addressed in 1.0-beta-2-SNAPSHOT.
Usual +1/0-
It's been a few months now, I would like to release Wagon WebDAV 1.0-beta-2.
There are some URL baseline bugs with creation of collections present in
1.0-beta-1 that have been addressed in 1.0-beta-2-SNAPSHOT.
Usual +1/0-1 (72 hours)
- J
gt;> URL: http://svn.apache.org/viewvc?view=rev&rev=477764
>> Log:
>> upgrading to commons-logging to 1.1 to correct misleading classloader
>> exception from commons-logging 1.0.3
>>
>> Modified:
>> maven/wagon/trunk/wagon-providers/wagon-webdav/pom.xml
&g
wrote:
Author: joakime
Date: Tue Nov 21 09:30:39 2006
New Revision: 477764
URL: http://svn.apache.org/viewvc?view=rev&rev=477764
Log:
upgrading to commons-logging to 1.1 to correct misleading
classloader exception from commons-logging 1.0.3
Modified:
maven/wagon/trunk/wagon-providers/wag
iewvc?view=rev&rev=477764
Log:
upgrading to commons-logging to 1.1 to correct misleading
classloader exception from commons-logging 1.0.3
Modified:
maven/wagon/trunk/wagon-providers/wagon-webdav/pom.xml
Modified: maven/wagon/trunk/wagon-providers/wagon-webdav/pom.xml
URL: http://svn.a
Two questions:
Is the webdav wagon still under developement?
The web site for wagon in general seems sketchy, with a lot of broken links
and possibly erroneous information.
I'm working on a patch to allow the webdav wagon to authenticate to an
NTLM-authorized DAV resource.
Am I wasting my
-webdav 1.0-beta-1)
we want to keep them all in the same version (at least for
now) so it's more easy to update them in
projects that use them.
Emmanuel
Mike Perham a écrit :
Can you summarize why? Do they all have outstanding fixes
deserving of
a release? Or are you just keeping the
y root now (when I mounted the webdav dir using mount -t davfs2)
So probably a configuration issue..
Milos
On 6/16/06, Milos Kleint <[EMAIL PROTECTED]> wrote:
On 6/16/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
> Seems to be a connection problem : Caused by:
java
it doesn't work from home either. There are some released artifacts in
the mevenide's part of remote repository already that were created
before the beaver crash. These directories and files seem to be owned
by root now (when I mounted the webdav dir using mount -t davfs2)
So
On 6/16/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
Seems to be a connection problem : Caused by: java.net.UnknownHostException:
dav.codehaus.org
Do you have installed the certificate for codehaus?
http://docs.codehaus.org/display/HAUSMATES/WebDAV
Yes.
Do you have configure
Seems to be a connection problem : Caused by: java.net.UnknownHostException:
dav.codehaus.org
Do you have installed the certificate for codehaus?
http://docs.codehaus.org/display/HAUSMATES/WebDAV
Do you have configured your project correctly?
http://docs.codehaus.org/display/HAUSMATES/Maven
ed to create destination WebDAV
collection (directory):
/repository/mevenide/org/codehaus/mevenide/mevenide2-parent/1.2
dav.codehaus.org
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error
depl
+1
Emmanuel Venisse wrote:
I'd prefer to release all wagons.
We have actually three open issues that will be fixed in beta-2
Emmanuel
Emmanuel Venisse a écrit :
hi,
wagon-webdav providers works fine and it is required for some release
of mojo and plexus projects.
here my +1
Emm
+1
On 6/15/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
I'd prefer to release all wagons.
We have actually three open issues that will be fixed in beta-2
Emmanuel
Emmanuel Venisse a écrit :
> hi,
>
> wagon-webdav providers works fine and it is required for some r
+1
Vincent
2006/6/15, Emmanuel Venisse <[EMAIL PROTECTED]>:
I'd prefer to release all wagons.
We have actually three open issues that will be fixed in beta-2
Emmanuel
Emmanuel Venisse a écrit :
> hi,
>
> wagon-webdav providers works fine and it is required for some r
+1
> -Original Message-
> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 15, 2006 2:51 PM
> To: Maven Developers List
> Subject: Re: [vote] Release all wagons (was Re: [vote]
> Release wagon-webdav 1.0-beta-1)
>
> we want to keep them
h the same
version (1.0-beta-1)?
-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 15, 2006 9:22 AM
To: Maven Developers List
Subject: [vote] Release all wagons (was Re: [vote] Release
wagon-webdav 1.0-beta-1)
I'd prefer to release all wagons
AM
> To: Maven Developers List
> Subject: [vote] Release all wagons (was Re: [vote] Release
> wagon-webdav 1.0-beta-1)
>
> I'd prefer to release all wagons.
>
> We have actually three open issues that will be fixed in beta-2
>
t; To: Maven Developers List
> Subject: [vote] Release all wagons (was Re: [vote] Release
> wagon-webdav 1.0-beta-1)
>
> I'd prefer to release all wagons.
>
> We have actually three open issues that will be fixed in beta-2
>
--
On 6/15/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
I'd prefer to release all wagons.
We have actually three open issues that will be fixed in beta-2
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
I'd prefer to release all wagons.
We have actually three open issues that will be fixed in beta-2
Emmanuel
Emmanuel Venisse a écrit :
hi,
wagon-webdav providers works fine and it is required for some release of
mojo and plexus projects.
here my +1
Emm
+1
Been using it internally since it appeared.
Mark
On 15/06/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
+1
On 6/15/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
> hi,
>
> wagon-webdav providers works fine and it is required for some release of mojo
and plexus pro
On 6/15/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
> hi,
>
> wagon-webdav providers works fine and it is required for some release of mojo
and plexus projects.
>
> here my +1
+1
Won't you release the full wagon
+1
On 6/15/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
hi,
wagon-webdav providers works fine and it is required for some release of mojo
and plexus projects.
here my +1
Emmanuel
-
To unsubscribe, e-mail:
+1
managed to deploy the site for mevenide2 easily.
Milos
On 6/15/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
hi,
wagon-webdav providers works fine and it is required for some release of mojo
and plexus projects.
here my +1
Em
hi,
wagon-webdav providers works fine and it is required for some release of mojo
and plexus projects.
here my +1
Emmanuel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I had the same issue performing internal releases since we moved to
the webdav wagon, see:
http://www.mail-archive.com/users@maven.apache.org/msg42873.html
http://jira.codehaus.org/browse/MRELEASE-111
+1 for a webdav wagon release, it's working fine here for us.
Cheers,
Mark
On 14/
I think too it would be a good thing to do.
jerome lacoste a écrit :
Hi,
trying to release a mojo plugin, I am stuck because the Mojo root pom
depends on the 1.0-beta-1-SNAPSHOT wagon provider.
Apparently Jason said there was problem deploying, but I've deployed
sites and poms without issue th
Hi,
trying to release a mojo plugin, I am stuck because the Mojo root pom
depends on the 1.0-beta-1-SNAPSHOT wagon provider.
Apparently Jason said there was problem deploying, but I've deployed
sites and poms without issue this morning. Anyone has some more
information about this ?
If everythin
[ http://jira.codehaus.org/browse/MAVENUPLOAD-744?page=all ]
Carlos Sanchez closed MAVENUPLOAD-744:
--
Assign To: Carlos Sanchez
Resolution: Fixed
> please upload webdav-servlet-1.2
>
>
>
please upload webdav-servlet-1.2
Key: MAVENUPLOAD-744
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-744
Project: maven-upload-requests
Type: Task
Reporter: Robert Erler
new version, way faster than the old.
--
This
[ http://jira.codehaus.org/browse/MAVENUPLOAD-703?page=all ]
Carlos Sanchez closed MAVENUPLOAD-703:
--
Assign To: Carlos Sanchez
Resolution: Fixed
Next time put a direct url, like
http://ovh.dl.sourceforge.net/sourceforge/webdav-servlet
WebDAV-Servlet
--
Key: MAVENUPLOAD-703
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-703
Project: maven-upload-requests
Type: Task
Reporter: Robert Erler
This is a java servlet that provides an implementation of the webdav protocol.
Underlying
Implement WebDAV Provider
-
Key: WAGON-32
URL: http://jira.codehaus.org/browse/WAGON-32
Project: wagon
Type: New Feature
Reporter: Joakim Erdfelt
Priority: Minor
Implement a WebDAV provider for wagon.
url syntax would be - dav
The following comment has been added to this issue:
Author: Mark Slater
Created: Mon, 31 Jan 2005 6:40 PM
Body:
I've attached the maven-webdav-plugin-0.1.jar that makes an attempt to provide
this feature. All I can say is that it seems to work for my project.
I can'
The following issue has been updated:
Updater: Mark Slater (mailto:[EMAIL PROTECTED])
Date: Mon, 31 Jan 2005 6:38 PM
Comment:
This is a one-off stab at webdav site upload. It doesn't provide for much else.
It relies on the jakarta-slide project.
You need to define the and
: MPSITE-17
Summary: Support for WebDAV deployment
Type: New Feature
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven-site-plugin
Versions:
1.6
Assignee:
Reporter: Archimedes
98 matches
Mail list logo
