<build>
<exclude file="filename.mc"/>
<exclude dir="source-excluded" />
<exclude annotation="roundImpl"/>
</build>
fr735xt.sourcePath=$(fr735xt.sourcePath);sourcefolder1\source1.mc;sourcefolder1\source2.mc;sourcefolder2\*.mc
fr735xt.excludeAnnotations=roundImpl
# Exclude "trash" folder
base.sourcePath = source/*.mc; source/class/*.mc
I don't get it. I created folder on the same level as "source" dir, copied here class and immediately got error about duplicate classes. So from my testing I assuming that in base.sourcePath are all available *mc files in the project. So what is benefit of your first example with sourcefolder1?
I get the usage of resoucePath, where you can override resources definitions by specific order. But you can't do it with sourcePath definition - so why to use it?
The problem is by default it looks for .mc files in general, so it's not just looking under source.
Here's a part of a jungles file where I have source, with the common stuff, and two other dirs at the same level - one for breadcrumbs, one for the mapping api.
srcBase=source resBase=resources base.sourcePath=$(srcBase);source-nomaps base.resourcePath=$(resBase) fenix5x.sourcePath = $(srcBase);source-maps fenix5x.resourcePath = $(resBase);resources-maps
So, for the f5x, I use source-maps instead of souce-nomaps, and also use the resources for maps (really only the markers I use) in addition to the base resources