The CLI has a "module add" (haven't checked for remove/update) command for post-7.1.1 versions but personally I prefer downloading and editing the module xml file - it's really quite straightforward.
Unless I'm mistaken (and please tell me if I am), the module.xml won't download the actual code that's running the module? Just meta-data, right? (i.e. resource-root points to a local path, rather than some repository a la maven?)
Case in point: I want to play around with RestEasy 3.0-beta-2, I found a resteasy-jboss-modules-3.0-beta-2.zip in the download and extracted that in my modules folder. Now my (7.0) setup doesn't work anymore (which is OK, I've got backups).
In this case it would have been nice if an admin interface would have told me which versions are available and compatible, not just locally. Once my setup is stable I might want to share it with my collegues, that I don't really want to burden with downloading the same libraries manually.
Yes, there is no downloading involved and the resources references are disk-local
To summarize (and see if I understood everything correctly), to update I have to:
1) Find the modules I want to update in my local installation
2) Find newer versions of the corresponding jars on the internet
3) Copy the newer versions over the older
4) Check if the module has dependencies on other modules that need the same treatment (e.g. RestEasy depends on Jackson)
5) Create some kind of script to distribute to my co-workers
NB: I want to update, the modules I'm interested in are already installed.
Since the names of the jars most probably have changed you'll need to remove the old ones, drop in the new ones and edit the module.xml to reflect the new name. After that you can zip up the entire module dir and hand it to your collegues. Of course, if there is an API-breaking change in the jar, dependent jars/modules will also have to be updated. But I would say that is not that common unless the update is "major number".