08:58
So what I can do for the suite manager and such is have an API manager so to speak. This only really has to be used by the kernel. I suppose it would be sorted by the API providing stuff or the suite ID. However some things would have to be lower in the class path (configurations).
09:11
So I was thinking, perhaps APIs can instead use instead of MANIFEST.MF, they
can use perhaps say SQUIRRELJME-API.MF or so. Then this could also extend
to other software. Then with a special manifest such as this I can remove the
X-SquirrelJME prefixes in the manifess. This way on build, I could store the
original manifest too. But if MANIFEST.MF exists it can just be merged and
such, in case custom things in the manifest are required. I suppose this
would make it slightly more complex but easier in the long run.
09:17
So then also, the library and application ones could use:
SQUIRRELJME-MIDLET.MF and SQUIRRELJME-LIBLET.MF. Libraries and midlets
would only be valid if they had these things. The build system however
could then just have a simpler SQUIRRELJME-BUILD.MF which is used to
specify which dependencies one thing has without requiring that descriptions
and versions be parsed and such. So the build stuff would be very basic for
the most part. Then I would just need to figure out how to best represent the
various set of APIs and their dependencies along with application
dependencies. Then I would also need another manifest for the build errors
and such. Since right now I just look in the manifest for the build error
prefixes.