On 22 Aug 07, at 11:23 AM 22 Aug 07, Gregory Kick wrote:
It does if you use a shared file system, many people actually use
this. And simple Window file perms work here to protect it.
How do you deal with concurrent writes?
There's nothing you can do here with Wagon in general right now. This
is not local to the file wagon.
, all of them require some sort of
server somewhere. Granted, a lot of people have sshd or httpd or
ftpd
running so it's not an extra process, but there's still _something_
running on the other end no matter what. Also, I'd be pretty
surprised to find that a significant portion of the people running a
remote repository weren't running a servlet container already as
well.
Plus, there's always jetty or winstone if you want a quick install.
No argument that in the very near future I don't think anyone will
use a Maven repository without a front-end application. Web servers
are just too stupid, security is annoying, you have no transactional
behaviour, and you have to expose the internal structure.
I'm also pretty sure that there's going to be some question of
backwards compatibility. Well, seeing that I'm suggesting a RESTful
service, it could have the exact same structure as what's being used
now. I'm not entirely sure I'd recommend that, but it _could_.
If it
didn't you could always just add a new layout.
The repository managers will have an API, and can be exposed via REST
which will end up being one of the favored modes of operation. But I
see applications interacting directly with client side APIs to get
things done. Like Maven deployments, releases, searching, what
have you.
This seems like it'd end up being problematic for a couple of reasons.
The first is that when you say that it _can_ be exposed via REST this
implies too much flexibility in what the resource URIs look like.
There's no reason that there can't be a standard URI, but honestly I
don't see the REST API being the most used form of access.
To
provide a decent user experience from both the application and the
browser, there has to be some standardization for the rest api.
Not disagreeing with you.
Not
that the current layout doesn't have a standard interface, but the
format of the results for directory listings and the URIs for
additional functionality would end up being all over the place.
What is used to logically represent an artifact via a URI can be
decoupled from where it resides physically. Looking directly at the
web server is not necessarily representative of what the REST API
would provide.
The other issue is that, from a developer perspective, I'd rather
there not be a standard java api. If the job of a repository is to
serve artifacts, that should be the only contract to which I'm bound
(especially if the maven code is still compiling with 1.4).
It's not the only responsibility of the repository, and I disagree
that people won't want to use an API. But again, there is no reason
that we can't have a standard REST API built upon the standard API
which would satisfy your primary concern. For pulling artifacts 9/10
people will most likely use HTTP, but we have many people using SCP
and FTP for whatever their reasons.
Unless
there's a really compelling reason to support other transports,
Existing users that are not pulling with HTTP.
any
additional api just adds another layer. Of course, the maven-built RI
could add whatever api it wants, but I can't think of a scenario in
which you'd need to support its invocation from anything other than
the transport.
A repository manager will ultimately be responsible for more then
pulling artifacts. For pulling and the 9/10 people using HTTP, and
for those who simply want access to the repository we can provide
this common REST API and no one will be the wiser. But for
deployments, releases, searching, retrieval of incremental indices,
retrieval of stats a standard API will be of greater use. It's what
we would use directly from Maven and any tooling would be more
interested in using this API.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
