installing modules

I’m running into an issue where modules are nested inside other modules creating an error “Module Already Registered”

to reproduce

create a new app --installColdBoxBE

then install cborm
then install cbvalidation
then install cbstorages

at least 3 modules conflicts cbi18n, cbvalidation, etc…

this happening to anyone else?

I don’t get that error, at most the log says “XYZ already installed, use --force to force”
Are you running the latest CommandBox? It may say 1.0.0 on the CommandBox site, but iirc that hasn’t changed even though there have been a lot of changes/fixes/improvements.
Below is my log running the steps you listed.

hey i’m an idiot. i added --force and it created the problem.

thanks for posting your complete log!

Yep, I know what’s going on. The latest build now actually uses nested modules so a module’s dependencies are installed inside of it just like NPM does.



Eventually ColdBox is supposed to allow multiple versions of the same module to be registered and it’s models will only be available to the parent module. Right now, nested modules are sort of half-implemented and all are installed at a global level.

So what’s happening is all of those module rely on i18n for instance so they each get a copy of the version they need installed underneath them. The ColdBox framework is really ready to handler multiple modules of the same name yet so it’s just erroring out.

We can:

  1. Finish implementing nested modules in ColdBox. That would be nice, but there’s a lot of work left and Luis hadn’t really planned on doing it for the 4.0 release
  2. Break CommandBox so it stops installing nested dependencies in the right place. That would also break the new list command that really can’t work unless stuff is in the correct place. Otherwise the install paths and dependencies are in the wrong box.json
  3. “Enhance” ColdBox to just ignore multiple versions of the same module for now (kind of my favorite option at first blush)


ColdBox Platform Evangelist
Ortus Solutions, Corp

ColdBox Platform:

I'd hoped that using the NPM approach to dependency management was just
temporary. :slight_smile:

Putting copies of stuff everywhere is a pretty bad way to solve the
problem, IMHO.

What I've found to work well is to use mappings for dependencies while
in development, and then for final builds copying everything into a WAR
for optimal deployability (thus you can have debugging settings and
whatnot for development, "reload every time", etc., and "reload never",
no debug, etc., for the deployable).

I don't know how "future-ish" we wanna be, but with OSGi coming in Railo
5, it seems to make sense to accommodate for that resolution approach,
vs. the "copies of dependencies everywhere" approach.