Closed FroMage closed 9 years ago
Stef, I wondered if we could change the query API to make ModuleQuery.Type
a normal class that takes a list of suffixes and have JVM
, JS
, CODE
and ALL
etc be just some useful pre-defined sets of suffixes. In the query we would then pass that list instead of "jvm", "js", "code". This way we can let the programmer decide what they want to query (if you want to query for .JARs that only have .XML module descriptors, well that's your business) instead of having to keep defining new query types (I just added CEYLON_CODE
just for a case that Gavin needs for the IDE).
That's #182, right?
Yes, sorry, I put it here first and then opened an issue for it.
Still need support for .scripts.zip
, not sure if there are any more artifacts, but I needed -model.js
to work right now so I pushed that fix for now at least.
Ok, I think this is all for now. Closing.
Well I think the ui should show something about modules with scripts too, no?
I'm guessing you're talking about something else besides the upload page? It shows them there.
Re-opening because I saw that there's another importnat thing that's missing: the module-resources
folder!
Ok, and I see now that for the Herd we don't actually upload folders but only zips dat get unpacked. But honestly I don't think we should just always make ZIPs out of all the folders we have in our repositories, they will just fill up with needless copies of everything. My idea would be to have the CMR zip on-the-fly any folders it wants to send to the Herd. The Herd could then keep the zip around for easy downloading. Wdyt?
Well, zips are also useful for emailing to someone.
I'm guessing you're talking about something else besides the upload page? It shows them there.
Yes, the module version page, which gives you info about the module. It should tell us there are scripts there. I guess you need to add a table to record the script names, and perhaps try a quick and dirty text matcher to extract the script info?
Well, zips are also useful for emailing to someone.
Come on, don't tell me that anyone who can work with Ceylon isn't capable of creating a ZIP in seconds in any of half a dozen possible ways.
It's what I find obnoxious about the current module-docs
folder. We have that and we have a ZIP, but they don't even contain the same information! And if you do a ceylon doc
or a ceylon copy
to a remote server that is not Herd you copy everything twice! And all that because perhaps someone might be too lazy to right click on a folder and select "Zip"?
Well, the zip contains both the API docs and the text docs. Thing is we need them exploded locally, but we have to zip them over HTTP otherwise it takes forever. We could have them exploded locally and only zip for Herd, but that sounds like a lot of work.
Thing is we need them exploded locally
Well , weird thing is then that the text docs aren't exploded locally, they only exist in the ZIP.
but we have to zip them over HTTP otherwise it takes forever
I understand, although my tests with a local WebDAV server showed the copying was pretty fast (probably because it maintains the connection open for the entire duration). But I can see the need for transferring ZIPs. I just think we should generate them on-the-fly. That way we won't have folders and ZIPs with different stuff in them.
but that sounds like a lot of work.
I don't think it's that much work... but more than the few hours that I have left today before going on vacation ;)
The details page now has a download link for scripts just like we have for the source archive.
But do you see some kind of special use for being able to browse scripts? We don't do that for the "normal" ceylon commands either. Although that's not especially difficult, but the parsing seems like a lot of work for what seems to me very little ROI? But I'll open a new issue for it.
Well, I'm not sure it's useful to download the scripts, but listing them and their use would be nice. Also list the command that gets them installed like we do list how to run the module.
Also list the command that gets them installed like we do list how to run the module.
Done.
Like resources, docs (I think both already supported but check) and whatever the JS compiler did to split the metamodel out.