|
»
»
« Return to Thread: Plans for Wagon-1.0 final release?
Re: Plans for Wagon-1.0 final release?
by John Casey
::
Rate this Message:
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@...
> >
>
>
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@...
> >
>
>
« Return to Thread: Plans for Wagon-1.0 final release?
| Free embeddable forum powered by Nabble | Forum Help |
