On 22 Feb 07, at 5:11 PM 22 Feb 07, Joakim Erdfelt wrote:
Just some thoughts.
I would like to change wagon-webdav's protocol definition.
Currently it is "dav:http://"; and "dav:https://"; both of which are
technically invalid protocols.
It should be "dav://" and "davs://".
As long as you support the old ones that are used everywhere.
I've wanted to make the wagon's register URL handlers for
themselves too.
What does that mean exactly?
That would allow for a more natural Streaming Wagon implementation
too.
- Joakim
Joakim Erdfelt wrote:
The changes to wagon are ... (just to make sure they show in john's
gmail account)
1) Timeouts
2) Streaming Wagon
3) Limited Transactions
- Joakim
John Casey wrote:
Hi all,
I have something to point out that I think the entire Maven
development
community needs to hear. I've been doing a lot of work recently with
Maven
trunk, so I notice any (perhaps inevitable) instability that comes
down the
pike from dependency APIs. Recently, I've been having a LOT of
trouble in
this area.
Particularly in the Wagon API. It seems that a change was rolled
into
wagon-provider-api around the beginning of February that introduced
some new
methods into the Wagon interface. This is not in itself a
problem, even
though the current code version is at 1.0-*beta*-3-SNAPSHOT. What
causes an
issue is the fact that these new methods are then assumed to be in
place by
the new DefaultWagonManager, effectively breaking that manager's
backward
compatibility with previous releases of Wagon providers.
I tracked all of this down over the course of the past few days, in
between
doing the things that I'm actually focused on doing. I can fix
this one
problem by myself; I'm not pleading for help here. However, I cannot
act as
the gatekeeper for all APIs that get used in Maven trunk, to
ensure their
stability and backward compatibility. I've been informed that there
are many
other such changes heading for Wagon...interestingly enough, a quick
search
of my GMail account doesn't turn up any discussion of these changes
(unless
it's buried in the deep past somewhere).
I know that this email can look a bit hypocritical on its face,
but I
really
do feel that we owe it to our user base to be a little more
proactive in
ensuring backward compatibility than we have in the past. I
understand
that
many Maven developers are on various deadlines, but those
deadlines do
not
originate in the Maven ASF project, and shouldn't cause undue
harm to the
community or its code. I'm not trying to say we need to rigidly
adopt and
conform to some process or other, but we each individually need
to take
responsibility for discussing and testing any major changes we
plan to
put
into Maven or its dependencies.
IMHO, pushing new features into a beta API is irresponsible
unless you
can
be ABSOLUTELY certain it will not impact backward compatibility.
In these
cases, it is my understanding that the normal practice is to
create a
final
release of the existing API, and then push these bigger changes
into the
next version.
If there's even a shadow of doubt about what effect a change will
have on
the user community, we need to make a serious effort to start a
discussion
about it on this list.
Regards,
John
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
