Mauro Talevi wrote:
Ok - so two scenarios are possible:
1. Improve wagon abstraction: separate concerns and introduce the
missing features in the appropriate different abstraction layers (ie
upload and download)
2. Remove wagon and implement in maven-artifact, but you'll still end
up fa
Jason van Zyl wrote:
In this case I think the abstraction being neglected hasn't bought us
much. And that a more focused approach on what's most commonly used will
give the real chance to improve the instabilities we have and give
people an easier chance of understanding the codebase without
On 10 Sep 07, at 7:43 AM 10 Sep 07, Joakim Erdfelt wrote:
Just a thought, but why not dump wagon in 2.1 and just use the
java.net
package for file / http / https / ftp fetch, any valid java.net.URL
could work that way.
Instead of picking and choosing what to support, just punt and support
wh
On 9 Sep 07, at 2:46 AM 9 Sep 07, Mauro Talevi wrote:
Brett Porter wrote:
On 09/09/2007, at 1:11 AM, Jason van Zyl wrote:
Not using Wagon, our abstraction, and directly focusing on HTTP.
Doesn't that mean adding a bunch of HTTP code, listeners, etc into
the artifact code - and making two p
On 8 Sep 07, at 2:56 PM 8 Sep 07, Brett Porter wrote:
On 09/09/2007, at 1:11 AM, Jason van Zyl wrote:
Not using Wagon, our abstraction, and directly focusing on HTTP.
Doesn't that mean adding a bunch of HTTP code, listeners, etc into
the artifact code - and making two places to maintain
Brett Porter wrote:
On 09/09/2007, at 1:11 AM, Jason van Zyl wrote:
Not using Wagon, our abstraction, and directly focusing on HTTP.
Doesn't that mean adding a bunch of HTTP code, listeners, etc into the
artifact code - and making two places to maintain something essentially
the same, tha
Darn-it. Now you went and said, in two sentences, what I was saying in
three paragraphs. Grrr.
christian.
On 10-Sep-07, at 11:32 AM, Brian E. Fox wrote:
I really hope that we're not trying to keep file://
around so that it's easier to _distribute_ repositories.
I don't think that's the m
To me file:// repos were for local situations where you wanted to test
or fix maven build behaviour because of some condition. For example,
you're one machine is behind a firewall and you are not able to cross
the boundary to pull in stuff into your build system, so you create a
repo for t
>I really hope that we're not trying to keep file://
>around so that it's easier to _distribute_ repositories.
I don't think that's the motivation. It's just that there are some cases where
remote repos can't be done (usually more for organizational/political) reasons
than technical.
A quick thought about file:// repositories: I've seen it done from
time to time, and I always thought that it was decidedly un-maven.
Instead of distributing a framework with copies of jars, which seemed
to be the problem remote repositories were trying to solve, you just
distribute the same colle
On 9/10/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
> Just a thought, but why not dump wagon in 2.1 and just use the java.net
> package for file / http / https / ftp fetch, any valid java.net.URL
> could work that way.
>
> Instead of picking and choosing what to support, just punt and support
>
Just a thought, but why not dump wagon in 2.1 and just use the java.net
package for file / http / https / ftp fetch, any valid java.net.URL
could work that way.
Instead of picking and choosing what to support, just punt and support
what is in java itself for fetch.
And we can get rid of a lot of
On 09/09/2007, at 1:11 AM, Jason van Zyl wrote:
Not using Wagon, our abstraction, and directly focusing on HTTP.
Doesn't that mean adding a bunch of HTTP code, listeners, etc into
the artifact code - and making two places to maintain something
essentially the same, that doesn't really bu
On 8 Sep 07, at 8:50 AM 8 Sep 07, Wendy Smoak wrote:
On 9/7/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 7 Sep 07, at 5:20 PM 7 Sep 07, Brian E. Fox wrote:
I don't currently, but have in the past used file:// for remote.
For deploying or actually pulling? Deploying is a totally differ
On 9/7/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> On 7 Sep 07, at 5:20 PM 7 Sep 07, Brian E. Fox wrote:
>
> > I don't currently, but have in the past used file:// for remote.
> >
>
> For deploying or actually pulling? Deploying is a totally different
> story. I know tons of people who use fil
On 8 Sep 07, at 5:43 AM 8 Sep 07, Mauro Talevi wrote:
Jason van Zyl wrote:
On 7 Sep 07, at 5:20 PM 7 Sep 07, Brian E. Fox wrote:
I don't currently, but have in the past used file:// for remote.
For deploying or actually pulling? Deploying is a totally
different story. I know tons of people
Jason van Zyl wrote:
On 7 Sep 07, at 5:20 PM 7 Sep 07, Brian E. Fox wrote:
I don't currently, but have in the past used file:// for remote.
For deploying or actually pulling? Deploying is a totally different
story. I know tons of people who use file, dav, scp, and ftp. Strictly
for pullin
On 7 Sep 07, at 5:43 PM 7 Sep 07, Brett Porter wrote:
On 08/09/2007, at 10:37 AM, Jason van Zyl wrote:
On 7 Sep 07, at 5:16 PM 7 Sep 07, Brett Porter wrote:
file:// ?
I also know of some wagon-scm + SVN uses (though they could
download over HTTP).
Right, deployment is a different s
other then HTTP?
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, September 07, 2007 6:55 PM
To: Maven Developers List
Subject: Using HTTP repositories for consumption only
After thinking about Greg's comments I think it would be interesting
to ask peop
On 08/09/2007, at 10:37 AM, Jason van Zyl wrote:
On 7 Sep 07, at 5:16 PM 7 Sep 07, Brett Porter wrote:
file:// ?
I also know of some wagon-scm + SVN uses (though they could
download over HTTP).
Right, deployment is a different story. I use the wagon-scm stuff
for audit trail and dep
On 7 Sep 07, at 5:16 PM 7 Sep 07, Brett Porter wrote:
file:// ?
I also know of some wagon-scm + SVN uses (though they could
download over HTTP).
Right, deployment is a different story. I use the wagon-scm stuff for
audit trail and deploy there. I'm talking strictly about pulling.
I'd
n Developers List
Subject: Using HTTP repositories for consumption only
After thinking about Greg's comments I think it would be interesting
to ask people who actually uses anything but HTTP repositories for
consumption?
Deployment is a totally different story, but to radically simplify
the cor
List
Subject: Using HTTP repositories for consumption only
After thinking about Greg's comments I think it would be interesting
to ask people who actually uses anything but HTTP repositories for
consumption?
Deployment is a totally different story, but to radically simplify
the core
file:// ?
I also know of some wagon-scm + SVN uses (though they could download
over HTTP).
I'd be hesitant to remove this without doing some decent polling of
users (and probably a deprecation cycle).
- Brett
On 08/09/2007, at 8:55 AM, Jason van Zyl wrote:
After thinking about Greg's co
After thinking about Greg's comments I think it would be interesting
to ask people who actually uses anything but HTTP repositories for
consumption?
Deployment is a totally different story, but to radically simplify
the core what if we only allowed HTTP repositories for consumption in
2.1
25 matches
Mail list logo
