I think these problems are more often misconfigurations of Maven (due
to it being hard to do) - so something to be fixed in maven by moving
the repo permissions into the project repo definition.
I believe once configured correctly it works in most cases.
- Brett
On 28/02/2007, at 11:46 PM, Jason van Zyl wrote:
On 28 Feb 07, at 10:08 AM 28 Feb 07, Joakim Erdfelt wrote:
Before we close out wagon 1.0...
Should we address the recurring scp / permissions issue we have with
people.apache.org?
That's really not going to change the API so if it's changing the
default permission then go for it.
Jason.
- Joakim
John Casey wrote:
I think all of these items are great ideas. I think you've done a
great job
of summing up the major recurring discussions about improving wagon
(not to
mention a couple of good ideas in there that I haven't heard much
about). I
wouldn't stand in the way of any of this...except where wagon-1.0 is
concerned.
IMO, most of this list should be developed post-1.0 (whether that's
1.1 or
2.0 is up for debate, of course; this wouldn't really seem to
demand a
complete rewrite, which is what I'd expect of a 2.0). I don't see
how
you're
going to make some of these changes without creating a lot more
backward
compatibility issues. If we planned on tackling these things in the
1.0branch, we should have gone through more alphas. IMO, we've
missed
our
chance.
I think it's important to remember that the existing wagon api works
well in
many cases, and for a large number of users. We should declare
this one a
success, and move on to implementing the things we learned from it.
-john
On 2/28/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
Just so that we have "Joakim's plans" documented here ....
Wagon Ideas.
1. Add Timeouts.
Question becomes, how do we configure this value?
Per Protocol? or Per Repository?
Do we use the <server><configuration> section in the
settings.xml?
2. Add Client Header Identification.
This would only be useful on some protocols (such as
http / dav),
but completely irrelevant on others.
Jason could use this to track the uptake of specific
versions of
maven on the repo1.maven.org side.
If we decide to do this for http, we can make it be a
separate
request header, or a modification of the USER-AGENT string.
3. Streaming Wagons.
4. Limited Wagon Transactions.
This becomes a problem when we have a deploy that modifies
the
maven-metadata.xml
5. Deprecation of repository id / server id as the
authentication
binding mechanism.
Use what precisely to bind to?
1. hostname
2. hostname:port
3. protocol://hostname:port
4. regex of any of the above
5. all of the above
6. Whitelists on repositories in pom.xml, based on groupId.
(don't
bother searching this repository if the groupId doesn't
match).
This should help optimize the repository searching. It's
just a
piece of build optimization, anyone consuming the pom
could just
as well ignore this optimization with no ill effects.
7. Password Encryption in the settings.xml
I welcome discussion.
Big +1 or -1 on any concept above.
And I realize that the concepts above are not wagon exclusive, but
rather overlap with maven 2.1 too.
- Joakim
Trygve Laugstøl wrote:
John Casey wrote:
Hi,
I just committed some changes to trunk that should restore
backward
compatibility for using older wagons (at least in the vast
majority of
cases). It may still break if there is an older version of a
wagon
out there
that doesn't extend from AbstractWagon (since the Wagon interface
picked up
like 5 new methods lately).
Can we start talking about a Wagon 1.0-final release? What do
we need
to get
this done? It looks like the current roadmap only shows 3
outstanding
issues
for the next release. Does anyone have plans for finishing
those, and
are
they enough to serve as a basis for a final release?
I'm just trying to figure out what plans there are for this,
since
I'd like
to move toward a 2.1-alpha-1 release of maven, and this is going
to be
a
prereq.
I say release what Wagon is now as 1.0 (in other words no API
breakage) and put Joakim's plans into Wagon 2.0.
--
Trygve
------------------------------------------------------------------
---
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
