assets/developer-notes/stephanie-gawroriski/2016/12/04.mkd

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