Hi Marc,
Instead of creating a new command, I decided to update the REPO LIST command, which now invalidates the internal repo structure before listing all all packages. The command creates some textual output, but you can simply ignore it. Could you try the latest snapshot [1] and see if calling REPO LIST or repo:list() meets your requirements?
Best, Christian
[1] http://files.basex.org/releases/latest/
On Thu, Feb 19, 2015 at 12:29 PM, Christian Grün christian.gruen@gmail.com wrote:
…Perfect, so we shouldn't encounter problems when refreshing the repository directory.
On Thu, Feb 19, 2015 at 12:23 PM, Marc van Grootel marc.van.grootel@gmail.com wrote:
Oh no I wouldn't. --Marc
On Thu, Feb 19, 2015 at 12:04 PM, Christian Grün christian.gruen@gmail.com wrote:
In gradle.properties I define system properties and then in a Gradle build script I invoke a JavaExec task with the system properties.
So, if I get it right, the repo path will be set at startup time. But will you change it while BaseXHTTP is running?
task http(type: JavaExec) { classpath configurations.basex main = "org.basex.BaseXHTTP" systemProperties System.getProperties() }
--Marc
On Thu, Feb 19, 2015 at 11:44 AM, Christian Grün christian.gruen@gmail.com wrote:
Hi Marc,
I figure when I change the repo path before running this it would pick up the modules from the new directory?
This is probably not that easy, because REPOPATH is a global/static option, which is supposed not to change over the runtime of a BaseX instance.
How/where do you currently change the repo path at runtime?
Christian
Thus, so to speak,
being able to "mount" another repo dir without file copying. Remembering timestamps etc. would make this a little trickier though as the new path may contain different modules possibly even older then the previous repo dir.
I will keep an eye on this package listing issue (I noticed it on OSX) and try to come up with some repro steps.
--Marc
On Thu, Feb 19, 2015 at 11:24 AM, Christian Grün christian.gruen@gmail.com wrote: > Hi Marc, > >> I like to have the same workflow during development and take advantage >> of having modules not depend on a fixed import path. When working with >> the repo modules have to be installed first. Just copying them under >> the repo doesn't make basex aware of them. > > That's true (at least for jar and xar files; it actually works for > simple XQuery modules). > > We could add a REPO UPDATE command and a repo:update() XQuery > function, which rebuild the internal repository cache; do you think > this would already help? > > Another, more flexible, alternative would be to remember the > timestamps of already parsed modules and rebuild the repository > whenever the timestamp has changed or the addressed module does not > exist. > >> BTW one more thing I noticed. When I sometimes get into a situation >> where individual empty directories are also recognized as packages >> (but I cannot delete them from the GUI package manager). With >> repo:list() I then see something like this. > > Feel free to provide me with a snapshot of your repo directory > whenever you can reproduce it. > > Best, > Christian
-- --Marc
-- --Marc
-- --Marc