The current state of parsing these urls as I've know it already
supports both, with limit to Linux.
if you specify a unix-style path in <repository>
/home/apollo/tc/modules ---> it parses as path (only on unix)
file://home/apollo/tc/modules ---> it parses as URL which ends up
with the same path
c:/apollo/tc/modules ---> it complaints about unknown
protocol ( c:/ )
file:/c:/apollo/tc/modules ---> it parses as URL
I've suggested to Alex to also accept Windows path but he argued the
acceptant of Unix-style path is a bonus, not a design so there's no
point of supporting it for Windows.
So if we make it to accept both style (path and url), we certain can
with little effort.
Hung-
Taylor Gautier wrote:
I'm not disagreeing - just want to make sure it is the best and least
confusing way to implement support for filepaths. Is it sensible that
the element accepts filepaths and urls?
Are they always distinguishable from one another? Should we write
special code to flip between one or another automagically? Or is it
better to have separate elements for separate types of config?
(I tend to prefer the latter as it seems it is less magic code, and
seems to be less magic for the user, but I can certainly be convinced
of the former)
Alex Miller wrote:
This thread kinda died but I didn't understand this last
mail in the context of my response.
It would be possible to support both urls and file paths in
the
same element right? Taylor, I'm not sure if you were disagreeing with
that or not. I'd prefer to use support both in the same config element
rather than having different ones.
On Mar 28, 2008, at 4:48 PM, Taylor Gautier wrote:
Seems we can't support
relative paths if we stick with urls. The thought was that if we did
add http support, we could add using a different repo spec, say:
<repository-url>the_url</repository-url>
[EMAIL PROTECTED] wrote:
+1
On 3/28/08, Alex Miller <[EMAIL PROTECTED]> wrote:
I think we should support http:// in the future. Seems like it would be
annoying to restrict to a file path at this point given that it's been a url
till now and will (hopefully) support a url in the future.
I guess I'd vote for supporting both. It's easy enough to detect whether
something is a url and just retry as a file path.
Alex
----- "Taylor Gautier" <[EMAIL PROTECTED]> wrote:
We've run into some issues with the repository spec being a uri rather than
a file path. It has been pointed out that really we only support repos in a
filesystem anyway, so a uri is overkill, and in fact could lead someone to
believe we support something like http:// or worse gopher://, which is not
the case.
So I think it would be best to convert this setting to a file path, which is
more consistent with the rest of our config anyway.
Thoughts? What consequences will this have? I suspect the maven plugin
uses the repo setting, but at the system level by setting -D...
Maybe we need to implement this with a backward compatible translation from
a file url to a file path?
http://jira.terracotta.org/jira/browse/CDV-685
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
|
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
