Le mar. 11 févr. 2025 à 12:17, Thomas Reinhardt <tho...@reinhardt.com> a écrit :
> > Maybe this is unrelated, but I had problems with regard to xml comments > in custom maven plugins in the past. Some of our in-house plugins > rewrite poms and it is always a challenge to preserve existing comments. > I know there is a (partial?) solution that the release plugin uses but > that is hard to implement. At least way harder than it should be. > > The perfect solution would be to read the model with MavenXpp3Reader, > work with the model and write it back with MavenXpp3Writer. But that > always loses the comments, so we need to use plain XML parsing. > > BTW: what exactly is the difference between the MavenXpp3Reader and > MavenXpp3ReaderEx (and the corresponding writer) classes? I was not able > to google anything about those. > The MavenXpp3ReaderEx does record location of each xml element in the object model. > > Feel free to ignore this mail if you think it is completely offtopic. > It's not completely off-topic. One thing that could be done would be to enhance the parser to keep not only the location of the element, but also previously discarded DOM elements (mostly spaces, comments, and maybe the original text elements). Given the model and parser are generated, this limits the amount of work. However, the location tracking already seems quite a bit heavyweight in terms of memory, so I'm not sure we could keep the whole DOM tree in memory and across merges. > > > -Thomas > > > > Mit freundlichen Grüßen, > Thomas Reinhardt > > On 10/02/2025 14:48, Romain Manni-Bucau wrote: > > Maybe we can start by just keeping the comments before or nested in kept > > element and if the comment is before a dropped element (build) we drop it > > as well? Will not reach 100% but maybe be sufficient to start? > > > > Romain Manni-Bucau > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> > | Old > > Blog <http://rmannibucau.wordpress.com> | Github > > <https://github.com/rmannibucau> | LinkedIn > > <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > > > > Le lun. 10 févr. 2025 à 14:47, Xeno Amess <xenoam...@gmail.com> a écrit > : > > > >>> And if you ask for my own idea, I would tend to preserve the comments, > >> until there be better solution > >> but sadly I just think in the shitty xml/xsd world, there might never > be a > >> better solution...... > >> > >> Xeno Amess <xenoam...@gmail.com> 于2025年2月10日周一 21:45写道： > >> > >>>> Side note: technically this doesn't help to move content to tags since > >> we > >>> have the info of comment location and content already, what we miss is > >>> "should we keep it or not" and this is the same for custom xsds - being > >>> worse for XSD when they are nested in kept elements so the other topic > >>> about custom tags can end up being way more complex IMHO. > >>> > >>> YES! you get what I mean and what I worried about exactly. > >>> And if you ask for my own idea, I would tend to preserve the comments, > >>> until there be better solution > >>> > >>> > >>> Romain Manni-Bucau <rmannibu...@gmail.com> 于2025年2月10日周一 21:32写道： > >>> > >>>> Are we saying comments should be written in tags? I think we are > >> starting > >>>> to speak about another topic - which is relevant and mainly "how can > we > >>>> handle external XSD securely" - but comment topic stays, as mentionned > >>>> there are real life use cases for comments where you do not want to go > >>>> with > >>>> a custom xsd nor even a tag since you want to write a comment IMHO. > >>>> > >>>> Side note: technically this doesn't help to move content to tags since > >> we > >>>> have the info of comment location and content already, what we miss is > >>>> "should we keep it or not" and this is the same for custom xsds - > being > >>>> worse for XSD when they are nested in kept elements so the other topic > >>>> about custom tags can end up being way more complex IMHO. > >>>> > >>>> Romain Manni-Bucau > >>>> @rmannibucau <https://x.com/rmannibucau> | .NET Blog > >>>> <https://dotnetbirdie.github.io/> | Blog < > >> https://rmannibucau.github.io/> > >>>> | Old > >>>> Blog <http://rmannibucau.wordpress.com> | Github > >>>> <https://github.com/rmannibucau> | LinkedIn > >>>> <https://www.linkedin.com/in/rmannibucau> | Book > >>>> < > >>>> > >> > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > >>>>> > >>>> > >>>> > >>>> Le lun. 10 févr. 2025 à 14:15, Xeno Amess <xenoam...@gmail.com> a > >> écrit : > >>>> > >>>>> well, adding custom elements, makes it cannot pass xsd, right? > >>>>> or we shall allow any element name? but that would kill typo check, > >>>> like if > >>>>> somebody wrongly said, <dependencys>, and spend a whole day finding > >>>> what be > >>>>> wrong. > >>>>> or is there some way to allow some...prefix?or allow-all-namespace > >> like > >>>>> <custom:property1> or something? > >>>>> > >>>>> Gary Gregory <garydgreg...@gmail.com> 于2025年2月10日周一 20:57写道： > >>>>> > >>>>>> I agree FWIW, this is a problem XML standards solved decades ago. > >>>>> Comments > >>>>>> should be considered invisible, in fact many parsers don't surface > >>>> them. > >>>>>> Between processing instructions and namespaces, a tool should have > >>>> all it > >>>>>> needs IMO. > >>>>>> > >>>>>> Gary > >>>>>> > >>>>>> On Mon, Feb 10, 2025, 07:45 Elliotte Rusty Harold < > >> elh...@ibiblio.org > >>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> On Mon, Feb 10, 2025 at 10:02 AM Xeno Amess <xenoam...@gmail.com> > >>>>> wrote: > >>>>>>>> > >>>>>>>>> Sometimes comments are used to embed additional > >> machine-readable > >>>>>>> metadata. > >>>>>>>> yes and considering somebody would like to use this for a maven > >>>>>> extension > >>>>>>>> or something... > >>>>>>> > >>>>>>> Yes, that's a pretty common antipattern. Embedding other markup > >>>>>>> formats inside XML is baroque, confusing, and tool hostile. The > >>>> better > >>>>>>> approach is to add additional XML markup to the document. In this > >>>>>>> specific instance that means Maven would stop erroring if it sees > >>>>>>> elements it doesn't recognize. That is, it asks the question "Do I > >>>>>>> have everything I need to build this project?" instead of "Do I > >>>>>>> understand every element in this pom?" > >>>>>>> > >>>>>>> A slightly less radical approach would be to ignore elements not > >> in > >>>>>>> Maven's own namespace. > >>>>>>> > >>>>>>> -- > >>>>>>> Elliotte Rusty Harold > >>>>>>> elh...@ibiblio.org > >>>>>>> > >>>>>>> > >>>> --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ------------------------ Guillaume Nodet
