[jira] [Created] (ACE-468) Improve & simplify template processing for configurations

["J.W. Janssen (JIRA)" <ji...@apache.org>]

J.W. Janssen created ACE-468:
--------------------------------

             Summary: Improve & simplify template processing for configurations
                 Key: ACE-468
                 URL: https://issues.apache.org/jira/browse/ACE-468
             Project: ACE
          Issue Type: Improvement
    Affects Versions: 1.0.0
            Reporter: J.W. Janssen


Currently, ACE will *always* process *all* autoconf files as template, even if these files do not need any processing at all. Not only is this an incorrect assumption, but also a waste of both resources and processing power.

It would be better if autoconf files could be "annotated" with metadata in order to let them specify whether or not template processing is desired for that file. This way, we only need to preprocess these files when needed and can simply copy all other files as-is. 

In the general case, for this to work, we need to provide additional metadata with each artifact that specifies whether or not it is a template and if so, what processor it wants to be processed with. For many artifacts, such as bundles, JPEG images and so on, it is already possible to specify additional metadata that can be used by ACE. For other files, such as the autoconf files, this is not directly possible, but we can specify such metadata using, for example, a XML comment.

This issue is about changing the following:

* add one (or two) fixed attribute(s) to {{ArtifactObject}} that specifies if and what preprocessor should be used for an artifact;
* modify the existing {{ConfigurationHelperImpl}} to fill these attributes for all *new* artifacts that are processed by it;
* change the {{ArtifactRepositoryImpl#needsNewVersion}} to take the new attributes into consideration. When no attributes are present, it will assume the current behaviour of always invoking the preprocessor.

By letting an artifact specify what template processor it wants to be processed by gives a lot of flexibility that the current mechanism lacks.




--
This message was sent by Atlassian JIRA
(v6.2#6252)