« Return to Thread: Plans for Wagon-1.0 final release?

Re: Plans for Wagon-1.0 final release?

by Jason van Zyl-2 :: Rate this Message:

Reply to Author | View in Thread


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

 « Return to Thread: Plans for Wagon-1.0 final release?