On 28 Feb 07, at 9:50 AM 28 Feb 07, Joakim Erdfelt wrote:

Just so that we have "Joakim's plans" documented here ....

Wagon Ideas.


Just a point which I think is important: keep any discussion of how this is configured separate from Maven and its configuration mechansim. What's falling out from the embedder is a session level configuration and a request level configuration. So you might want something in Wagon for the initial setup of a provider and then for a request. You might want to set a default timeout but allow it to be overridden at the request level.

   1. Add Timeouts.
      Question becomes, how do we configure this value?
      Per Protocol? or Per Repository?

Session level with possible overrides at the request level. I think the Configuration for session and ExecutionRequest in Maven is a good model.

Can probably wait for 1.1.

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.

Probably a Map passed into the session level, or request level configuration could then be used by the given provider to with what it wants with it. Otherwise you're going to get into crappy configuration models for each provider. This is what Velocity resource loaders do for specifics and it works well.

Can probably wait for 1.1.

   3. Streaming Wagons.

This would definitely be good for piping content from one place to another without it having to hit the disk.

Can probably wait for 1.1.

   4. Limited Wagon Transactions.
      This becomes a problem when we have a deploy that modifies the
      maven-metadata.xml

Again stop thinking about Maven, what's the use case here.

   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

The id sucks but this again can wait for 1.1.

   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.

I think all of these are good ideas but can probably wait until 1.1. We need to start releasing this stuff. I think the API is not quite right, but we can scrutinize the API later, let's release 1.0 and then move on. Maven 2.1 can use 1.1 and so you'll get lots of feedback from there.


And I realize that the concepts above are not wagon exclusive, but
rather overlap with maven 2.1 too.

I say we can let Maven 2.1 provide use cases but don't let that completely shape the work being done.

jason.


- 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]

Reply via email to