Plans for Wagon-1.0 final release?

[John Casey]

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.

Thanks,

John

[Trygve Laugstøl]

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: wagon-dev-unsubscribe@...
For additional commands, e-mail: wagon-dev-help@...

[Joakim Erdfelt-2]

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: wagon-dev-unsubscribe@...
> For additional commands, e-mail: wagon-dev-help@...
>

[John Casey]

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 <joakim@...> 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: wagon-dev-unsubscribe@...
> > For additional commands, e-mail: wagon-dev-help@...
> >
>
>

[Joakim Erdfelt-2]

Before we close out wagon 1.0...

Should we address the recurring scp / permissions issue we have with
people.apache.org?

- 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 <joakim@...> 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: wagon-dev-unsubscribe@...
>> > For additional commands, e-mail: wagon-dev-help@...
>> >
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@...
For additional commands, e-mail: wagon-dev-help@...

[John Casey]

Yeah, that's the sort of thing I wanted to talk about here. I was curious
what was outstanding in terms of non-design bugs that could be addressed
prior to 1.0-final. This would seem to fit the bill...is it assigned to the
1.0 version in JIRA?

/me looks...

I don't see anything in there that would seem to match, but it's possible
I'm not familiar enough with the issue to find it...unless it's WAGON-71.

-john

On 2/28/07, Joakim Erdfelt <joakim@...> wrote:

>
> Before we close out wagon 1.0...
>
> Should we address the recurring scp / permissions issue we have with
> people.apache.org?
>
> - 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 <joakim@...> 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: wagon-dev-unsubscribe@...
> >> > For additional commands, e-mail: wagon-dev-help@...
> >> >
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wagon-dev-unsubscribe@...
> For additional commands, e-mail: wagon-dev-help@...
>
>

[Joakim Erdfelt-2]

This http://jira.codehaus.org/browse/WAGONSSH-42 seems to be the closest.

- Joakim

John Casey wrote:

> Yeah, that's the sort of thing I wanted to talk about here. I was curious
> what was outstanding in terms of non-design bugs that could be addressed
> prior to 1.0-final. This would seem to fit the bill...is it assigned
> to the
> 1.0 version in JIRA?
>
> /me looks...
>
> I don't see anything in there that would seem to match, but it's possible
> I'm not familiar enough with the issue to find it...unless it's WAGON-71.
>
> -john
>
> On 2/28/07, Joakim Erdfelt <joakim@...> wrote:
>>
>> Before we close out wagon 1.0...
>>
>> Should we address the recurring scp / permissions issue we have with
>> people.apache.org?
>>
>> - 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 <joakim@...> 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: wagon-dev-unsubscribe@...
>> >> > For additional commands, e-mail: wagon-dev-help@...
>> >> >
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wagon-dev-unsubscribe@...
>> For additional commands, e-mail: wagon-dev-help@...
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@...
For additional commands, e-mail: wagon-dev-help@...

[Joakim Erdfelt-2]

I say with Wagon 2.0, we don't even bother with maintaining backwards
compatibility.

(Yes, I like the idea of calling it Wagon 2.0)

We should also get Milos Kleint and Eugene Kuleshov involved to see if
there is anything that he would like to have from their IDE integration
points of view.

- Joakim

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.
>
> Thanks,
>
> John
>

---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@...
For additional commands, e-mail: wagon-dev-help@...

[Jason van Zyl-2]

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: wagon-dev-unsubscribe@...
>> For additional commands, e-mail: wagon-dev-help@...
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@...
For additional commands, e-mail: wagon-dev-help@...

[Jason van Zyl-2]

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 <joakim@...> 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: wagon-dev-unsubscribe@...
>>>> For additional commands, e-mail: wagon-dev-help@...
>>>>
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wagon-dev-unsubscribe@...
> For additional commands, e-mail: wagon-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@...
For additional commands, e-mail: wagon-dev-help@...

[brettporter]

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 <joakim@...> 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: wagon-dev-unsubscribe@...
>>>>> For additional commands, e-mail: wagon-dev-help@...
>>>>>
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wagon-dev-unsubscribe@...
>> For additional commands, e-mail: wagon-dev-help@...
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wagon-dev-unsubscribe@...
> For additional commands, e-mail: wagon-dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@...
For additional commands, e-mail: wagon-dev-help@...

[Jason van Zyl-2]

On 28 Feb 07, at 11:29 AM 28 Feb 07, Brett Porter wrote:

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

Yes, but I think we should make this easier across the board if wagon  
happens to be used outside of Maven. I think group writable is a  
reasonably safe thing to do and provides the most convenient default.  
And thus requires less configuration information on the Maven side  
which is what we should be striving for.

Jason.

> - 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 <joakim@...> 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: wagon-dev-unsubscribe@...
>>>>>> For additional commands, e-mail: wagon-dev-help@...
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: wagon-dev-unsubscribe@...
>>> For additional commands, e-mail: wagon-dev-help@...
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wagon-dev-unsubscribe@...
>> For additional commands, e-mail: wagon-dev-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wagon-dev-unsubscribe@...
> For additional commands, e-mail: wagon-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@...
For additional commands, e-mail: wagon-dev-help@...

[Jason van Zyl-2]

So are we pretty much agreed that most things Joakim brought up will  
be slated for 1.1/2.0 and we'll push a release of this out as soon as  
we can?

Jason.

On 27 Feb 07, at 5:23 PM 27 Feb 07, 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.
>
> Thanks,
>
> John

---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@...
For additional commands, e-mail: wagon-dev-help@...

[John Casey]

Yup, I think that's the general consensus, though we do need to sift through
the various WAGON* jira projects, and determine what existing issues must be
fixed for a 1.0 release, I suppose.

In a way, it's not made things simpler to break up the different wagons into
separate jira projects...as far as I can tell, they've been
developed/released in lock-step so far.

-john

On 3/1/07, Jason van Zyl <jason@...> wrote:

>
> So are we pretty much agreed that most things Joakim brought up will
> be slated for 1.1/2.0 and we'll push a release of this out as soon as
> we can?
>
> Jason.
>
> On 27 Feb 07, at 5:23 PM 27 Feb 07, 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.
> >
> > Thanks,
> >
> > John
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wagon-dev-unsubscribe@...
> For additional commands, e-mail: wagon-dev-help@...
>
>

[jblack]

Any news or concerns about releasing the existing wagon as 1.0?

Jeff

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.

Thanks,

John

[Nathan Beyer-3]

An upgrade to the latest HttpClient would be nice. The current http
provider code is 1 major version behind and a number of fixes behind.

-Nathan

On Nov 28, 2007 10:08 AM, jblack <jblack@...> wrote:

>
> Any news or concerns about releasing the existing wagon as 1.0?
>
> Jeff
>
>
> 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.
> >
> > Thanks,
> >
> > John
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Plans-for-Wagon-1.0-final-release--tf3304968.html#a13995619
> Sent from the Wagon - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wagon-dev-unsubscribe@...
> For additional commands, e-mail: wagon-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@...
For additional commands, e-mail: wagon-dev-help@...