Re: Plans for Wagon-1.0 final release?

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