Re: Build windows-jdk11
Maybe works on some notes, not on others? The build I tested (linked in the issue) worked later on. But I didn't check which node it ran on. On Mon, 7 Jun 2021, 20:08 Robert Scholte, wrote: > I don't understand why INFRA-21954 was closed, the issue is still > occurring. > I've changed INFRA-21690 to blocker, but still no response. > > Robert > On 7-6-2021 15:32:29, Benjamin Marwell wrote: > I also opened > > https://issues.apache.org/jira/browse/INFRA-21954 > > #asfinfra on slack > > On Mon, 7 Jun 2021, 14:52 Michael Osipov, wrote: > > > Am 2021-06-07 um 14:36 schrieb Elliotte Rusty Harold: > > > Build windows-jdk11 has been broken for a week+ now. Anyone want to > > > take a look? I couldn't find any useful log output. > > > > > > https://issues.apache.org/jira/browse/INFRA-21690 > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: Build windows-jdk11
I don't understand why INFRA-21954 was closed, the issue is still occurring. I've changed INFRA-21690 to blocker, but still no response. Robert On 7-6-2021 15:32:29, Benjamin Marwell wrote: I also opened https://issues.apache.org/jira/browse/INFRA-21954 #asfinfra on slack On Mon, 7 Jun 2021, 14:52 Michael Osipov, wrote: > Am 2021-06-07 um 14:36 schrieb Elliotte Rusty Harold: > > Build windows-jdk11 has been broken for a week+ now. Anyone want to > > take a look? I couldn't find any useful log output. > > > https://issues.apache.org/jira/browse/INFRA-21690 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Moving away from Modello
Robert Scholte wrote: > Well, where is the need for additional namespaces and how they be handled? > The reader has a strict mode, should it fail or ignore unknown tags? > I am aware of one request: adding a namespace on plugins configuration (to > validate its content), however the configuration-element is part of the maven > namespace, so I don't think this will work. Yes, unless you want namespace prefixes, which is awkward for children. However, there is one area where I would have liked better namespace support in the past, namely when plugins need free-form XML elements. The most well-known use case is the maven-antrun-plugin's configuration element, which is of type PlexusConfiguration. AFAIK, the following won't work with a PlexusConfiguration target: http://example.org/;> 42 The PlexusConfiguration would only give you access to the QName "ex:example" with no way to determine what URI the "ex" namespace prefix is bound to. You would have to write it like this: http://example.org/;> 42 Now that might not seem like a big difference, but remember that you could move the xmlns:ex declaration all the way up to the project element and thereby sharing it among multiple elements. FYI, the use case I had in the past was configuring XQuery/XSLT engines, whose external variables and configuration options are namespaced: http://example.org/; xmlsns:xs="http://www.w3.org/2001/XMLSchema; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;> 42 Not being able to place those namespace declarations on the root element really hurts, in particular as the XMLSchema-instance namespace is normally already declared there -- but you cannot "see" that from your PlexusConfiguration. Note that this is *not* an argument in favour of dropping Modello; it is just an argument in favour of better namespace support (or rather awareness) in something like PlexusConfiguration. Best wishes, Andreas Sewe OpenPGP_signature Description: OpenPGP digital signature
Re: Moving away from Modello
On Mon, Jun 7, 2021 at 2:11 PM Guillaume Nodet wrote: > > There are current issues in our pom.xml parsing, particularly around > > namespaces, that aren't going to be resolved until we get rid of or > > fix Modello, and possibly that's going to require fixing XPP3. I don't > > know. However the XML parser should be an implementation detail. > > > > Which parsing problems exactly ? I used the MXParser / XPP3 for the Camel > reader and it has full support for namespaces afaik. > It's been a few months (or a year?) since I dug into this. Might just be Modello, not XPP3; I'm no longer sure. The fundamental mistake is that Maven allows pom.xml both with and without namespace declarations, and possibly does not properly handle prefixed element names. (It's been a little while so I might not remember every detail.) Either way, this misunderstanding makes it extremely difficult to process pom.xml files with standard XML tools such as XSLT and XQuery. This cost me a lot of extra work circa 2019/2020 when I was writing tooling that needed to process pom.xml files to follow dependency chains. At one point I dug into the code to see how hard it would be to repair this and let Maven work with XML namespaces instead of against them. Most of the offending code proved to be in plexus rather than maven itself, and it was made far more opaque by the multiple extra levels of indirection in the various frameworks like Modello that Maven sits on top of. -- 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
Re: Moving away from Modello
Well, where is the need for additional namespaces and how they be handled? The reader has a strict mode, should it fail or ignore unknown tags? I am aware of one request: adding a namespace on plugins configuration (to validate its content), however the configuration-element is part of the maven namespace, so I don't think this will work. thanks, Robert On 7-6-2021 15:37:17, Elliotte Rusty Harold wrote: On Mon, Jun 7, 2021 at 1:21 PM Guillaume Nodet wrote: > > The generated xml readers are used to actually read the pom. That's an > important part :-) > I spent quite some time profiling those and XPP3 is really fast, so I'd > really like to avoid using JAXB for that. > > I agree with not using JAXB. It's a poorly designed API that causes more problems than it solves, though I could say the same for all the other data binding APIs out there. Not just for XML either. JSON and SQL data binding APIs suffer from the same flawed goal of avoiding writing the code necessary to understand the data. It never works and it always ends up costing more in the end. There are current issues in our pom.xml parsing, particularly around namespaces, that aren't going to be resolved until we get rid of or fix Modello, and possibly that's going to require fixing XPP3. I don't know. However the XML parser should be an implementation detail. -- 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
Re: [VOTE] Release Maven Dependency Plugin version 3.2.0
+1 On Mon, Jun 7, 2021, 14:29 Michael Osipov wrote: > Hi, > > We solved 9 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348705=Html=12317227 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MDEP/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1650/ > > https://repository.apache.org/content/repositories/maven-1650/org/apache/maven/plugins/maven-dependency-plugin/3.2.0/maven-dependency-plugin-3.2.0-source-release.zip > > Source release checksum(s): > maven-dependency-plugin-3.2.0-source-release.zip > sha512: > > f33780ed0ceb08d2d78115dc0c4306aaa1bf5bfd0a730d6709e42e7a34ac1b35da8258afa0bfeb7c122129a3383be170b1827a38b120d1bb287e8ca668f87343 > > Staging site: > https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Moving away from Modello
Le lun. 7 juin 2021 à 15:37, Elliotte Rusty Harold a écrit : > On Mon, Jun 7, 2021 at 1:21 PM Guillaume Nodet wrote: > > > > The generated xml readers are used to actually read the pom. That's an > > important part :-) > > I spent quite some time profiling those and XPP3 is really fast, so I'd > > really like to avoid using JAXB for that. > > > > > > I agree with not using JAXB. It's a poorly designed API that causes > more problems than it solves, though I could say the same for all the > other data binding APIs out there. Not just for XML either. JSON and > SQL data binding APIs suffer from the same flawed goal of avoiding > writing the code necessary to understand the data. It never works and > it always ends up costing more in the end. > When I was working on an alternative to JAXB for Camel, I ended up writing a simple generator that generates the reader + xsd from POJOs. > > There are current issues in our pom.xml parsing, particularly around > namespaces, that aren't going to be resolved until we get rid of or > fix Modello, and possibly that's going to require fixing XPP3. I don't > know. However the XML parser should be an implementation detail. > Which parsing problems exactly ? I used the MXParser / XPP3 for the Camel reader and it has full support for namespaces afaik. > > -- > 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 > > -- Guillaume Nodet
Re: Moving away from Modello
On Mon, Jun 7, 2021 at 1:21 PM Guillaume Nodet wrote: > > The generated xml readers are used to actually read the pom. That's an > important part :-) > I spent quite some time profiling those and XPP3 is really fast, so I'd > really like to avoid using JAXB for that. > > I agree with not using JAXB. It's a poorly designed API that causes more problems than it solves, though I could say the same for all the other data binding APIs out there. Not just for XML either. JSON and SQL data binding APIs suffer from the same flawed goal of avoiding writing the code necessary to understand the data. It never works and it always ends up costing more in the end. There are current issues in our pom.xml parsing, particularly around namespaces, that aren't going to be resolved until we get rid of or fix Modello, and possibly that's going to require fixing XPP3. I don't know. However the XML parser should be an implementation detail. -- 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
Re: Build windows-jdk11
I also opened https://issues.apache.org/jira/browse/INFRA-21954 #asfinfra on slack On Mon, 7 Jun 2021, 14:52 Michael Osipov, wrote: > Am 2021-06-07 um 14:36 schrieb Elliotte Rusty Harold: > > Build windows-jdk11 has been broken for a week+ now. Anyone want to > > take a look? I couldn't find any useful log output. > > > https://issues.apache.org/jira/browse/INFRA-21690 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Moving away from Modello
Le lun. 7 juin 2021 à 14:49, Elliotte Rusty Harold a écrit : > On Wed, Jun 2, 2021 at 6:53 PM Hervé BOUTEMY > wrote: > > > > I don't get how Modello got in your way on these issues: please explain > > And it works perfectly on Eclipse: there is a m2e extension for Modello > that > > does the job. > > I assume you're referring to the unsigned, pre-1.0 extensions that > corporate security policy prohibits installing. The details don't > really matter though. Every extra tool introduced into the build > process is one extra piece to break in some environment that makes the > build more fragile and makes it that much harder to bring on new > developers. > > > from a Modello model, we generate: > > - Java objects > > - serializers and deserializers: there are other options for some APIs, > but > > not for XPP3 AFAIK > > - XML format documentation > > - xsd > > with consistent explanation on each field: how do you expect to keep > that? > > > > Other than the Java objects, which can trivially be pure Java code, > when do we use any of those? It all feels like YAGNI to me. > The generated xml readers are used to actually read the pom. That's an important part :-) I spent quite some time profiling those and XPP3 is really fast, so I'd really like to avoid using JAXB for that. > > -- > 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 > > -- Guillaume Nodet
Re: [VOTE] Release Maven Dependency Plugin version 3.2.0
+1 W dniu pon., 7.06.2021 o 14:29 Michael Osipov napisał(a): > Hi, > > We solved 9 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348705=Html=12317227 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MDEP/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1650/ > > https://repository.apache.org/content/repositories/maven-1650/org/apache/maven/plugins/maven-dependency-plugin/3.2.0/maven-dependency-plugin-3.2.0-source-release.zip > > Source release checksum(s): > maven-dependency-plugin-3.2.0-source-release.zip > sha512: > > f33780ed0ceb08d2d78115dc0c4306aaa1bf5bfd0a730d6709e42e7a34ac1b35da8258afa0bfeb7c122129a3383be170b1827a38b120d1bb287e8ca668f87343 > > Staging site: > https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Build windows-jdk11
Am 2021-06-07 um 14:36 schrieb Elliotte Rusty Harold: Build windows-jdk11 has been broken for a week+ now. Anyone want to take a look? I couldn't find any useful log output. https://issues.apache.org/jira/browse/INFRA-21690 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Dependency Plugin version 3.2.0
+1 On Mon, Jun 7, 2021 at 12:29 PM Michael Osipov wrote: > > Hi, > > We solved 9 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348705=Html=12317227 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MDEP/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1650/ > https://repository.apache.org/content/repositories/maven-1650/org/apache/maven/plugins/maven-dependency-plugin/3.2.0/maven-dependency-plugin-3.2.0-source-release.zip > > Source release checksum(s): > maven-dependency-plugin-3.2.0-source-release.zip > sha512: > f33780ed0ceb08d2d78115dc0c4306aaa1bf5bfd0a730d6709e42e7a34ac1b35da8258afa0bfeb7c122129a3383be170b1827a38b120d1bb287e8ca668f87343 > > Staging site: > https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- 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
Re: Moving away from Modello
On Wed, Jun 2, 2021 at 6:53 PM Hervé BOUTEMY wrote: > > I don't get how Modello got in your way on these issues: please explain > And it works perfectly on Eclipse: there is a m2e extension for Modello that > does the job. I assume you're referring to the unsigned, pre-1.0 extensions that corporate security policy prohibits installing. The details don't really matter though. Every extra tool introduced into the build process is one extra piece to break in some environment that makes the build more fragile and makes it that much harder to bring on new developers. > from a Modello model, we generate: > - Java objects > - serializers and deserializers: there are other options for some APIs, but > not for XPP3 AFAIK > - XML format documentation > - xsd > with consistent explanation on each field: how do you expect to keep that? > Other than the Java objects, which can trivially be pure Java code, when do we use any of those? It all feels like YAGNI to me. -- 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
Build windows-jdk11
Build windows-jdk11 has been broken for a week+ now. Anyone want to take a look? I couldn't find any useful log output. -- 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
[VOTE] Release Maven Dependency Plugin version 3.2.0
Hi, We solved 9 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348705=Html=12317227 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/projects/MDEP/issues Staging repo: https://repository.apache.org/content/repositories/maven-1650/ https://repository.apache.org/content/repositories/maven-1650/org/apache/maven/plugins/maven-dependency-plugin/3.2.0/maven-dependency-plugin-3.2.0-source-release.zip Source release checksum(s): maven-dependency-plugin-3.2.0-source-release.zip sha512: f33780ed0ceb08d2d78115dc0c4306aaa1bf5bfd0a730d6709e42e7a34ac1b35da8258afa0bfeb7c122129a3383be170b1827a38b120d1bb287e8ca668f87343 Staging site: https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
