Unable to call parse() methods in plugins due to DSL parser validation additional curly brace validation

[mattjamison]

Description

I noticed when testing with the latest structurizr-lite client, that a java plugin I've been using to parse a small DSL fragment via the exposed parse() method now throws an exception. I tracked back to commit 545cd230b176dd9e85decd9909c20e21365d4687, which pulls in the structurizr-java version including the curly brace validation in issue 252.

The plugin is really simple, it walks the project files, parsing and including small DSL fragments containing style definitions. I'm doing this to essentially allow the addition of any number of *.style files to our project, that the plugin will read and include in the final workspace. I'm definitely open to any other methods to accomplish this. What I would have love to have done instead is used a glob with the !include directive for example, but I don't believe that's possible and thus the plugin.

I'm happy to submit a PR with what I think is a simpler fix, which would be to expose a parse() method with the boolean include parameter, which essentially disables the problematic validation for internal uses of parse().

Steps to reproduce

1. Utilize a structurizr-lite version >= v2024.03.02 (545cd230b176dd9e85decd9909c20e21365d4687)
2. Call the parse() method from a plugin:
   context.getDslParser().parse(path.toFile());
3. Exception thrown:
   com.structurizr.dsl.StructurizrDslParserException: Unexpected end of DSL content - are one or more closing curly braces missing?

Screenshot

No response

Code sample

`context.getDslParser().parse(path.toFile());`

Configuration

No response

Severity

Minor

Priority

I'm willing to fix this myself and raise a PR (please confirm approach first)

More information

No response

[simonbrowndotje]

I'd probably just recommend placing all of the .style files in a single folder (e.g. styles), and using !include styles instead of building a plugin.

[mattjamison]

I was hoping not to have to reorganize the project, it's currently got a decently deep structure of directories to organize things by team/project, but if this isn't something worth fixing then your suggestion is probably the best bet. If you are willing to take the small PR to expose the include boolean in an additional parse method, I'm happy to submit it. In either case though, thank you for the quick reply!