I've been experimenting with a new Fantom Env that gathers up all the correct versions of dependant pods from a local fanr repository. It's nice as it allows different projects to use different versions of the same pod.
But to make it work I've tweaked the following...
I would have expected that when Env.findPodFile() is called, the returned file is honoured as being correct. But this is not always the case.
Currently, when Pod calls Env.findPodFile() it then checks that the name of the returned file is what it expected and throws an Err if not. For example, my new Env returns a file called afPlastic-1.0.18.pod but Pod throws an Err complaining that it expected the file to be called afPlastic.pod.
The Err msg is about case sensitivity on Windows machines, which is fair enough, but I see no reason why the Pod class should care about this. So I've pushed the name check down into the Env class where file is first found.
diff -r 7194bb092a91 src/sys/java/fan/sys/Pod.java
--- a/src/sys/java/fan/sys/Pod.java Fri Nov 06 14:03:10 2015 -0500
+++ b/src/sys/java/fan/sys/Pod.java Tue Nov 17 14:29:26 2015 +0000
@@ -160,11 +160,6 @@
// if null or doesn't exist then its a no go
if (file == null || !file.exists()) throw UnknownPodErr.make(name);
- // verify case since Windoze is case insensitive
- String actualName = file.getCanonicalFile().getName();
- actualName = actualName.substring(0, actualName.length()-4);
- if (!actualName.equals(name)) throw UnknownPodErr.make("Mismatch case: " + name + " != " + actualName);
-
store = FStore.makeZip(file);
}
diff -r 7194bb092a91 src/sys/java/fan/sys/Env.java
--- a/src/sys/java/fan/sys/Env.java Fri Nov 06 14:03:10 2015 -0500
+++ b/src/sys/java/fan/sys/Env.java Tue Nov 17 15:28:29 2015 +0000
@@ -111,9 +111,16 @@
return parent.findAllFiles(uri);
}
- public File findPodFile(String name)
+ public File findPodFile(String name) throws java.io.IOException
{
- return findFile(Uri.fromStr("lib/fan/" + name + ".pod"), false);
+ fan.sys.File file = findFile(Uri.fromStr("lib/fan/" + name + ".pod"), false);
+ if (file == null) return null;
+
+ // verify case since Windoze is case insensitive
+ java.io.File f = ((LocalFile) file).file;
+ String actualName = f.getCanonicalFile().getName();
+ if (!actualName.equals(name + ".pod")) throw UnknownPodErr.make("Case mismatch: expected '" + name + ".pod' but found '" + actualName + "'");
+ return file;
}
public List findAllPodNames()
This retains the same default behaviour but also allows other Env implementations to return arbitrary named pod files.
EDIT: Updated patch so Env uses java.io.File.getCanonicalFile().getName() for the actual name check.
brianWed 18 Nov 2015
Agree, this is good change. The original checks were pre-Env plugin design. I pushed a change, although didn't see your canonical name change - but I don't think that matters since that is more a matter normalizing the path versus the filename itself
SlimerDude Tue 17 Nov 2015
I've been experimenting with a new Fantom
Env
that gathers up all the correct versions of dependant pods from a local fanr repository. It's nice as it allows different projects to use different versions of the same pod.But to make it work I've tweaked the following...
I would have expected that when
Env.findPodFile()
is called, the returned file is honoured as being correct. But this is not always the case.Currently, when Pod calls
Env.findPodFile()
it then checks that the name of the returned file is what it expected and throws an Err if not. For example, my new Env returns a file calledafPlastic-1.0.18.pod
but Pod throws an Err complaining that it expected the file to be calledafPlastic.pod
.The Err msg is about case sensitivity on Windows machines, which is fair enough, but I see no reason why the
Pod
class should care about this. So I've pushed the name check down into theEnv
class where file is first found.This retains the same default behaviour but also allows other
Env
implementations to return arbitrary named pod files.EDIT: Updated patch so
Env
usesjava.io.File.getCanonicalFile().getName()
for the actual name check.brian Wed 18 Nov 2015
Agree, this is good change. The original checks were pre-Env plugin design. I pushed a change, although didn't see your canonical name change - but I don't think that matters since that is more a matter normalizing the path versus the filename itself