CDV ❯ could not specify a relative path for repository
-
Bug
-
Status: Closed
-
1 Critical
-
Resolution: Fixed
-
-
-
amiller
-
Reporter: tgautier
-
March 27, 2008
-
0
-
Watchers: 0
-
May 01, 2008
-
April 29, 2008
Attachments
Description
I suspected that the following:
Would specify the lib directory in the current directory for repos, however this gets converted into /lib
Comments
Alex Miller 2008-03-27
Fiona OShea 2008-03-28
Taylor sending email to tc-dev to get feedback on changing repo spec to file path
Fiona OShea 2008-04-08
Add support for relative paths (relative to working process)
Deprecate file URL – in 2.6.1 we will remove support for file URL
Alex Miller 2008-04-11
Changed tc schema to be xs:string instead of xs:anyURI. Changed Resolver code to take Strings representing either URL or file path (possibly relative) instead of URL. Changed a lot of internal code to use File instead of URLs. Allow URL but state warning saying that URL support is deprecated.
Changed Eclipse plugin to pick, use, and validate Files instead of URLs (but will still work if using tc-config with url from older release).
Changed tcbuild test framework to pass file paths instead of URLs. Changed tc-maven-plugin to work with file paths instead of urls.
Hung Huynh 2008-04-16
I tested with 2.6-stable1, here’s what I had in my tc-config.xml
The client started without any error in console log (which is bad since you don’t know what went wrong), but in the terracotta-client.log, I found this stack trace:
2008-04-16 19:14:35,876 [main] ERROR com.tc.plugins.ModulesLoader - Exception thrown
java.net.MalformedURLException: unknown protocol: d
at java.net.URL.
Hung Huynh 2008-04-16
If I use relative path, I got this
<repository>mystuff</repository>
2008-04-16 19:30:15,948 [main] ERROR com.tc.plugins.ModulesLoader - Exception thrown
java.net.MalformedURLException: no protocol: mystuff
at java.net.URL.
Alex Miller 2008-04-27
I made some changes for windows file paths (C:\foo\bar) and relative paths and these cases should be fixed.
Hung Huynh 2008-04-28
tested with 2.6 r8386
To reproduce:
- Extracted attached zip to “terracotta-2.6-nightly-rev8386/tools/sessions/configurator-sandbox”
- Start Session Configurator:
- Add these to tc-config.xml
mymodules - Click “Start All”
You’ll see the below exception. It doesn’t even consider the “mymodules” as a choice. I can confirm “configurator-sandbox” is the working directory because that’s the place the logs and statistics got printed out also.
2008-04-28 17:13:34,818 INFO - Terracotta 2.6-nightly-rev8386, as of 20080428-120411 (Revision 8386 by cruise@rh4mo0 from 2.6) 2008-04-28 17:13:35,349 INFO - Configuration loaded from the file at ‘C:\terracotta\builds\terracotta-2.6-nightly-rev8386\tools\sessions\configurator-sandbox\tomcat5.5\tc-config.xml’. 2008-04-28 17:13:35,974 FATAL - Unable to resolve TIM file for tim-ehcache-1.3 version 1.2.0-SNAPSHOT (group-id: org.terracotta.modules)
Attempted to resolve the TIM using the following descriptors:
groupId: org.terracotta.modules
name : tim-ehcache-1.3
Version: 1.2.0-SNAPSHOT
Expected the TIM’s filename to be:
tim-ehcache-1.3-1.2.0-SNAPSHOT.jar
Expected these attributes to be in the manifest:
Bundle-SymbolicName: org.terracotta.modules.tim-ehcache-1.3
Bundle-Version : 1.2.0.SNAPSHOT
Searched using the following repositories:
+ C:\terracotta\builds\terracotta-2.6-nightly-rev8386\modules
Tried to resolve the jar file using the following paths:
+ C:\terracotta\builds\terracotta-2.6-nightly-rev8386\modules\org\terracotta\modules\tim-ehcache-1.3\1.2.0-SNAPSHOT\tim-ehcache-1.3-1.2.0-SNAPSHOT.jar
+ C:\terracotta\builds\terracotta-2.6-nightly-rev8386\modules\tim-ehcache-1.3-1.2.0-SNAPSHOT.jar
If the jar file exists and is in one of the paths listed
above, make sure that the Bundle-SymbolicName and
Bundle-Version attribute in its manifest matches the ones
that the resolver expects.
2008-04-28 17:13:35,974 ERROR - Exception thrown
com.tc.bundles.exception.MissingBundleException: Unable to resolve TIM file for tim-ehcache-1.3 version 1.2.0-SNAPSHOT (group-id: org.terracotta.modules)
at com.tc.bundles.Resolver.resolve(Resolver.java:172)
at com.tc.bundles.Resolver.resolve(Resolver.java:191)
at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:150)
at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:98)
at com.tc.object.tools.BootJarTool.
Hung Huynh 2008-04-29
I tested relative path with chatter demo and it worked fine. I think the real problem is this issue DEV-1596
It’s not valid (AFAIK) to use relative paths in URIs. Relative URIs are typically formed by combining a base URI (not sure what that would be in our case - could be current directory or tc install but we would need to specify) with a path. The example above is a bastard hybrid of those. :)
For probably no really good reason the only thing that works here now is a valid absolute file URL. If you want to jettison the idea of supporting an arbitrary URL (not just file://), then you could switch to a file path and get what you want.
I think there is real potential value in supporting non-file urls so someone could load a TIM direct from our forge or elsewhere. So, another alternative would be to support a variable substitution for the install directory in the file url which would cover the case above.
And another option would be to support both URL and file path in which case you could instead say just “./lib”.
I think I’d vote for the last.