Re: [VOTE] Release Apache Wagon version 3.3.4
SHA512 ok, successful local build but an Error in ASF build #38 and #39 with the last two commits from maven-release-plugin but not from the #37. Pls have a look into this: https://builds.apache.org/job/maven-box/job/maven-wagon/job/master/39/testReport/junit/org.apache.maven.wagon.providers.http/HttpWagonErrorTest/linux_jdk13___Build_linux_jdk13___testGet500/ On Sun, Nov 3, 2019 at 9:04 PM Hervé BOUTEMY wrote: > Hi, > > We solved 5 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122=12345956=Text > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1535/ > > https://repository.apache.org/content/repositories/maven-1535/org/apache/maven/wagon/wagon/3.3.4/wagon-3.3.4-source-release.zip > > Source release checksum(s): > wagon-3.3.4-source-release.zip sha512: > 1484d17bede842ed45ae3642ccb12f585489a95604fd100a4fddea05e39b0d0471a3d878c8252cc2a29fcdc4f3d2ec0dd25629842ea4443d7557e488b0f3c25f > > Staging site: > https://maven.apache.org/wagon-archives/wagon-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: Regression in model interpolation coming from using JSR-330?
I did a quick review of the various components in core
and StringVisitorModelInterpolator / StringSearchModelInterpolator appears
to be the only case where a role (ModelInterpolator) has two non-default
implementations and another component only asks for the first
implementation. There are other roles which have multiple implementations,
but in those cases that's expected because each implementation has a
specific name and handles a specific case (see the various ProfileActivator
implementations which are all then injected into a list in
DefaultProfileSelector.)
It also appears that StringVisitorModelInterpolator was only added recently
- if it's meant to be a replacement of StringSearchModelInterpolator then
one option would be to simply remove StringSearchModelInterpolator.
Alternatively if StringSearchModelInterpolator is needed to be kept around
for compatibility reasons (such as someone directly extending it outside of
Maven) then the Named annotation could be removed
from StringSearchModelInterpolator so it isn't automatically picked up.
Wrt. extra checks, checking for multiple implementations in the same
realm/classloader that haven't been given specific names is a possibility -
you can open feature requests at
https://bugs.eclipse.org/bugs/describecomponents.cgi?product=Sisu
On Sun, 3 Nov 2019 at 19:05, Gabriel Belingueres
wrote:
> Hi Hervé:
>
> I was thinking in the lines of some checking at the maven core level only,
> enough to detect problems and ensure there are no regressions.
>
> At the plugin level, I guess the assurance that the right component is
> injected can be checked with an integration test.
>
> The way I realized the problem was that I was adding some logging traces
> into the StringVisitorModelInterpolator class but *nothing* showed (even
> the build was successful and the interpolation indeed was happening
> somewhere). Then added the same logging lines to
> StringSearchModelInterpolator, and the logging appeared in the build, which
> confirmed the issue. (I didn't test if there are any other component with
> the same problem.)
>
> El dom., 3 de nov. de 2019 a la(s) 06:27, Hervé BOUTEMY (
> herve.bout...@free.fr) escribió:
>
> > nice idea, but overriding by adding a new implementation in classpath is
> > the
> > normal overriding way: not sure how "ambiguity checker" could make a
> > difference
> > between such wanted override vs unwanted ambiguity
> >
> > BTW, how did you see that StringVisitorModelInterpolator was not used but
> > StringSearchModelInterpolator instead, please?
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 3 novembre 2019, 05:30:50 CET Gabriel Belingueres a écrit :
> > > Thanks Stuart.
> > >
> > > The reproducibility PR you mention helps in having a deterministic
> > ordering
> > > inside the Named components file to buld exactly the same executable,
> but
> > > it does not mean it is the right priority for component injection.
> > >
> > > Do you know if it is possible to configure sisu to throw an exception
> if
> > > trying to inject an ambiguous component? Otherwise, I guess we must
> > > implement some sort of "ambiguity checker", either as an integration
> test
> > > (don't know if it is possible) or either built-it into maven
> executable.
> > >
> > >
> > >
> > >
> > > El sáb., 2 de nov. de 2019 a la(s) 20:54, Stuart McCulloch (
> > >
> > > mccu...@gmail.com) escribió:
> > > > Yes, when there are multiple non-default implementations with the
> same
> > > > priority then it will pick the first in the list (where the "list" in
> > > > question is actually a combination of plugins + extensions + core
> > > > bindings for the given type)
> > > >
> > > > If a particular implementation should be treated as the default then
> it
> > > > should either start with "Default" or be annotated with
> > @Named("default")
> > > > -
> > > > the benefit of this approach is that it documents that this is the
> > default
> > > > implementation, to be favoured over the others. Alternatively if you
> > want
> > > > to have an ordering between implementations then you can use
> @Priority
> > to
> > > > assign specific priorities and favour one over the other.
> > > >
> > > > If you don't mark an implementation as default and don't define any
> > > > priorities then the only current guarantees are that implementations
> in
> > > > plugins and extensions will be favoured over implementations in core
> > (to
> > > > allow overriding). But there is an upcoming improvement to sort the
> > list
> > > > inside each module that would make this more deterministic from build
> > to
> > > > build, at least when ranking implementations inside a particular
> > module:
> > > > https://github.com/eclipse/sisu.inject/pull/5 - with that change
> then
> > > > you'll get an extra guarantee that inside a module it will be ordered
> > by
> > > > package+name.
> > > >
> > > > PS. even with the old Plexus runtime annotations you could be at the
> > whim
> > > > of classpath ordering,
[VOTE] Release Apache Wagon version 3.3.4
Hi, We solved 5 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122=12345956=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1535/ https://repository.apache.org/content/repositories/maven-1535/org/apache/maven/wagon/wagon/3.3.4/wagon-3.3.4-source-release.zip Source release checksum(s): wagon-3.3.4-source-release.zip sha512: 1484d17bede842ed45ae3642ccb12f585489a95604fd100a4fddea05e39b0d0471a3d878c8252cc2a29fcdc4f3d2ec0dd25629842ea4443d7557e488b0f3c25f Staging site: https://maven.apache.org/wagon-archives/wagon-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: last review of Reproducible Builds proposal
Well I have a new candidate: maven-bundle-plugin Creates: Bnd-LastModified in the MANIFEST.MF Gotta find out a way to either suppress that entry (Would be great if it could consume the same property) Chris Am 03.11.19, 20:25 schrieb "herve.bout...@free.fr" : ok, Reproducible Builds are not so easy to get: each plugin that you use can cause an issue I really recommend you diffoscope to investigate differences, it really helps a lot by easily giving you precise differences Good luck for the investigations :) Regards, Hervé - Mail original - De: "Christofer Dutz" À: "Maven Developers List" Envoyé: Dimanche 3 Novembre 2019 20:16:42 Objet: Re: last review of Reproducible Builds proposal Hi Herve, unfortunately I now have implemented some tooling to compare the stuff produced by the updated reproducible builds. And it does show quite a number of non binary equal files. Will investigate what's the difference. Chris Am 03.11.19, 11:08 schrieb "Hervé BOUTEMY" : great feedback, thank you: this proves the initial set of only 3 plugins is a good basis. For checking the many output artifacts from a build, future buildinfo file [1] should help a lot. I still have many usability concerns for Maven multi-module builds (starting with: should we generate only the root buildinfo or one buildinfo per Maven module?) Let's keep the ball rolling: today, it's plugins release day!!! Regards, Hervé [1] https://reproducible-builds.org/docs/jvm/ Le vendredi 1 novembre 2019, 13:34:32 CET Christofer Dutz a écrit : > Hi, > > so I just updated the versions of the 3 plugins and gave the Apache PLC4X > build a little spin ... > https://github.com/apache/plc4x/tree/feature/reproducible-builds > > Did two executions of this: > mvn -U -P > with-boost,with-java,with-dotnet,with-cpp,with-python,with-proxies,with-san > dbox,with > -DaltDeploymentRepository=snapshot-repo::default::file:./local-snapshots-di > r clean deploy (but with a different second local repo location) > > Then I used "diff" and "cmp" to compare individual files and it didn't show > differences with the artifacts I chose ... now I guess I'll have to whip > up some little bash script to sort of compare the artifacts from one > directory with the other (Unfortunately the SNAPSHOT timestamps are a > little annoying :-/ > We do have some C++, C# and Python modules ... but I wouldn't expect the C++ > and C# to be reproducible. > Chris > > > Am 01.11.19, 12:04 schrieb "Hervé BOUTEMY" : > > Le vendredi 1 novembre 2019, 09:40:40 CET Christofer Dutz a écrit : > > > Hi Herve, > > > > thanks for that will try it asap and report any findings back. > > > > But good to know that there is a difference between JDK major versions > > and > > OSes ... so it would probably be best to stage releases on Linux with > > an > > OpenJDK of the minimum supported version? > > Just thinking how to make it > > possible to verify without having to buy Mac or Windows licenses ... > > guess > > on every machine you could whip up a Ubuntu VM for verification. Just > > thinking about it ... perhaps it would be best to create a Docker > > image for doing the reproducible stuff ... > > just to be clear: the difference is on newline only, then Windows vs > anything else. You get the same result on Linux, MacOS, FreeBSD, or any > other Unix. > And if I want to be complete, if you get a source tarball from Windows, > extract it to a Linux/MacOS/... box and build with "mvn - > Dline.separator='\r\n'", in general, you get the same result as a build > under Windows: I tested multiple times, it worked, but we'll see if it > works always or just "in general" > > > > Are there any plans on creating a plugin to allow verification? > > > > Sort of something like this: > > "mvn package release:verify-reproduicble > > -DstagingRepoUrl=a.b.c.de/repo/blahblahblah" > > (Which doesn't deploy the > > artifacts, but instead download them and do a binary comparison) > > yes, but for now it was completely another form: this is the "Buildinfo >
Re: last review of Reproducible Builds proposal
ok, Reproducible Builds are not so easy to get: each plugin that you use can cause an issue I really recommend you diffoscope to investigate differences, it really helps a lot by easily giving you precise differences Good luck for the investigations :) Regards, Hervé - Mail original - De: "Christofer Dutz" À: "Maven Developers List" Envoyé: Dimanche 3 Novembre 2019 20:16:42 Objet: Re: last review of Reproducible Builds proposal Hi Herve, unfortunately I now have implemented some tooling to compare the stuff produced by the updated reproducible builds. And it does show quite a number of non binary equal files. Will investigate what's the difference. Chris Am 03.11.19, 11:08 schrieb "Hervé BOUTEMY" : great feedback, thank you: this proves the initial set of only 3 plugins is a good basis. For checking the many output artifacts from a build, future buildinfo file [1] should help a lot. I still have many usability concerns for Maven multi-module builds (starting with: should we generate only the root buildinfo or one buildinfo per Maven module?) Let's keep the ball rolling: today, it's plugins release day!!! Regards, Hervé [1] https://reproducible-builds.org/docs/jvm/ Le vendredi 1 novembre 2019, 13:34:32 CET Christofer Dutz a écrit : > Hi, > > so I just updated the versions of the 3 plugins and gave the Apache PLC4X > build a little spin ... > https://github.com/apache/plc4x/tree/feature/reproducible-builds > > Did two executions of this: > mvn -U -P > with-boost,with-java,with-dotnet,with-cpp,with-python,with-proxies,with-san > dbox,with > -DaltDeploymentRepository=snapshot-repo::default::file:./local-snapshots-di > r clean deploy (but with a different second local repo location) > > Then I used "diff" and "cmp" to compare individual files and it didn't show > differences with the artifacts I chose ... now I guess I'll have to whip > up some little bash script to sort of compare the artifacts from one > directory with the other (Unfortunately the SNAPSHOT timestamps are a > little annoying :-/ > We do have some C++, C# and Python modules ... but I wouldn't expect the C++ > and C# to be reproducible. > Chris > > > Am 01.11.19, 12:04 schrieb "Hervé BOUTEMY" : > > Le vendredi 1 novembre 2019, 09:40:40 CET Christofer Dutz a écrit : > > > Hi Herve, > > > > thanks for that will try it asap and report any findings back. > > > > But good to know that there is a difference between JDK major versions > > and > > OSes ... so it would probably be best to stage releases on Linux with > > an > > OpenJDK of the minimum supported version? > > Just thinking how to make it > > possible to verify without having to buy Mac or Windows licenses ... > > guess > > on every machine you could whip up a Ubuntu VM for verification. Just > > thinking about it ... perhaps it would be best to create a Docker > > image for doing the reproducible stuff ... > > just to be clear: the difference is on newline only, then Windows vs > anything else. You get the same result on Linux, MacOS, FreeBSD, or any > other Unix. > And if I want to be complete, if you get a source tarball from Windows, > extract it to a Linux/MacOS/... box and build with "mvn - > Dline.separator='\r\n'", in general, you get the same result as a build > under Windows: I tested multiple times, it worked, but we'll see if it > works always or just "in general" > > > > Are there any plans on creating a plugin to allow verification? > > > > Sort of something like this: > > "mvn package release:verify-reproduicble > > -DstagingRepoUrl=a.b.c.de/repo/blahblahblah" > > (Which doesn't deploy the > > artifacts, but instead download them and do a binary comparison) > > yes, but for now it was completely another form: this is the "Buildinfo > file" proposal https://reproducible-builds.org/docs/jvm/ > that I stopped to work on 1 year ago given I had no chance to get the > same output: it's now a good time to restart working on it as next steps > > > > Also it could be great if the release-plugin could automatically set > > the > > property: > > a) if it finds the "project.build.outputTimestamp" set to some > > placeholder value b) if some switch tells it to prepare a > > reproducible > > build by using some sort of "switch" parameter > > Guess that would sort of close the loop to get the biggest benefit out > > of > > the reproducible builds.
Re: last review of Reproducible Builds proposal
Hi Herve, unfortunately I now have implemented some tooling to compare the stuff produced by the updated reproducible builds. And it does show quite a number of non binary equal files. Will investigate what's the difference. Chris Am 03.11.19, 11:08 schrieb "Hervé BOUTEMY" : great feedback, thank you: this proves the initial set of only 3 plugins is a good basis. For checking the many output artifacts from a build, future buildinfo file [1] should help a lot. I still have many usability concerns for Maven multi-module builds (starting with: should we generate only the root buildinfo or one buildinfo per Maven module?) Let's keep the ball rolling: today, it's plugins release day!!! Regards, Hervé [1] https://reproducible-builds.org/docs/jvm/ Le vendredi 1 novembre 2019, 13:34:32 CET Christofer Dutz a écrit : > Hi, > > so I just updated the versions of the 3 plugins and gave the Apache PLC4X > build a little spin ... > https://github.com/apache/plc4x/tree/feature/reproducible-builds > > Did two executions of this: > mvn -U -P > with-boost,with-java,with-dotnet,with-cpp,with-python,with-proxies,with-san > dbox,with > -DaltDeploymentRepository=snapshot-repo::default::file:./local-snapshots-di > r clean deploy (but with a different second local repo location) > > Then I used "diff" and "cmp" to compare individual files and it didn't show > differences with the artifacts I chose ... now I guess I'll have to whip > up some little bash script to sort of compare the artifacts from one > directory with the other (Unfortunately the SNAPSHOT timestamps are a > little annoying :-/ > We do have some C++, C# and Python modules ... but I wouldn't expect the C++ > and C# to be reproducible. > Chris > > > Am 01.11.19, 12:04 schrieb "Hervé BOUTEMY" : > > Le vendredi 1 novembre 2019, 09:40:40 CET Christofer Dutz a écrit : > > > Hi Herve, > > > > thanks for that will try it asap and report any findings back. > > > > But good to know that there is a difference between JDK major versions > > and > > OSes ... so it would probably be best to stage releases on Linux with > > an > > OpenJDK of the minimum supported version? > > Just thinking how to make it > > possible to verify without having to buy Mac or Windows licenses ... > > guess > > on every machine you could whip up a Ubuntu VM for verification. Just > > thinking about it ... perhaps it would be best to create a Docker > > image for doing the reproducible stuff ... > > just to be clear: the difference is on newline only, then Windows vs > anything else. You get the same result on Linux, MacOS, FreeBSD, or any > other Unix. > And if I want to be complete, if you get a source tarball from Windows, > extract it to a Linux/MacOS/... box and build with "mvn - > Dline.separator='\r\n'", in general, you get the same result as a build > under Windows: I tested multiple times, it worked, but we'll see if it > works always or just "in general" > > > > Are there any plans on creating a plugin to allow verification? > > > > Sort of something like this: > > "mvn package release:verify-reproduicble > > -DstagingRepoUrl=a.b.c.de/repo/blahblahblah" > > (Which doesn't deploy the > > artifacts, but instead download them and do a binary comparison) > > yes, but for now it was completely another form: this is the "Buildinfo > file" proposal https://reproducible-builds.org/docs/jvm/ > that I stopped to work on 1 year ago given I had no chance to get the > same output: it's now a good time to restart working on it as next steps > > > > Also it could be great if the release-plugin could automatically set > > the > > property: > > a) if it finds the "project.build.outputTimestamp" set to some > > placeholder value b) if some switch tells it to prepare a > > reproducible > > build by using some sort of "switch" parameter > > Guess that would sort of close the loop to get the biggest benefit out > > of > > the reproducible builds. > > +1 > issue has been created > https://issues.apache.org/jira/browse/MRELEASE-1029 But I didn't work on > it yet, help welcome > > > > I would be happy to help as I think this is one > > of the greatest new features. (Ok ... perhaps besides the > > sound-output-extension I learned about yesterday ;-) ) > > +1 > the current step is important, but it's only
Re: Regression in model interpolation coming from using JSR-330?
Hi Hervé:
I was thinking in the lines of some checking at the maven core level only,
enough to detect problems and ensure there are no regressions.
At the plugin level, I guess the assurance that the right component is
injected can be checked with an integration test.
The way I realized the problem was that I was adding some logging traces
into the StringVisitorModelInterpolator class but *nothing* showed (even
the build was successful and the interpolation indeed was happening
somewhere). Then added the same logging lines to
StringSearchModelInterpolator, and the logging appeared in the build, which
confirmed the issue. (I didn't test if there are any other component with
the same problem.)
El dom., 3 de nov. de 2019 a la(s) 06:27, Hervé BOUTEMY (
herve.bout...@free.fr) escribió:
> nice idea, but overriding by adding a new implementation in classpath is
> the
> normal overriding way: not sure how "ambiguity checker" could make a
> difference
> between such wanted override vs unwanted ambiguity
>
> BTW, how did you see that StringVisitorModelInterpolator was not used but
> StringSearchModelInterpolator instead, please?
>
> Regards,
>
> Hervé
>
> Le dimanche 3 novembre 2019, 05:30:50 CET Gabriel Belingueres a écrit :
> > Thanks Stuart.
> >
> > The reproducibility PR you mention helps in having a deterministic
> ordering
> > inside the Named components file to buld exactly the same executable, but
> > it does not mean it is the right priority for component injection.
> >
> > Do you know if it is possible to configure sisu to throw an exception if
> > trying to inject an ambiguous component? Otherwise, I guess we must
> > implement some sort of "ambiguity checker", either as an integration test
> > (don't know if it is possible) or either built-it into maven executable.
> >
> >
> >
> >
> > El sáb., 2 de nov. de 2019 a la(s) 20:54, Stuart McCulloch (
> >
> > mccu...@gmail.com) escribió:
> > > Yes, when there are multiple non-default implementations with the same
> > > priority then it will pick the first in the list (where the "list" in
> > > question is actually a combination of plugins + extensions + core
> > > bindings for the given type)
> > >
> > > If a particular implementation should be treated as the default then it
> > > should either start with "Default" or be annotated with
> @Named("default")
> > > -
> > > the benefit of this approach is that it documents that this is the
> default
> > > implementation, to be favoured over the others. Alternatively if you
> want
> > > to have an ordering between implementations then you can use @Priority
> to
> > > assign specific priorities and favour one over the other.
> > >
> > > If you don't mark an implementation as default and don't define any
> > > priorities then the only current guarantees are that implementations in
> > > plugins and extensions will be favoured over implementations in core
> (to
> > > allow overriding). But there is an upcoming improvement to sort the
> list
> > > inside each module that would make this more deterministic from build
> to
> > > build, at least when ranking implementations inside a particular
> module:
> > > https://github.com/eclipse/sisu.inject/pull/5 - with that change then
> > > you'll get an extra guarantee that inside a module it will be ordered
> by
> > > package+name.
> > >
> > > PS. even with the old Plexus runtime annotations you could be at the
> whim
> > > of classpath ordering, similarly Plexus XML descriptors are influenced
> by
> > > classpath resource ordering - so ideally it's better to be explicit
> about
> > > ordering
> > >
> > > On Sat, 2 Nov 2019 at 23:07, Gabriel Belingueres <
> belingue...@gmail.com>
> > >
> > > wrote:
> > > > Hi:
> > > >
> > > > I just built maven core from source and found that it was using
> > > > StringSearchModelInterpolator instead of
> StringVisitorModelInterpolator,
> > >
> > > a
> > >
> > > > regression from the last 3.6.2 release.
> > > >
> > > > I found that in
> maven-model-builder/META-INF/sisu/javax.injected.Named
> > > > file, both interpolators are listed but in reverse order (comparing
> it
> > >
> > > with
> > >
> > > > the same file in 3.6.2), that is StringSearchModelInterpolator appear
> > >
> > > first
> > >
> > > > in the file and StringVisitorModelInterpolator second.
> > > >
> > > > (I believe the dependency injection picks up the first one it finds
> with
> > > > the right type.)
> > > >
> > > > Deleting the @Named annotation from StringSearchModelInterpolator
> solved
> > > > the issue, as this make the entry disappear from the
> > > > javax.injected.Named
> > > > file. Then the dependency injection uses the
> > > > StringVisitorModelInterpolator.
> > > >
> > > > Can anyone confirm this issue?
> > > > And if so, how to best prevent in the future that this type of
> > > > dependency
> > > > injection regressions from happening?
> > > >
> > > > Kind regards,
> > > > Gabriel
>
>
>
>
>
>
Re: New link pattern when option is set to true
Raised PR with unit test and integration test included: https://github.com/apache/maven-javadoc-plugin/pull/34 This is my first PR for any of the maven project. Although I made my best effort to follow all the coding conventions, surely there will be something missing. So feel free to point out. Max On Sun, Nov 3, 2019 at 3:20 PM Max Zhu wrote: > thanks. > > Created: https://issues.apache.org/jira/browse/MJAVADOC-628 > > Max > > On Sun, Nov 3, 2019 at 4:51 AM Enrico Olivelli > wrote: > >> Hi Max. >> sorry for late reply. >> >> I think your idea is interesting and you work is valuable, >> You can follow up by creating a JIRA in issues.apache.org in MJAVADOC >> project and then you can also send a PR. >> Please add an integration test. >> >> this is the guide for new contributors >> https://maven.apache.org/guides/development/guide-helping.html >> >> Enrico >> >> Il giorno ven 1 nov 2019 alle ore 09:26 Max Zhu >> ha scritto: >> >>> hi, >>> >>> Any update on this please? Is this mail group actively monitored? or >>> should >>> I raise a pull request directly to the project? >>> >>> Max >>> >>> On Mon, Oct 28, 2019 at 6:12 PM Max Zhu wrote: >>> >>> > For what's worth I am talking about maven-javadoc-plugin (just realized >>> > this is the main maven mail group) >>> > >>> > On Sat, Oct 26, 2019 at 6:51 PM Max Zhu wrote: >>> > >>> >> hi, >>> >> >>> >> Wondering if it makes sense to extend option to >>> javadoc.io. >>> >> >>> >> For example, google gson (https://github.com/google/gson) has pointed >>> >> their javadoc to https://www.javadoc.io/doc/com.google.code.gson/gson >>> on >>> >> their README.md. But currently, maven-javadoc-plugin will only try to >>> fetch >>> >> https://github.com/google/gson/apidoc/package-list , which >>> apparently is >>> >> an invalid address. >>> >> >>> >> I am aware there is already on option to extend tag, but >>> that's >>> >> quite tedious as everytime we have to manually keep things in sync >>> when we >>> >> add / remove dependencies or change versions. >>> >> >>> >> There are quite a few popular libraries hosting javadoc with >>> javadoc.io >>> >> already (eg, mockito / spark), and the pattern is very simple as well: >>> >> >>> https://www.javadoc.io/doc/[group_id]/[artifact_id]/[version_id]/package-list >>> >> >>> >> Thus, it will be quite helpful if maven-javadoc-plugin can just >>> >> automatically try this url pattern from the dependency list as well. >>> >> >>> >> Declaimer, I started javadoc.io about 5 years ago and now it's >>> getting >>> >> more trendy these days, so I would like to better support this >>> project. >>> >> >>> >> Max >>> >> >>> >> >>> >> Reference: >>> >> >>> https://github.com/apache/maven-javadoc-plugin/blob/b1c029f26c4dc40b29a0e122e5c42b294845acfd/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L6526 >>> >> >>> >> >>> > >>> >>
[ANN] Apache Maven JAR Plugin 3.2.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven JAR Plugin, version 3.2.0 This plugin provides the capability to build jars. https://maven.apache.org/plugins/maven-jar-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-jar-plugin 3.2.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-jar-plugin/download.cgi Release Notes - Maven JAR Plugin - Version 3.2.0 ** New Feature * [MJAR-263] - Reproducible Builds: make entries in output jar files reproducible (order + timestamp) Read https://maven.apache.org/guides/mini/guide-reproducible-builds.html for more information on Reproducible Builds with Maven. Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Maven Assembly Plugin 3.2.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Assembly Plugin, version 3.2.0 This plugin is primarily intended to allow users to aggregate the project output along with its dependencies, modules, site documentation, and other files into a single distributable archive. https://maven.apache.org/plugins/maven-assembly-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-assembly-plugin 3.2.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-assembly-plugin/download.cgi Release Notes - Maven Assembly Plugin - Version 3.2.0 ** Bug * [MASSEMBLY-871] - Descriptor ref "bin" causes error messages in the build log on Windows ** New Feature * [MASSEMBLY-921] - Reproducible Builds: make entries in output archive reproducible (order + timestamp) ** Improvement * [MASSEMBLY-914] - Add GitHub Informations ** Task * [MASSEMBLY-915] - Remove integration-test-archetype Read https://maven.apache.org/guides/mini/guide-reproducible-builds.html for more information on Reproducible Builds with Maven. Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Maven JAR Plugin 3.2.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven JAR Plugin, version 3.2.0 This plugin provides the capability to build jars. https://maven.apache.org/plugins/maven-jar-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-jar-plugin 3.2.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-jar-plugin/download.cgi Release Notes - Maven JAR Plugin - Version 3.2.0 ** New Feature * [MJAR-263] - Reproducible Builds: make entries in output jar files reproducible (order + timestamp) Read https://maven.apache.org/guides/mini/guide-reproducible-builds.html for more information on Reproducible Builds with Maven. Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Maven Source Plugin 3.2.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Source Plugin, version 3.2.0 This plugin creates a jar archive of the source files of the current project. https://maven.apache.org/plugins/maven-source-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-source-plugin 3.2.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-source-plugin/download.cgi Release Notes - Maven Source Plugin - Version 3.2.0 ** Bug * [MSOURCES-95] - Source JAR is re-created even if sources are not changed ** New Feature * [MSOURCES-120] - Reproducible Builds: make entries in output jar files reproducible (order + timestamp) Read https://maven.apache.org/guides/mini/guide-reproducible-builds.html for more information on Reproducible Builds with Maven. Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Archetypes: problem updating local catalog
Hi, I'm working on Struts Archetypes [1] and discovered that running: mvn clean install archetype:update-local-catalog will create/update "~/.m2/repository/archetype-catalog.xml" but using command: mvn archetype:generate -DarchetypeCatalog=local reads data from "~/.m2/archetype-catalog.xml" which doesn't exist. Do I have to manually copy the file? Is it by design or maybe it's a bug? [1] https://github.com/apache/struts-archetypes Regards Łukasz - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Regression in model interpolation coming from using JSR-330?
As Hervé noted, much of this is the way Maven (and Plexus) has always
behaved - the core defines component roles that plugins/extensions can
implement. There will typically be a core implementation (sometimes named
as the default, but not always) but that implementation can be
overridden by implementations in plugins/extensions so people can extend
and augment Maven. Sometimes the consumer of a component role wants to see
all implementations and will inject a list or a map (keyed by name) - for
example handlers of different archive types where you might ship a stock
set of handlers, but want to allow plugins to add handlers for other
archive types.
So there has always been multiple implementations of a given component
role, and an ordering to decide which one to return when someone asks for
just one implementation of that role (compared to asking for a list or a
map). Historically Plexus always gave implementations in plugins/extensions
a slightly higher priority than core - and "newer" plugins in terms of when
they were added to the runtime build a slightly higher priority than
"older" plugins. The ordering of implementations inside a given realm or
classloader followed the "classpath" ordering of the jars, while the
ordering of implementations inside a jar followed their order in the Plexus
XML descriptor.
Almost 10 years ago Maven switched from the old Plexus container to a new
shim built on top of Guice that supports the same Plexus API and behaviour.
In other words, the same ranking between core and plugin/extension
implementations and the same classpath/descriptor ordering for
implementations in the same classloader/jar. When moving from Plexus
annotations to JSR330 annotations the same behaviour was applied to the
order of implementations in the javax.injected.Named descriptor (which is
in some ways a replacement for Plexus' components.xml.) The code and
behaviour to manage all this has been there for a while since the shim
manages both sets of annotations and maps them to Guice bindings, it's only
recently that selected parts of Maven have been switching from Plexus
annotations to JSR330 annotations.
This is why the ordering in the javax.injected.Named descriptor makes a
difference in terms of multiple implementations in the same jar - it's
following the same historical ordering that Plexus would apply to
implementations in components.xml. The difference is that
the javax.injected.Named descriptor is typically built as the code is
compiled by using an annotation processor, rather than as a separate
packaging step (although that can be configured when it makes sense such as
generating an uber-index for a collection of archives.) The use of
an annotation processor means that differences in the order that javac
compiles the classes can currently affect the order of them in the
descriptor. A lot of the time that ordering doesn't change, especially when
you're using the same OS and version of java, but to make sure we get
completely reproducible builds Hervé has proposed a stricter ordering on
the javax.injected.Named descriptor.
On Sun, 3 Nov 2019 at 04:31, Gabriel Belingueres
wrote:
> Thanks Stuart.
>
> The reproducibility PR you mention helps in having a deterministic ordering
> inside the Named components file to buld exactly the same executable, but
> it does not mean it is the right priority for component injection.
>
> Do you know if it is possible to configure sisu to throw an exception if
> trying to inject an ambiguous component? Otherwise, I guess we must
> implement some sort of "ambiguity checker", either as an integration test
> (don't know if it is possible) or either built-it into maven executable.
>
>
>
>
> El sáb., 2 de nov. de 2019 a la(s) 20:54, Stuart McCulloch (
> mccu...@gmail.com) escribió:
>
> > Yes, when there are multiple non-default implementations with the same
> > priority then it will pick the first in the list (where the "list" in
> > question is actually a combination of plugins + extensions + core
> > bindings for the given type)
> >
> > If a particular implementation should be treated as the default then it
> > should either start with "Default" or be annotated with
> @Named("default") -
> > the benefit of this approach is that it documents that this is the
> default
> > implementation, to be favoured over the others. Alternatively if you want
> > to have an ordering between implementations then you can use @Priority to
> > assign specific priorities and favour one over the other.
> >
> > If you don't mark an implementation as default and don't define any
> > priorities then the only current guarantees are that implementations in
> > plugins and extensions will be favoured over implementations in core (to
> > allow overriding). But there is an upcoming improvement to sort the list
> > inside each module that would make this more deterministic from build to
> > build, at least when ranking implementations inside a particular module:
> >
Re: [GitHub] [maven-compiler-plugin] eolivelli commented on issue #1: [MCOMPILER-320] Introduce additionalClasspathElements property
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/ [https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/] master is blue... On 2-11-2019 11:19:42, GitBox wrote: eolivelli commented on issue #1: [MCOMPILER-320] Introduce additionalClasspathElements property URL: https://github.com/apache/maven-compiler-plugin/pull/1#issuecomment-549030217 @rfscholte it looks like the maven compiler plugin is not in good shape. We should fix it before committing this patch 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: last review of Reproducible Builds proposal
great feedback, thank you: this proves the initial set of only 3 plugins is a good basis. For checking the many output artifacts from a build, future buildinfo file [1] should help a lot. I still have many usability concerns for Maven multi-module builds (starting with: should we generate only the root buildinfo or one buildinfo per Maven module?) Let's keep the ball rolling: today, it's plugins release day!!! Regards, Hervé [1] https://reproducible-builds.org/docs/jvm/ Le vendredi 1 novembre 2019, 13:34:32 CET Christofer Dutz a écrit : > Hi, > > so I just updated the versions of the 3 plugins and gave the Apache PLC4X > build a little spin ... > https://github.com/apache/plc4x/tree/feature/reproducible-builds > > Did two executions of this: > mvn -U -P > with-boost,with-java,with-dotnet,with-cpp,with-python,with-proxies,with-san > dbox,with > -DaltDeploymentRepository=snapshot-repo::default::file:./local-snapshots-di > r clean deploy (but with a different second local repo location) > > Then I used "diff" and "cmp" to compare individual files and it didn't show > differences with the artifacts I chose ... now I guess I'll have to whip > up some little bash script to sort of compare the artifacts from one > directory with the other (Unfortunately the SNAPSHOT timestamps are a > little annoying :-/ > We do have some C++, C# and Python modules ... but I wouldn't expect the C++ > and C# to be reproducible. > Chris > > > Am 01.11.19, 12:04 schrieb "Hervé BOUTEMY" : > > Le vendredi 1 novembre 2019, 09:40:40 CET Christofer Dutz a écrit : > > > Hi Herve, > > > > thanks for that will try it asap and report any findings back. > > > > But good to know that there is a difference between JDK major versions > > and > > OSes ... so it would probably be best to stage releases on Linux with > > an > > OpenJDK of the minimum supported version? > > Just thinking how to make it > > possible to verify without having to buy Mac or Windows licenses ... > > guess > > on every machine you could whip up a Ubuntu VM for verification. Just > > thinking about it ... perhaps it would be best to create a Docker > > image for doing the reproducible stuff ... > > just to be clear: the difference is on newline only, then Windows vs > anything else. You get the same result on Linux, MacOS, FreeBSD, or any > other Unix. > And if I want to be complete, if you get a source tarball from Windows, > extract it to a Linux/MacOS/... box and build with "mvn - > Dline.separator='\r\n'", in general, you get the same result as a build > under Windows: I tested multiple times, it worked, but we'll see if it > works always or just "in general" > > > > Are there any plans on creating a plugin to allow verification? > > > > Sort of something like this: > > "mvn package release:verify-reproduicble > > -DstagingRepoUrl=a.b.c.de/repo/blahblahblah" > > (Which doesn't deploy the > > artifacts, but instead download them and do a binary comparison) > > yes, but for now it was completely another form: this is the "Buildinfo > file" proposal https://reproducible-builds.org/docs/jvm/ > that I stopped to work on 1 year ago given I had no chance to get the > same output: it's now a good time to restart working on it as next steps > > > > Also it could be great if the release-plugin could automatically set > > the > > property: > > a) if it finds the "project.build.outputTimestamp" set to some > > placeholder value b) if some switch tells it to prepare a > > reproducible > > build by using some sort of "switch" parameter > > Guess that would sort of close the loop to get the biggest benefit out > > of > > the reproducible builds. > > +1 > issue has been created > https://issues.apache.org/jira/browse/MRELEASE-1029 But I didn't work on > it yet, help welcome > > > > I would be happy to help as I think this is one > > of the greatest new features. (Ok ... perhaps besides the > > sound-output-extension I learned about yesterday ;-) ) > > +1 > the current step is important, but it's only the beginning of the story > from an effective usage perspective > > Regards, > > Hervé > > > > > > Chris > > > > > > Am 01.11.19, 09:24 schrieb "Hervé BOUTEMY" : > > > > > > Le jeudi 31 octobre 2019, 17:26:52 CET Christofer Dutz a écrit : > > > > > > > > > Hi all, > > > > > > as I can see you're voting on releasing the reproducible build > > > extended > > > plugin versions. > > > > > > > > Is there any documentation on how to use this new > > > > > > > > > feature? > > > > > > I had a look at the confluence page, but that seemed like a > > >
Re: New link pattern when option is set to true
thanks. Created: https://issues.apache.org/jira/browse/MJAVADOC-628 Max On Sun, Nov 3, 2019 at 4:51 AM Enrico Olivelli wrote: > Hi Max. > sorry for late reply. > > I think your idea is interesting and you work is valuable, > You can follow up by creating a JIRA in issues.apache.org in MJAVADOC > project and then you can also send a PR. > Please add an integration test. > > this is the guide for new contributors > https://maven.apache.org/guides/development/guide-helping.html > > Enrico > > Il giorno ven 1 nov 2019 alle ore 09:26 Max Zhu ha > scritto: > >> hi, >> >> Any update on this please? Is this mail group actively monitored? or >> should >> I raise a pull request directly to the project? >> >> Max >> >> On Mon, Oct 28, 2019 at 6:12 PM Max Zhu wrote: >> >> > For what's worth I am talking about maven-javadoc-plugin (just realized >> > this is the main maven mail group) >> > >> > On Sat, Oct 26, 2019 at 6:51 PM Max Zhu wrote: >> > >> >> hi, >> >> >> >> Wondering if it makes sense to extend option to >> javadoc.io. >> >> >> >> For example, google gson (https://github.com/google/gson) has pointed >> >> their javadoc to https://www.javadoc.io/doc/com.google.code.gson/gson >> on >> >> their README.md. But currently, maven-javadoc-plugin will only try to >> fetch >> >> https://github.com/google/gson/apidoc/package-list , which apparently >> is >> >> an invalid address. >> >> >> >> I am aware there is already on option to extend tag, but that's >> >> quite tedious as everytime we have to manually keep things in sync >> when we >> >> add / remove dependencies or change versions. >> >> >> >> There are quite a few popular libraries hosting javadoc with >> javadoc.io >> >> already (eg, mockito / spark), and the pattern is very simple as well: >> >> >> https://www.javadoc.io/doc/[group_id]/[artifact_id]/[version_id]/package-list >> >> >> >> Thus, it will be quite helpful if maven-javadoc-plugin can just >> >> automatically try this url pattern from the dependency list as well. >> >> >> >> Declaimer, I started javadoc.io about 5 years ago and now it's getting >> >> more trendy these days, so I would like to better support this project. >> >> >> >> Max >> >> >> >> >> >> Reference: >> >> >> https://github.com/apache/maven-javadoc-plugin/blob/b1c029f26c4dc40b29a0e122e5c42b294845acfd/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L6526 >> >> >> >> >> > >> >
Re: Regression in model interpolation coming from using JSR-330?
nice idea, but overriding by adding a new implementation in classpath is the
normal overriding way: not sure how "ambiguity checker" could make a difference
between such wanted override vs unwanted ambiguity
BTW, how did you see that StringVisitorModelInterpolator was not used but
StringSearchModelInterpolator instead, please?
Regards,
Hervé
Le dimanche 3 novembre 2019, 05:30:50 CET Gabriel Belingueres a écrit :
> Thanks Stuart.
>
> The reproducibility PR you mention helps in having a deterministic ordering
> inside the Named components file to buld exactly the same executable, but
> it does not mean it is the right priority for component injection.
>
> Do you know if it is possible to configure sisu to throw an exception if
> trying to inject an ambiguous component? Otherwise, I guess we must
> implement some sort of "ambiguity checker", either as an integration test
> (don't know if it is possible) or either built-it into maven executable.
>
>
>
>
> El sáb., 2 de nov. de 2019 a la(s) 20:54, Stuart McCulloch (
>
> mccu...@gmail.com) escribió:
> > Yes, when there are multiple non-default implementations with the same
> > priority then it will pick the first in the list (where the "list" in
> > question is actually a combination of plugins + extensions + core
> > bindings for the given type)
> >
> > If a particular implementation should be treated as the default then it
> > should either start with "Default" or be annotated with @Named("default")
> > -
> > the benefit of this approach is that it documents that this is the default
> > implementation, to be favoured over the others. Alternatively if you want
> > to have an ordering between implementations then you can use @Priority to
> > assign specific priorities and favour one over the other.
> >
> > If you don't mark an implementation as default and don't define any
> > priorities then the only current guarantees are that implementations in
> > plugins and extensions will be favoured over implementations in core (to
> > allow overriding). But there is an upcoming improvement to sort the list
> > inside each module that would make this more deterministic from build to
> > build, at least when ranking implementations inside a particular module:
> > https://github.com/eclipse/sisu.inject/pull/5 - with that change then
> > you'll get an extra guarantee that inside a module it will be ordered by
> > package+name.
> >
> > PS. even with the old Plexus runtime annotations you could be at the whim
> > of classpath ordering, similarly Plexus XML descriptors are influenced by
> > classpath resource ordering - so ideally it's better to be explicit about
> > ordering
> >
> > On Sat, 2 Nov 2019 at 23:07, Gabriel Belingueres
> >
> > wrote:
> > > Hi:
> > >
> > > I just built maven core from source and found that it was using
> > > StringSearchModelInterpolator instead of StringVisitorModelInterpolator,
> >
> > a
> >
> > > regression from the last 3.6.2 release.
> > >
> > > I found that in maven-model-builder/META-INF/sisu/javax.injected.Named
> > > file, both interpolators are listed but in reverse order (comparing it
> >
> > with
> >
> > > the same file in 3.6.2), that is StringSearchModelInterpolator appear
> >
> > first
> >
> > > in the file and StringVisitorModelInterpolator second.
> > >
> > > (I believe the dependency injection picks up the first one it finds with
> > > the right type.)
> > >
> > > Deleting the @Named annotation from StringSearchModelInterpolator solved
> > > the issue, as this make the entry disappear from the
> > > javax.injected.Named
> > > file. Then the dependency injection uses the
> > > StringVisitorModelInterpolator.
> > >
> > > Can anyone confirm this issue?
> > > And if so, how to best prevent in the future that this type of
> > > dependency
> > > injection regressions from happening?
> > >
> > > Kind regards,
> > > Gabriel
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Apache Maven Assembly Plugin version 3.2.0
Hi, The vote has passed with the following result: +1 : Sylwester Lachiewicz, Karl Heinz Marbaise, Enrico Olivelli, Tibor Digana, Hervé Boutemy PMC quorum reached I will promote the artifacts to the central repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Apache Maven JAR Plugin version 3.2.0
Hi, The vote has passed with the following result: +1 : Olivier Lamy, Karl Heinz Marbaise, Sylwester Lachiewicz, Hervé Boutemy, Tibor Digana, PMC quorum reached I will promote the artifacts to the central repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Apache Maven Source Plugin version 3.2.0
Hi, The vote has passed with the following result: +1 : Olivier Lamy, Romain Manni-Bucau, Tibor Digana, Hervé Boutemy, Karl Heinz Marbaise, Sylwester Lachiewicz PMC quorum reached I will promote the artifacts to the central repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Assembly Plugin version 3.2.0
here is my +1 Regards, Hervé Le mardi 29 octobre 2019, 23:10:46 CET Hervé BOUTEMY a écrit : > Hi, > > We solved 9 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220 > rsion=12344773=Text > > Staging repo: > https://repository.apache.org/content/repositories/maven-1534/ > https://repository.apache.org/content/repositories/maven-1534/org/apache/mav > en/plugins/maven-assembly-plugin/3.2.0/maven-assembly-plugin-3.2.0-source-re > lease.zip > > Source release checksum(s): > maven-assembly-plugin-3.2.0-source-release.zip sha512: > 23c1c79c51279232efc8dbeb697a6357257263c03356732d94b06f26ce219f44e650910ec7d > eb2ca8889449e669d40c47f7717ab6c1fb1e5ea6572cf643a5926 > > Staging site: > https://maven.apache.org/plugins-archives/maven-assembly-plugin-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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
