nielsbasjes commented on PR #104:
URL: https://github.com/apache/maven-release/pull/104#issuecomment-1191313865
To summarize where I'm stuck with the 'clean' loading of the configuration.
I have been doing some more digging and I think what I would like is not
possible (not like I had initially thought it up).
What I would like is to have as a config of this plugin (simplified):
```
<configuration>
<projectVersionPolicyId>Foo</projectVersionPolicyId>
<projectVersionPolicyConfig>
<fooA>1</fooA>
<fooB>true</fooB>
</projectVersionPolicyConfig>
</configuration>
```
where this is part of the release plugin config
```
<configuration>
<projectVersionPolicyId>Foo</projectVersionPolicyId>
<projectVersionPolicyConfig>
...
</projectVersionPolicyConfig>
</configuration>
```
and this is part of the `Foo` config
```
<fooA>1</fooA>
<fooB>true</fooB>
```
It is only possible to determine the `<fooA>` is a valid tag AFTER the
`<projectVersionPolicyId>` has been read, the mentioned code (`Foo`) has been
loaded and the possible config schema from there has been retrieved.
But in order to get to the `<projectVersionPolicyId>` the system needs to
read (at least) the entire `<configuration>` block; which will fail over the
(then) unknown `<fooA>` part.
I.e. Chicken and egg.
Based on this I now see only two ways to handle this:
1. As I have done now: The extra config is a CDATA string that is handled as
I have written now.
2. As antrun does it: The config can be `any xml` which is not validated
during the initial read.
I'm looking into the latter right now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
