box build unable to resolve missing artifacts: lucee.config

I’ve cloned commandbox from github and I’m trying to build the cli tool on windows with “box-cli.bat build”.

I do not know where to get org/lucee/lucee.config/

It did try to download it from cfdistro repo: but it was unable to find it.

Any tips on this build process would be great. If you have a resource with instructions, them excuse me but I couldn’t find anything, or atleast not recent instructions. I did find instructions for version 2.X of commandbox. Let me know.

C:\Users\daniel.mejia\cfdistro\core\server\cfengine\build-lucee.xml:37: The following error occurred while executing this line:
C:\Users\daniel.mejia\cfdistro\core\server\cfengine\build-lucee.xml:64: The following error occurred while executing this line:
C:\Users\daniel.mejia\cfdistro\core\packager\maven.xml:243: The following error occurred while executing this line:
C:\Users\daniel.mejia\cfdistro\core\packager\maven.xml:89: Unable to resolve artifact: Missing:

by the way. i’m simply attemting to learn about the build process . eventually i would like to contribute to commandbox with fixes or features.

Ok, so I checked out and its true lucee.config does not exist.

I’m not sure what to do here. the build process first required lucee.war- so I installed that one, which now requires lucee.config-

what do i do? I guessing I can change it to 5.2.7.x?

ok. I successfully ran the build using lucee.config, then I successfully ran “box-cli.bat build-cli.exe”.

I think it's using a custom build Micha whipped up maybe, meant to ping
about that but forgot- what you did is what I was going to say to do. :slight_smile:

hmm, that should have came from maven Central. You shouldn’t have to download it at all. What build target did you run? I always do option 5 and then target “build.cli.exe”.

I'm guessing it's not there or something else odd is going on, as I ran
into that too, but didn't think much of it and just changed it to one I
already had locally.

I should add, if all you want to do is hack on the cfml sources, just delete the cfml folder in your install and symlink it to the cfml folder in your repo. I only run the actual build locally when if changed java code or update jar dependencies.

I just realised the missing dependency is Lucee.config, not Lucee. Did you change something in the file? I don’t think that version of that artifact exists.

Duh, should have snapped to that. I can run a build of it, but I think
something else must have changed, I saw that last time I tried a build a
couple days ago IIRC.

We can port the build to gradle-- cfdistro plays just fine with it and I
could toss in that exeSign thing too (assuming not much has changed
since I last looked at it), and I have been wanting to nix the network
requirement of the build for ages now... :wink:

Anyhow, I'll pop a little update into the CI build and things should
work again, but I think maybe build property was maybe modified or some
such if the versions were separate before.

So I was on my phone last night so I apologize for the short, spread out replies :slight_smile: To explain a bit further, that lucee.config artifact is not Lucee itself, but a separate custom little thing Denny builds on his personal build server. It’s simply a zip that contains the default XML lucee config files which we use to help create the internal CLI engine with some settings already in place. Denny’s personal build server doesn’t always have the latest versions build but since the XML config files rarely ever change (and are pretty much 100% backwards compatible) it’s not really a big deal wither the lucee.config artifact is on the newest so long as it’s somewhere in the neighborhood.

If you’re wondering where this personal server is of Denny’s, it’s right here.;O=D

And like I mentioned in my first reply, the actual Lucee jars are downloaded from the official Lucee Maven repo which is updated automatically every time the official Lucee Travis-CI build runs. is a snapshot build of Lucee that I needed to use to get a pull request of mine that Micha had failed to merged into the first release candidate of 5.2.7. Now that final is out (and contains my pull) I’ll probably switch CommandBox 4.0 back to it just so I’m on a stable version.

I’m assuming what happened is you were perusing through the file and saw a Lucee version number in there that seems a little old so you updated it to match the other one which is where things went south since you didn’t realize that lucee.config artifact doesn’t pull from the official Lucee Maven repo, but instead from Denny’s personal CI server which is sometimes a few versions behind.

Does that help clear things up?

Cool. Glad it’s sorted out.

I actually ran “box-cli.bat build” then I ran “box-cli.bat build.cli.exe”, in case you still wondering.

Also I am really curious about the build process and how it’s all glued together with Java. So after looking at the source a little bit I decided to see if I could build it having never done anything with maven or JDK.

Dan Mejia

Denny or I would be happy to explain parts of the build you’re curious about. It does a lot of it’s slightly different for each artifact (*nix binary, exe, etc). You can start by just reading through the Ant build.xml to see an overview. It’s mostly just compiling java, downloading jars, and patching it all together along with the CFML bits. And yes, it should “just work” even if you don’t have anything on your machine but Ant installed. All of the other bits for the build like CFDistro, Launch4J, etc are all downloaded on the fly.

I am really curious about the build process and how it’s all glued together with Java

I wouldn’t say there’s much Java involved in the build. it’s mostly just a giant Ant build that runs other Ant builds. Some of the custom Ant tasks that we have like creating the debs and rpms are written by Denny in java, btu they’re pretty much black boxes.