[VOTE] Release Apache ASF parent 30
Hi, We solved 25 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250&version=12352680 Commits: https://github.com/apache/maven-apache-parent/compare/apache-29...apache-30 Staging repo: https://repository.apache.org/content/repositories/orgapacheapache-1035/ https://repository.apache.org/content/repositories/orgapacheapache-1035/org/apache/apache/30/apache-30-source-release.zip Source release checksum(s): apache-30-source-release.zip - SHA-512 : 3c2557de0d8b1a1bfb36d67e7e17cdf338f9812ccb9fd030eedb3ff4693fbac38980bfe022dc033fe454b28f2e49ddedb768c52a62c83b82e1ad0041b5ff9ac7 Staging site: https://maven.apache.org/pom-archives/asf-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at least 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Sławomir Jaranowski
Re: [VOTE] Release Apache ASF parent 30
Am 2023-06-11 um 19:02 schrieb Slawomir Jaranowski: Hi, We solved 25 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250&version=12352680 Commits: https://github.com/apache/maven-apache-parent/compare/apache-29...apache-30 Staging repo: https://repository.apache.org/content/repositories/orgapacheapache-1035/ https://repository.apache.org/content/repositories/orgapacheapache-1035/org/apache/apache/30/apache-30-source-release.zip Source release checksum(s): apache-30-source-release.zip - SHA-512 : 3c2557de0d8b1a1bfb36d67e7e17cdf338f9812ccb9fd030eedb3ff4693fbac38980bfe022dc033fe454b28f2e49ddedb768c52a62c83b82e1ad0041b5ff9ac7 Staging site: https://maven.apache.org/pom-archives/asf-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at least 72 hours. Insane! +1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache ASF parent 30
+1 On Sun, Jun 11, 2023 at 7:02 PM Slawomir Jaranowski wrote: > Hi, > > We solved 25 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250&version=12352680 > > Commits: > https://github.com/apache/maven-apache-parent/compare/apache-29...apache-30 > > Staging repo: > https://repository.apache.org/content/repositories/orgapacheapache-1035/ > > https://repository.apache.org/content/repositories/orgapacheapache-1035/org/apache/apache/30/apache-30-source-release.zip > > Source release checksum(s): > apache-30-source-release.zip - SHA-512 : > > 3c2557de0d8b1a1bfb36d67e7e17cdf338f9812ccb9fd030eedb3ff4693fbac38980bfe022dc033fe454b28f2e49ddedb768c52a62c83b82e1ad0041b5ff9ac7 > > Staging site: > https://maven.apache.org/pom-archives/asf-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski >
[VOTE] Release Maven Invoker Plugin version 3.6.0
Hi, we solved 8 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317525&version=12353076 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINVOKER%20AND%20resolution%20%3D%20Unresolved Staging repo: https://repository.apache.org/content/repositories/maven-1954/ https://repository.apache.org/content/repositories/maven-1954/org/apache/maven/plugins/maven-invoker-plugin/3.6.0/maven-invoker-plugin-3.6.0-source-release.zip Source release checksum(s): maven-invoker-plugin-3.6.0-source-release.zip sha512: ed73a73536577de505c2c09b09ad644dcd4e1b957c785dc48d3481c67ba5f598ba5095d125d3d54414fde02226fb638536e1bcdc7618b23515d224184af3fdf2 Staging site: https://maven.apache.org/plugins-archives/maven-invoker-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: [VOTE] Release Apache ASF parent 30
+1 niedz., 11 cze 2023, 19:15 użytkownik Tamás Cservenák napisał: > +1 > > On Sun, Jun 11, 2023 at 7:02 PM Slawomir Jaranowski < > s.jaranow...@gmail.com> > wrote: > > > Hi, > > > > We solved 25 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250&version=12352680 > > > > Commits: > > > https://github.com/apache/maven-apache-parent/compare/apache-29...apache-30 > > > > Staging repo: > > https://repository.apache.org/content/repositories/orgapacheapache-1035/ > > > > > https://repository.apache.org/content/repositories/orgapacheapache-1035/org/apache/apache/30/apache-30-source-release.zip > > > > Source release checksum(s): > > apache-30-source-release.zip - SHA-512 : > > > > > 3c2557de0d8b1a1bfb36d67e7e17cdf338f9812ccb9fd030eedb3ff4693fbac38980bfe022dc033fe454b28f2e49ddedb768c52a62c83b82e1ad0041b5ff9ac7 > > > > Staging site: > > https://maven.apache.org/pom-archives/asf-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > -- > > Sławomir Jaranowski > > >
Re: [VOTE] Release Apache ASF parent 30
+1 Le dim. 11 juin 2023 à 19:02, Slawomir Jaranowski a écrit : > Hi, > > We solved 25 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250&version=12352680 > > Commits: > https://github.com/apache/maven-apache-parent/compare/apache-29...apache-30 > > Staging repo: > https://repository.apache.org/content/repositories/orgapacheapache-1035/ > > https://repository.apache.org/content/repositories/orgapacheapache-1035/org/apache/apache/30/apache-30-source-release.zip > > Source release checksum(s): > apache-30-source-release.zip - SHA-512 : > > 3c2557de0d8b1a1bfb36d67e7e17cdf338f9812ccb9fd030eedb3ff4693fbac38980bfe022dc033fe454b28f2e49ddedb768c52a62c83b82e1ad0041b5ff9ac7 > > Staging site: > https://maven.apache.org/pom-archives/asf-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski > -- Guillaume Nodet
[VOTE] Release Maven WAR Plugin version 3.4.0
Hi, we solved 17 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121&version=12350597 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/projects/MWAR/issues Staging repo: https://repository.apache.org/content/repositories/maven-1955/ https://repository.apache.org/content/repositories/maven-1955/org/apache/maven/plugins/maven-war-plugin/3.4.0/maven-war-plugin-3.4.0-source-release.zip Source release checksum(s): maven-war-plugin-3.4.0-source-release.zip sha512: ef7b2621697024570522a778318106f1e5ca18bf6944cb9e43e693e8c37312af272036f517d03b3555622f9bad695217ececa078affda6442d76063b5153f998 Staging site: https://maven.apache.org/plugins-archives/maven-war-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: [VOTE] Release Maven WAR Plugin version 3.4.0
+1 On Sun, Jun 11, 2023, 22:14 Michael Osipov wrote: > Hi, > > we solved 17 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121&version=12350597 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MWAR/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1955/ > > https://repository.apache.org/content/repositories/maven-1955/org/apache/maven/plugins/maven-war-plugin/3.4.0/maven-war-plugin-3.4.0-source-release.zip > > Source release checksum(s): > maven-war-plugin-3.4.0-source-release.zip > sha512: > > ef7b2621697024570522a778318106f1e5ca18bf6944cb9e43e693e8c37312af272036f517d03b3555622f9bad695217ececa078affda6442d76063b5153f998 > > Staging site: > https://maven.apache.org/plugins-archives/maven-war-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 > >
Build POM and consumer POM (was Re: [DISCUSS] POM model version
Those are actually two different questions, but I'd like to raise those together, since they do affect the same feature. 1/ We currently don't have an XML schema for the build POM. One possibility would be to relax a bit the constraints on the main POM schema ( http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are not mandatory in the xml. By not modifying the validation rules, those elements will have to be present in the object model, so that should be safe. Another option would be to have a separate schema, but given the small set of changes on the build pom on the current constraints, i think the first solution would be better. As a reminder, the build pom supports: inferring version for artifacts that are part of the reactor (that's usually done using managedVersion), inferring the relativePath element, ci friendly interpolation for the version. 2/ the consumer POM could be streamlined much more using the same techniques than used in the flatten-maven-plugin. Currently, we're only removing the element, but we could remove the full build section, flatten dependencies, etc... Packaged artifacts (i.e. with a non pom packaging), can only be used as dependencies, so I think the whole flattening process could make sense. Is there any drawback in doing so ? Any particular reason the consumer POM support is limited to removing modules and does not go further ? I can see some discussion in https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM but those do not seem to be settled. Le ven. 9 juin 2023 à 11:22, Guillaume Nodet a écrit : > > > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy a > écrit : > >> adding a new POM element in build POM was supposed to be something for >> Maven 5 >> and to trigger a POM 5 version, to make clear that we are leaving the >> Maven 3 >> space (that uses POM version 4, hence the need for version clarification >> between Maven and it POM model version) >> >> if we enter that space before having released Maven 4, we're adding more >> complexity: do you really want to work on Maven 5 now? >> >> >> another aspect: >> do we want to have this new improvement only for Maven 4/5 or also have >> it for >> Maven 3.9? >> in Maven 3.9, such little enhancement were implemented as XML attributes >> > > Fwiw, if I reduce the diff between the XSD generated with 3.0 and with > 3.9.x, I end up with the following diff > https://gist.github.com/gnodet/f8dfd3206ebf55d6e4610a25e683120b > So, you're right, no new elements have been introduced. A few attributes > added, one element removed. > > However I really don't understand how adding an attribute vs an element > makes the POM more compatible. Our own generated parser will reject any > unknown new attribute the same way as an unknown element (that's for any > maven 3.x version). Here's what happen if I use a maven 3.2.5 to read a POM > with an element that has been introduced later: > https://gist.github.com/gnodet/35a3ad4d449e586dc282c08eacc82ed0 > So I'm not really buying the argument about attribute / element at this > point. If that could be clarified, it would be nice ! > > So I think the question comes down to: do we prefer modifying/overwriting > the schema as we did in the past or do we prefer cleanly versioning it. In > both cases, I think we need to keep it compatible, i.e. only add > elements/attributes. The first option is much easier to implement: just do > nothing as we did in the past, but this has the drawback of not giving > people/tools much warning or information about possible changes. We simply > overwrite the schema from the web site with the latest one at each release, > hoping that tools will not see the change and that they don't really cache > the schema (in case you really need the latest). The other option is to > more properly version the schema. This would need additional code if we > want to correctly detect which version is the lower version needed to > correctly write a given POM. But even for doc changes, I think it may be > preferable to micro version the schemas. > > The scm.child.xxx attributes that were added are not meaningful for the > consumer afaik: they are used for build time and for doc, when you use an > artifact as a dependency (i.e. on the consumer side), those attributes > won't be used. So from a consumer POV, they don't carry any semantics and > can safely be silently discarded. This is also the case for this new > priority attribute, as it only affects the current project or child > projects. In that sense this new feature could just be silently added to > the schema as previous things, so I'm fine with not versioning the schema > now if that's the consensus. > > The problem (and that's really something we need to fix), is that we don't > any real difference between the build POM and the consumer POM schemas. We > also don't make a real difference between consuming as a bom / dependency / > plugin, and consuming as a parent. Both cases are rea
Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version
Le dim. 11 juin 2023 à 22:28, Guillaume Nodet a écrit : > Those are actually two different questions, but I'd like to raise those > together, since they do affect the same feature. > > 1/ We currently don't have an XML schema for the build POM. One > possibility would be to relax a bit the constraints on the main POM schema > ( > http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are not > mandatory in the xml. By not modifying the validation rules, those > elements will have to be present in the object model, so that should be > safe. Another option would be to have a separate schema, but given the > small set of changes on the build pom on the current constraints, i > think the first solution would be better. As a reminder, the build pom > supports: inferring version for artifacts that are part of the reactor > (that's usually done using managedVersion), inferring the relativePath > element, ci friendly interpolation for the version. > +1 to relax > > 2/ the consumer POM could be streamlined much more using the same > techniques than used in the flatten-maven-plugin. Currently, we're only > removing the element, but we could remove the full build section, > flatten dependencies, etc... Packaged artifacts (i.e. with a non pom > packaging), can only be used as dependencies, so I think the whole > flattening process could make sense. Is there any drawback in doing so ? > Any particular reason the consumer POM support is limited to removing > modules and does not go further ? I can see some discussion in > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM > but > those do not seem to be settled. > Doesnt flattening break transitive dep resolution since depth changes? Also drops some build meta which cant be resoled anymore portably like compiler setup, which graalvm version was used and lastly would need to drop or not props not used elsewhere. Think staying as close as possible of the source is overall good to consume as intended (build control) until the transformer is fully configurable (never hopefully since it sounds overcomplicated). > Le ven. 9 juin 2023 à 11:22, Guillaume Nodet a écrit : > > > > > > > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy a > > écrit : > > > >> adding a new POM element in build POM was supposed to be something for > >> Maven 5 > >> and to trigger a POM 5 version, to make clear that we are leaving the > >> Maven 3 > >> space (that uses POM version 4, hence the need for version clarification > >> between Maven and it POM model version) > >> > >> if we enter that space before having released Maven 4, we're adding more > >> complexity: do you really want to work on Maven 5 now? > >> > >> > >> another aspect: > >> do we want to have this new improvement only for Maven 4/5 or also have > >> it for > >> Maven 3.9? > >> in Maven 3.9, such little enhancement were implemented as XML attributes > >> > > > > Fwiw, if I reduce the diff between the XSD generated with 3.0 and with > > 3.9.x, I end up with the following diff > > https://gist.github.com/gnodet/f8dfd3206ebf55d6e4610a25e683120b > > So, you're right, no new elements have been introduced. A few attributes > > added, one element removed. > > > > However I really don't understand how adding an attribute vs an element > > makes the POM more compatible. Our own generated parser will reject any > > unknown new attribute the same way as an unknown element (that's for any > > maven 3.x version). Here's what happen if I use a maven 3.2.5 to read a > POM > > with an element that has been introduced later: > > https://gist.github.com/gnodet/35a3ad4d449e586dc282c08eacc82ed0 > > So I'm not really buying the argument about attribute / element at this > > point. If that could be clarified, it would be nice ! > > > > So I think the question comes down to: do we prefer modifying/overwriting > > the schema as we did in the past or do we prefer cleanly versioning it. > In > > both cases, I think we need to keep it compatible, i.e. only add > > elements/attributes. The first option is much easier to implement: just > do > > nothing as we did in the past, but this has the drawback of not giving > > people/tools much warning or information about possible changes. We > simply > > overwrite the schema from the web site with the latest one at each > release, > > hoping that tools will not see the change and that they don't really > cache > > the schema (in case you really need the latest). The other option is to > > more properly version the schema. This would need additional code if we > > want to correctly detect which version is the lower version needed to > > correctly write a given POM. But even for doc changes, I think it may be > > preferable to micro version the schemas. > > > > The scm.child.xxx attributes that were added are not meaningful for the > > consumer afaik: they are used for build time and for doc, when you use an > > artifact as a dependency (i.e. on the consumer side), tho
Re: [VOTE] Release Maven WAR Plugin version 3.4.0
+1 niedz., 11 cze 2023 o 22:16 Tamás Cservenák napisał(a): > +1 > > On Sun, Jun 11, 2023, 22:14 Michael Osipov wrote: > > > Hi, > > > > we solved 17 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121&version=12350597 > > > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/projects/MWAR/issues > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1955/ > > > > > https://repository.apache.org/content/repositories/maven-1955/org/apache/maven/plugins/maven-war-plugin/3.4.0/maven-war-plugin-3.4.0-source-release.zip > > > > Source release checksum(s): > > maven-war-plugin-3.4.0-source-release.zip > > sha512: > > > > > ef7b2621697024570522a778318106f1e5ca18bf6944cb9e43e693e8c37312af272036f517d03b3555622f9bad695217ececa078affda6442d76063b5153f998 > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-war-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 POM and consumer POM (was Re: [DISCUSS] POM model version
Strange question but maybe it will inspire someone else. Why does the POM the user uses to control the build the exact same format as the POMs created to express the results of the build? Is that necessary? It seems to me the discussion is about the drawbacks of that approach. Perhaps its needed for reproducible builds or something but it seems to me those two use cases are different and the difficulty comes from trying to make one stable format serve both use cases. Hunter On Sunday, June 11, 2023 at 02:12:49 PM PDT, Romain Manni-Bucau wrote: Le dim. 11 juin 2023 à 22:28, Guillaume Nodet a écrit : > Those are actually two different questions, but I'd like to raise those > together, since they do affect the same feature. > > 1/ We currently don't have an XML schema for the build POM. One > possibility would be to relax a bit the constraints on the main POM schema > ( > http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are not > mandatory in the xml. By not modifying the validation rules, those > elements will have to be present in the object model, so that should be > safe. Another option would be to have a separate schema, but given the > small set of changes on the build pom on the current constraints, i > think the first solution would be better. As a reminder, the build pom > supports: inferring version for artifacts that are part of the reactor > (that's usually done using managedVersion), inferring the relativePath > element, ci friendly interpolation for the version. > +1 to relax > > 2/ the consumer POM could be streamlined much more using the same > techniques than used in the flatten-maven-plugin. Currently, we're only > removing the element, but we could remove the full build section, > flatten dependencies, etc... Packaged artifacts (i.e. with a non pom > packaging), can only be used as dependencies, so I think the whole > flattening process could make sense. Is there any drawback in doing so ? > Any particular reason the consumer POM support is limited to removing > modules and does not go further ? I can see some discussion in > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM > but > those do not seem to be settled. > Doesnt flattening break transitive dep resolution since depth changes? Also drops some build meta which cant be resoled anymore portably like compiler setup, which graalvm version was used and lastly would need to drop or not props not used elsewhere. Think staying as close as possible of the source is overall good to consume as intended (build control) until the transformer is fully configurable (never hopefully since it sounds overcomplicated). > Le ven. 9 juin 2023 à 11:22, Guillaume Nodet a écrit : > > > > > > > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy a > > écrit : > > > >> adding a new POM element in build POM was supposed to be something for > >> Maven 5 > >> and to trigger a POM 5 version, to make clear that we are leaving the > >> Maven 3 > >> space (that uses POM version 4, hence the need for version clarification > >> between Maven and it POM model version) > >> > >> if we enter that space before having released Maven 4, we're adding more > >> complexity: do you really want to work on Maven 5 now? > >> > >> > >> another aspect: > >> do we want to have this new improvement only for Maven 4/5 or also have > >> it for > >> Maven 3.9? > >> in Maven 3.9, such little enhancement were implemented as XML attributes > >> > > > > Fwiw, if I reduce the diff between the XSD generated with 3.0 and with > > 3.9.x, I end up with the following diff > > https://gist.github.com/gnodet/f8dfd3206ebf55d6e4610a25e683120b > > So, you're right, no new elements have been introduced. A few attributes > > added, one element removed. > > > > However I really don't understand how adding an attribute vs an element > > makes the POM more compatible. Our own generated parser will reject any > > unknown new attribute the same way as an unknown element (that's for any > > maven 3.x version). Here's what happen if I use a maven 3.2.5 to read a > POM > > with an element that has been introduced later: > > https://gist.github.com/gnodet/35a3ad4d449e586dc282c08eacc82ed0 > > So I'm not really buying the argument about attribute / element at this > > point. If that could be clarified, it would be nice ! > > > > So I think the question comes down to: do we prefer modifying/overwriting > > the schema as we did in the past or do we prefer cleanly versioning it. > In > > both cases, I think we need to keep it compatible, i.e. only add > > elements/attributes. The first option is much easier to implement: just > do > > nothing as we did in the past, but this has the drawback of not giving > > people/tools much warning or information about possible changes. We > simply > > overwrite the schema from the web site with the latest one at each > release, > > hoping that tools will not see the change and that they don't really > cac
Re: [DISCUSS] POM model version
Le vendredi 9 juin 2023, 11:22:26 CEST Guillaume Nodet a écrit : > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy a écrit : > > adding a new POM element in build POM was supposed to be something for > > Maven 5 > > and to trigger a POM 5 version, to make clear that we are leaving the > > Maven 3 > > space (that uses POM version 4, hence the need for version clarification > > between Maven and it POM model version) > > > > if we enter that space before having released Maven 4, we're adding more > > complexity: do you really want to work on Maven 5 now? > > > > > > another aspect: > > do we want to have this new improvement only for Maven 4/5 or also have it > > for > > Maven 3.9? > > in Maven 3.9, such little enhancement were implemented as XML attributes > > Fwiw, if I reduce the diff between the XSD generated with 3.0 and with > 3.9.x, I end up with the following diff > https://gist.github.com/gnodet/f8dfd3206ebf55d6e4610a25e683120b > So, you're right, no new elements have been introduced. A few attributes > added, one element removed. yes, it's a real strategy that has been defined a very long time ago, as a strong promise from Maven project to Maven Central consumers > However I really don't understand how adding an attribute vs an element > makes the POM more compatible. Our own generated parser will reject any > unknown new attribute the same way as an unknown element (that's for any > maven 3.x version). Here's what happen if I use a maven 3.2.5 to read a POM > with an element that has been introduced later: > https://gist.github.com/gnodet/35a3ad4d449e586dc282c08eacc82ed0 > So I'm not really buying the argument about attribute / element at this > point. If that could be clarified, it would be nice ! the idea is that Maven 1, 2 and 3 before 3.6.0 (MNG-6059) defined elements only, not attributes, then people parsing POMs look at elements, not attributes: adding attributes won't break external parsers. Don't look at Maven code to judge: the whole logic is based on "known unknown" = we don't know who parses POMs published to Maven Central, but there are many (it's easy to cite many, but not all). > So I think the question comes down to: do we prefer modifying/overwriting > the schema as we did in the past or do we prefer cleanly versioning it. In > both cases, I think we need to keep it compatible, i.e. only add > elements/attributes. The first option is much easier to implement: just do > nothing as we did in the past, but this has the drawback of not giving > people/tools much warning or information about possible changes. We simply > overwrite the schema from the web site with the latest one at each release, > hoping that tools will not see the change and that they don't really cache > the schema (in case you really need the latest). The other option is to > more properly version the schema. This would need additional code if we > want to correctly detect which version is the lower version needed to > correctly write a given POM. But even for doc changes, I think it may be > preferable to micro version the schemas. the strategy on adding new elements has always been yet to define precisely, and called Maven 5 If you want to work on details of Maven 5 way to add new elements, it has to be worked seriously (xmlns? xsd?), documented, tested widely, ... > The scm.child.xxx attributes that were added are not meaningful for the > consumer afaik: they are used for build time and for doc, when you use an > artifact as a dependency (i.e. on the consumer side), those attributes > won't be used. So from a consumer POV, they don't carry any semantics and > can safely be silently discarded. This is also the case for this new > priority attribute, as it only affects the current project or child > projects. In that sense this new feature could just be silently added to > the schema as previous things, so I'm fine with not versioning the schema > now if that's the consensus. I would not say consumers never use scm.child.xxx attributes, but yes, not for the core dependency aspects: if we accepted to take the risk on these attributes, it's exactly for that reason And yes, to me, that would be the same for plugin execution priority: not used by dependency consumers > > The problem (and that's really something we need to fix), is that we don't > any real difference between the build POM and the consumer POM schemas. We > also don't make a real difference between consuming as a bom / dependency / > plugin, and consuming as a parent. Both cases are really different, as the > first one could strip out most of the section. One possibility > would be to more formerly identify those 3 use cases (build on file system, > consuming as a dependency and consuming as a child). Note that we're > currently lacking a build schema, so that when using the build/consumer > POM, your build schema cannot be validated, as it's missing some elements. > One possibility would be to simply make some elements non
Re: [VOTE] Release Apache ASF parent 30
wow, what a release! +1 Reproducible build ok Regards, Hervé Le dimanche 11 juin 2023, 19:02:05 CEST Slawomir Jaranowski a écrit : > Hi, > > We solved 25 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250&ve > rsion=12352680 > > Commits: > https://github.com/apache/maven-apache-parent/compare/apache-29...apache-30 > > Staging repo: > https://repository.apache.org/content/repositories/orgapacheapache-1035/ > https://repository.apache.org/content/repositories/orgapacheapache-1035/org/ > apache/apache/30/apache-30-source-release.zip > > Source release checksum(s): > apache-30-source-release.zip - SHA-512 : > 3c2557de0d8b1a1bfb36d67e7e17cdf338f9812ccb9fd030eedb3ff4693fbac38980bfe022dc > 033fe454b28f2e49ddedb768c52a62c83b82e1ad0041b5ff9ac7 > > Staging site: > https://maven.apache.org/pom-archives/asf-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 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 POM and consumer POM (was Re: [DISCUSS] POM model version
Le dimanche 11 juin 2023, 23:31:36 CEST Hunter C Payne a écrit : > Strange question but maybe it will inspire someone else. Why does the POM > the user uses to control the build the exact same format as the POMs > created to express the results of the build? Is that necessary? it has been done in early Maven 2 and Maven Central creation, near 20 years ago: why do more complex? And how, when at that time all the concepts had to be invented and implemented to simply work first. > It seems > to me the discussion is about the drawbacks of that approach. Perhaps its > needed for reproducible builds or something but it seems to me those two > use cases are different and the difficulty comes from trying to make one > stable format serve both use cases. Hunter that's why the concepts of build/consumer POM were introduced [1] 5 or 6 years ago and the plan about Maven 4 and 5 [2] with summaries of the history [3] done while working on it Regards, Hervé [1] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM [2] https://cwiki.apache.org/confluence/display/MAVEN/Maven+Core+Roadmap [3] https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html > > On Sunday, June 11, 2023 at 02:12:49 PM PDT, Romain Manni-Bucau > wrote: > Le dim. 11 juin 2023 à 22:28, Guillaume Nodet a écrit : > > Those are actually two different questions, but I'd like to raise those > > together, since they do affect the same feature. > > > > 1/ We currently don't have an XML schema for the build POM. One > > possibility would be to relax a bit the constraints on the main POM schema > > ( > > http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are not > > mandatory in the xml. By not modifying the validation rules, those > > elements will have to be present in the object model, so that should be > > safe. Another option would be to have a separate schema, but given the > > small set of changes on the build pom on the current constraints, i > > think the first solution would be better. As a reminder, the build pom > > supports: inferring version for artifacts that are part of the reactor > > (that's usually done using managedVersion), inferring the relativePath > > element, ci friendly interpolation for the version. > > +1 to relax > > > 2/ the consumer POM could be streamlined much more using the same > > techniques than used in the flatten-maven-plugin. Currently, we're only > > removing the element, but we could remove the full build > > section, > > flatten dependencies, etc... Packaged artifacts (i.e. with a non pom > > packaging), can only be used as dependencies, so I think the whole > > flattening process could make sense. Is there any drawback in doing so ? > > Any particular reason the consumer POM support is limited to removing > > modules and does not go further ? I can see some discussion in > > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM > > but > > those do not seem to be settled. > > Doesnt flattening break transitive dep resolution since depth changes? > > Also drops some build meta which cant be resoled anymore portably like > compiler setup, which graalvm version was used and lastly would need to > drop or not props not used elsewhere. > Think staying as close as possible of the source is overall good to consume > as intended (build control) until the transformer is fully configurable > (never hopefully since it sounds overcomplicated). > > > Le ven. 9 juin 2023 à 11:22, Guillaume Nodet a écrit : > > > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy a > > > > > > écrit : > > >> adding a new POM element in build POM was supposed to be something for > > >> Maven 5 > > >> and to trigger a POM 5 version, to make clear that we are leaving the > > >> Maven 3 > > >> space (that uses POM version 4, hence the need for version > > >> clarification > > >> between Maven and it POM model version) > > >> > > >> if we enter that space before having released Maven 4, we're adding > > >> more > > >> complexity: do you really want to work on Maven 5 now? > > >> > > >> > > >> another aspect: > > >> do we want to have this new improvement only for Maven 4/5 or also have > > >> it for > > >> Maven 3.9? > > >> in Maven 3.9, such little enhancement were implemented as XML > > >> attributes > > > > > > Fwiw, if I reduce the diff between the XSD generated with 3.0 and with > > > 3.9.x, I end up with the following diff > > > https://gist.github.com/gnodet/f8dfd3206ebf55d6e4610a25e683120b > > > So, you're right, no new elements have been introduced. A few attributes > > > added, one element removed. > > > > > > However I really don't understand how adding an attribute vs an element > > > makes the POM more compatible. Our own generated parser will reject any > > > unknown new attribute the same way as an unknown element (that's for any > > > maven 3.x version). Here's what happen if I use a maven 3.2.5 to read a > > > > POM > > > > > with an element t
Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version
Le dim. 11 juin 2023 à 23:12, Romain Manni-Bucau a écrit : > > > Le dim. 11 juin 2023 à 22:28, Guillaume Nodet a > écrit : > >> Those are actually two different questions, but I'd like to raise those >> together, since they do affect the same feature. >> >> 1/ We currently don't have an XML schema for the build POM. One >> possibility would be to relax a bit the constraints on the main POM >> schema ( >> http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are >> not >> mandatory in the xml. By not modifying the validation rules, those >> elements will have to be present in the object model, so that should be >> safe. Another option would be to have a separate schema, but given the >> small set of changes on the build pom on the current constraints, i >> think the first solution would be better. As a reminder, the build pom >> supports: inferring version for artifacts that are part of the reactor >> (that's usually done using managedVersion), inferring the relativePath >> element, ci friendly interpolation for the version. >> > > +1 to relax > >> >> 2/ the consumer POM could be streamlined much more using the same >> techniques than used in the flatten-maven-plugin. Currently, we're only >> removing the element, but we could remove the full build >> section, >> flatten dependencies, etc... Packaged artifacts (i.e. with a non pom >> packaging), can only be used as dependencies, so I think the whole >> flattening process could make sense. Is there any drawback in doing so ? >> Any particular reason the consumer POM support is limited to removing >> modules and does not go further ? I can see some discussion in >> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM >> but >> those do not seem to be settled. >> > > Doesnt flattening break transitive dep resolution since depth changes? > > Also drops some build meta which cant be resoled anymore portably like > compiler setup, which graalvm version was used and lastly would need to > drop or not props not used elsewhere. > Think staying as close as possible of the source is overall good to > consume as intended (build control) until the transformer is fully > configurable (never hopefully since it sounds overcomplicated). > All those properties, plugin config, etc... are completely irrelevant for jars or any other packaged artifact. The only way those can actually have an impact is when you use the pom as a parent. That's because when you inherit from a project, it has to have the "pom" packaging. Dependency management is used when importing BOMs, but all other usages are afaik limited to declaring dependencies or plugins, and in those cases, the only interesting bits are dependencies, dependencyManagement, parents and properties (+ repositories). The flatten-m-p does merge those 4 pieces into a single list of dependencies (which has the benefit of simplifying the consumption of the artifact). We may not want to do that, but still the build section is completely irrelevant. To recap, we have 3 different usages of the POM: * the build pom on the file system read by maven when running * the consumer pom on a repository which is used when consuming a dependency/plugin jar or any other kind of packaging * the build pom with a pom packaging which can be uploaded to central and used as a parent by another project I do somewhat understand the will to keep the pom schema for artifacts uploaded in central. When consuming those jars (as dependencies or plugins), there's definitely very little need to actually make any change to the POM schema that they are using (even though I'm not really buying the fact that it has to be set in "amber"). Maven already supports any new element/attribute and other tools could adapt as well. However, there are clear needs to improve the build side POM. The build/pom consumer has done some improvement here, but it's not finished, and the pain point has not been addressed in any doc/wiki page I've read so far: if we ever introduce a new element in the build POM, but we want to consume that POM as a parent: this is the third usage above, and it's conflicting with two set of goals: * introduce new stuff in the build pom * keep 4.0.0 model in "amber" I think the only way is to create a new schema called POM5 if you want and to use it for build POM *and* for pom packaged POM uploaded to central, while packaged artifacts would be stuck with POM4. The POM5 could then be free to evolve as desired. So to sum-up, I can see two solutions: * allow the 4.0.0 model to evolve with 4.2.0 or any other. If we don't touch the "consuming" side of things, old maven will still work and be able to consumer jars uploaded (and we could still upload a 4.0.0 pom for jars if we remove the build section and everything that's irrelevant to consume those jars) * introduce a new schema for the build pom (be it http://maven.apache.org/POM/5.0.0 or http://maven.apache.org/BUILD/4.0.0, or whatever...) a
Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version
Isn't the schema named in the POM document itself? Can't we just allow use of "extended" (read backwards compatible) schemas as the POM is versioned? Then if/once a specific schema for a use case becomes popular it can be added to parsers as the required version if needed. Or perhaps that's too complex...IDK. Hunter On Sunday, June 11, 2023 at 04:36:52 PM PDT, Guillaume Nodet wrote: Le dim. 11 juin 2023 à 23:12, Romain Manni-Bucau a écrit : > > > Le dim. 11 juin 2023 à 22:28, Guillaume Nodet a > écrit : > >> Those are actually two different questions, but I'd like to raise those >> together, since they do affect the same feature. >> >> 1/ We currently don't have an XML schema for the build POM. One >> possibility would be to relax a bit the constraints on the main POM >> schema ( >> http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are >> not >> mandatory in the xml. By not modifying the validation rules, those >> elements will have to be present in the object model, so that should be >> safe. Another option would be to have a separate schema, but given the >> small set of changes on the build pom on the current constraints, i >> think the first solution would be better. As a reminder, the build pom >> supports: inferring version for artifacts that are part of the reactor >> (that's usually done using managedVersion), inferring the relativePath >> element, ci friendly interpolation for the version. >> > > +1 to relax > >> >> 2/ the consumer POM could be streamlined much more using the same >> techniques than used in the flatten-maven-plugin. Currently, we're only >> removing the element, but we could remove the full build >> section, >> flatten dependencies, etc... Packaged artifacts (i.e. with a non pom >> packaging), can only be used as dependencies, so I think the whole >> flattening process could make sense. Is there any drawback in doing so ? >> Any particular reason the consumer POM support is limited to removing >> modules and does not go further ? I can see some discussion in >> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM >> but >> those do not seem to be settled. >> > > Doesnt flattening break transitive dep resolution since depth changes? > > Also drops some build meta which cant be resoled anymore portably like > compiler setup, which graalvm version was used and lastly would need to > drop or not props not used elsewhere. > Think staying as close as possible of the source is overall good to > consume as intended (build control) until the transformer is fully > configurable (never hopefully since it sounds overcomplicated). > All those properties, plugin config, etc... are completely irrelevant for jars or any other packaged artifact. The only way those can actually have an impact is when you use the pom as a parent. That's because when you inherit from a project, it has to have the "pom" packaging. Dependency management is used when importing BOMs, but all other usages are afaik limited to declaring dependencies or plugins, and in those cases, the only interesting bits are dependencies, dependencyManagement, parents and properties (+ repositories). The flatten-m-p does merge those 4 pieces into a single list of dependencies (which has the benefit of simplifying the consumption of the artifact). We may not want to do that, but still the build section is completely irrelevant. To recap, we have 3 different usages of the POM: * the build pom on the file system read by maven when running * the consumer pom on a repository which is used when consuming a dependency/plugin jar or any other kind of packaging * the build pom with a pom packaging which can be uploaded to central and used as a parent by another project I do somewhat understand the will to keep the pom schema for artifacts uploaded in central. When consuming those jars (as dependencies or plugins), there's definitely very little need to actually make any change to the POM schema that they are using (even though I'm not really buying the fact that it has to be set in "amber"). Maven already supports any new element/attribute and other tools could adapt as well. However, there are clear needs to improve the build side POM. The build/pom consumer has done some improvement here, but it's not finished, and the pain point has not been addressed in any doc/wiki page I've read so far: if we ever introduce a new element in the build POM, but we want to consume that POM as a parent: this is the third usage above, and it's conflicting with two set of goals: * introduce new stuff in the build pom * keep 4.0.0 model in "amber" I think the only way is to create a new schema called POM5 if you want and to use it for build POM *and* for pom packaged POM uploaded to central, while packaged artifacts would be stuck with POM4. The POM5 could then be free to evolve as desired. So to sum-up, I can see two solutions: * allow the 4.0.0 model to evolve with 4.2.0 or
Re: [DISCUSS] POM model version
Le dim. 11 juin 2023 à 23:54, Hervé Boutemy a écrit : > Le vendredi 9 juin 2023, 11:22:26 CEST Guillaume Nodet a écrit : > > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy a > écrit : > > > adding a new POM element in build POM was supposed to be something for > > > Maven 5 > > > and to trigger a POM 5 version, to make clear that we are leaving the > > > Maven 3 > > > space (that uses POM version 4, hence the need for version > clarification > > > between Maven and it POM model version) > > > > > > if we enter that space before having released Maven 4, we're adding > more > > > complexity: do you really want to work on Maven 5 now? > > > > > > > > > another aspect: > > > do we want to have this new improvement only for Maven 4/5 or also > have it > > > for > > > Maven 3.9? > > > in Maven 3.9, such little enhancement were implemented as XML > attributes > > > > Fwiw, if I reduce the diff between the XSD generated with 3.0 and with > > 3.9.x, I end up with the following diff > > https://gist.github.com/gnodet/f8dfd3206ebf55d6e4610a25e683120b > > So, you're right, no new elements have been introduced. A few attributes > > added, one element removed. > yes, it's a real strategy that has been defined a very long time ago, as a > strong promise from Maven project to Maven Central consumers > > > However I really don't understand how adding an attribute vs an element > > makes the POM more compatible. Our own generated parser will reject any > > unknown new attribute the same way as an unknown element (that's for any > > maven 3.x version). Here's what happen if I use a maven 3.2.5 to read a > POM > > with an element that has been introduced later: > > https://gist.github.com/gnodet/35a3ad4d449e586dc282c08eacc82ed0 > > So I'm not really buying the argument about attribute / element at this > > point. If that could be clarified, it would be nice ! > the idea is that Maven 1, 2 and 3 before 3.6.0 (MNG-6059) defined elements > only, not attributes, then people parsing POMs look at elements, not > attributes: adding attributes won't break external parsers. > Don't look at Maven code to judge: the whole logic is based on "known > unknown" > = we don't know who parses POMs published to Maven Central, but there are > many > (it's easy to cite many, but not all). > I can't buy that argument. You're saying that we should not assume the way the POM is parsed, but we assume they don't parse arguments. That's clearly dodgy, and false for our own parser (both are parsed and rejected in strict mode and silently ignored in lenient mode). > > > So I think the question comes down to: do we prefer modifying/overwriting > > the schema as we did in the past or do we prefer cleanly versioning it. > In > > both cases, I think we need to keep it compatible, i.e. only add > > elements/attributes. The first option is much easier to implement: just > do > > nothing as we did in the past, but this has the drawback of not giving > > people/tools much warning or information about possible changes. We > simply > > overwrite the schema from the web site with the latest one at each > release, > > hoping that tools will not see the change and that they don't really > cache > > the schema (in case you really need the latest). The other option is to > > more properly version the schema. This would need additional code if we > > want to correctly detect which version is the lower version needed to > > correctly write a given POM. But even for doc changes, I think it may be > > preferable to micro version the schemas. > the strategy on adding new elements has always been yet to define > precisely, > and called Maven 5 > If you want to work on details of Maven 5 way to add new elements, it has > to > be worked seriously (xmlns? xsd?), documented, tested widely, ... > I'd prefer iterations that we can ship in a timely manner... My understanding is that "maven 5" was to align on a new major version of the model which is currently "4.0.0". I don't care about naming at this point. If the point is really the above, we could skip maven 4 as it has been written or use a new schema (see below). > > > The scm.child.xxx attributes that were added are not meaningful for the > > consumer afaik: they are used for build time and for doc, when you use an > > artifact as a dependency (i.e. on the consumer side), those attributes > > won't be used. So from a consumer POV, they don't carry any semantics > and > > can safely be silently discarded. This is also the case for this new > > priority attribute, as it only affects the current project or child > > projects. In that sense this new feature could just be silently added to > > the schema as previous things, so I'm fine with not versioning the schema > > now if that's the consensus. > I would not say consumers never use scm.child.xxx attributes, but yes, not > for > the core dependency aspects: if we accepted to take the risk on these > attributes, it's exactly for that reason > And yes, to me,
Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version
Le lun. 12 juin 2023 à 01:36, Guillaume Nodet a écrit : > Le dim. 11 juin 2023 à 23:12, Romain Manni-Bucau a > écrit : > > > > > > > Le dim. 11 juin 2023 à 22:28, Guillaume Nodet a > > écrit : > > > >> Those are actually two different questions, but I'd like to raise those > >> together, since they do affect the same feature. > >> > >> 1/ We currently don't have an XML schema for the build POM. One > >> possibility would be to relax a bit the constraints on the main POM > >> schema ( > >> http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are > >> not > >> mandatory in the xml. By not modifying the validation rules, those > >> elements will have to be present in the object model, so that should be > >> safe. Another option would be to have a separate schema, but given the > >> small set of changes on the build pom on the current constraints, i > >> think the first solution would be better. As a reminder, the build pom > >> supports: inferring version for artifacts that are part of the reactor > >> (that's usually done using managedVersion), inferring the relativePath > >> element, ci friendly interpolation for the version. > >> > > > > +1 to relax > > > >> > >> 2/ the consumer POM could be streamlined much more using the same > >> techniques than used in the flatten-maven-plugin. Currently, we're only > >> removing the element, but we could remove the full build > >> section, > >> flatten dependencies, etc... Packaged artifacts (i.e. with a non pom > >> packaging), can only be used as dependencies, so I think the whole > >> flattening process could make sense. Is there any drawback in doing so > ? > >> Any particular reason the consumer POM support is limited to removing > >> modules and does not go further ? I can see some discussion in > >> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM > >> but > >> those do not seem to be settled. > >> > > > > Doesnt flattening break transitive dep resolution since depth changes? > > > > Also drops some build meta which cant be resoled anymore portably like > > compiler setup, which graalvm version was used and lastly would need to > > drop or not props not used elsewhere. > > Think staying as close as possible of the source is overall good to > > consume as intended (build control) until the transformer is fully > > configurable (never hopefully since it sounds overcomplicated). > > > > All those properties, plugin config, etc... are completely irrelevant for > jars or any other packaged artifact. The only way those can actually have > an impact is when you use the pom as a parent. That's because when you > inherit from a project, it has to have the "pom" packaging. Dependency > management is used when importing BOMs, but all other usages are afaik > limited to declaring dependencies or plugins, and in those cases, the only > interesting bits are dependencies, dependencyManagement, parents and > properties (+ repositories). The flatten-m-p does merge those 4 pieces > into a single list of dependencies (which has the benefit of simplifying > the consumption of the artifact). We may not want to do that, but still > the build section is completely irrelevant. > Do you assume people only use pom as a dependencies source? it is used for way more than that IMHO. While I agree how plugins are executed is not important, how they are configured is used and adds value to consumers. A simple example (but trust me I saw some more complex in companie$) is to check compiler configs to ensure the assumed based runtime will work, indeed it is part of a static analyzis (and rarely the build) but the used source is the deployed pom and I strongly think it is an important metadata. Indeed you can say all that must be replaced by some metadata files but, as of today, the pom gives that quite easily and pseudo portably (you just compensate artifacts not using maven with explicit meta but it is a few compared to dropping it globally). > > To recap, we have 3 different usages of the POM: > * the build pom on the file system read by maven when running > * the consumer pom on a repository which is used when consuming a > dependency/plugin jar or any other kind of packaging > * the build pom with a pom packaging which can be uploaded to central and > used as a parent by another project > Agree > > I do somewhat understand the will to keep the pom schema for artifacts > uploaded in central. When consuming those jars (as dependencies or > plugins), there's definitely very little need to actually make any change > to the POM schema that they are using (even though I'm not really buying > the fact that it has to be set in "amber"). Maven already supports any new > element/attribute and other tools could adapt as well. > However, there are clear needs to improve the build side POM. The > build/pom consumer has done some improvement here, but it's not finished, > and the pain point has not been addressed in any doc/wiki page
