[MNG-7805] Make the modelVersion optional when using build pom #1148
Conversation
|
What about non-empty schema prefix? E..g, |
I've added a test. |
|
Maybe we should also add a test case that proves the |
Done, the two tests, now check the stability of the xml when |
gnodet
force-pushed
the
MNG-7805-make-modelVersion-optional
branch
from
36a513e
to
d06eb95
Compare
gnodet
force-pushed
the
MNG-7805-make-modelVersion-optional
branch
from
d06eb95
to
97e8a4c
Compare
|
Maybe we can just drop consumer stuff, since as we proved, model can "move" with existing tech as well? Am just worried about gigantic projects and their heap requirements.. |
That's really not what the discussions on dev@ seem to lead to. The problem does not seem to be maven, but "other"(?) tools which we would not want to break by upgrading the model. So we'll have to forever produce a consumer pom, which means introducing a bom packaging (to differentiate between parent poms and consumed boms). However, I think we should flatten it, so that the used schema is minimal and it will also make things much faster in the long term when all dependencies are flattened. |
JIRA issue: https://issues.apache.org/jira/browse/MNG-7805
The downside of this PR is that if the build/consumer feature is enabled, all poms will be parsed as events and kept in memory by the
ModelVersionXMLFilter. The reason is that in theory, themodelVersionelement can be the last element of the rootprojectelement. Given the way the build/consumer POM feature is implemented, the same mechanism is used to read the POM (i.e. xml to object model) and rewrite it (when installing/deploying), so that the transformed XML has to be clean wrt formatting, etc...A possible performance improvement would be to have filters operate in two modes, the first one during the first phase (I.e. xml element ordering, formatting is irrelevant, and this phase could even be done on the object model) and a second one to rewrite the POM.
But I think the performance loss is quite negligible as the number of POMs parsed with the build/consumer feature filter enabled is the number of projects in the reactor, so it should be usually an order of magnitude lower than the total number of POMs parsed for plugins / dependencies.