I believe it been discussed before and this repository-url element still adds confusion.
First of all, we do need some local place where all the tims will be available locally, because accessing all the jars over http is not really secure and could cause various issues. When working with maven we don't need any additional url repositories to download tims from, because those can be specified in Maven's pom.xml and we don't need duplication in tc-config.xml. In result we ended with repository-url used to point to local Maven repository when things are launched from maven and to <dist>/modules when it launched from the kit. So, in a past I've been advocating that <dist>/modules and Maven local repo would be treated as a local place for downloading, but things got somewhat mixed up. regards, Eugene 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] <mailto:[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
