Use id and versionNumber from template application-descriptor

[j3k0]

I understand why id and versionNumber are pulled from the project config file, they're a bit of a special because they're probably the only fields absolutely required to get a valid application descriptor (when not using a source application-descriptor.xml I mean)

In our case, I would rather not use the values in the project.apm file and use values in the source xml file. However even setting them to null in the project config, it always erases the values I set.

[marchbold]

These values are used through the additions merge process as well so it is important that they match. I'm actually more inclined to go the other way and provide more options in the project config than remove them.

Can you explain why you wouldn't want to have an accurate representation in the project file?

[j3k0]

It's a design choice:

1 project.apm aims to become the only source of truth, then it needs to be a full layer above the application descriptor.

• in this scenario, the application descriptor is like an internal file format, never touched by the user.
• all documentation and answered questions that exists online, explaining what to change in the application descriptor to fix certain issues, it's kinda invalidated.
• more work.

2. apm is a tool to manage the manifest and plist additions.

• in this scenario, the application descriptor is the source of truth, project.apm only adds dependencies and configuration.

I was under the impression you were aiming for case 2 (not a full replacement for the app descriptor).

Additional thoughts. Have you considered making the project configuration an XML file? All AIR-related config files tend to be XML, our internal tooling is equipped for parsing XML, not JSON (which I like more, as a human, but you know, legacy...).

What if the config file was an extension of the application descriptor? Something like this:

<application>
  <id>my.id</id>
  <name>
    <text xml:lang="en">My App</text>
  </name>
  <versionNumber>1.15.0</versionNumber>
  <filename>App</filename>
  <description>
    <text xml:lang="en">App</text>
  </description>
  <copyright>Copyright 2016-2021, Fovea</copyright>
  <supportedLanguages>en fr es de ja ko nl pt pl</supportedLanguages>

  <initialWindow>
    <aspectRatio>landscape</aspectRatio>
    <renderMode>direct</renderMode>
    <autoOrients>true</autoOrients>
    <fullScreen>true</fullScreen>
    <visible>true</visible>
    <softKeyboardBehavior>none</softKeyboardBehavior>
  </initialWindow>

  <!--- NEW STUFF HERE --->

  <dependencies>
    <dependency>
      <id>starling-source</id>
      <version>2.7.0</version>
    </dependency>
  </dependencies>

  <configurations>
    <configuration key="getTaskAllow">false</configuration>
  </configurations>
</application>

That would also make scenario 1 almost immediate, right? Also that gives an almost immediate migration process to apm (apm would understand existing projects). Also existing knowledge still apply to apm.

Just an idea...

[marchbold]

What I am aiming for is sort of like what you outline in 1, however not just replacing the app descriptor with the project.apm file, but with the apm tool itself. Both files would then be transparent to a developer except in advanced cases.

apm will be able to control all aspects of project.apm so this file format should be irrelevant, except in development and again advanced usage. This is even why we chose a different extension so as to clearly distinguish it.

I actually see potential to take the tool even further, with generating icons (including Assets.car / launch screens - which would be inserted into the app descriptor), build configurations for IDEs, and potentially even assembling build scripts. If this becomes the entry point for all libs, the majority of the information for configuring a build is contained here already.

The current approach of using the existing application descriptor as a template, is pretty much what you are suggesting. It allows immediate migration for an existing project, (as long as packages are available for all the ANEs in use) to apm with just supply of the application id and version (which is requested in the init process). It also allows all existing knowledge to apply. Also I think any existing documentation on what to change in the app descriptor would have a 1-to-1 corresponding fix in apm.

Maybe we could provide an option to apm init to process an existing app descriptor as an alternative to entering them manually?

[j3k0]

As far as we're concerned, apm as a dependencies manager is very useful, we don't need more. Concerning the application descriptor, if it had only taken responsibility of the manifest/info additions and extensionsID it would have made our life easier.

See #60 and #61 - Until all possible cases of what is possible in the application descriptor are handled, apm creates some unforeseen road-blocks which makes the tool a bit less practical that it could be, whereas it is just perfect at solving what needed to be solved: dependencies management.

[marchbold]

Yeah sure, perhaps I'll just allow empty values in those fields and do nothing with them in the meantime.

XML issues will need to be fixed either way as we still need to read and write the app descriptor to insert the other information.