Re: [WEAVER] - move to dormant?
On Tue, 10 Oct 2023, 10:05 Romain Manni-Bucau, wrote: > Guess we can delay it of a few years (maybe one more LTS) to avoid to > import it in bval to drop it later, sounds like useless work, but overall, > also sounds like java direction for the project. > > Le mar. 10 oct. 2023 à 00:36, Matt Benson a écrit : > > > This was spun out to support security manager stuff in Apache BVal. Until > > that known ASF client is able (at the specification level) to exclusively > > support Java versions with no SecurityManager whatsoever, I'd personally > > prefer to fix [weaver], but having made my preference known I will defer > to > > the consensus of the community. > > > > Matt > > > > On Mon, Oct 9, 2023, 10:26 AM sebb wrote: > > > > > Does not seem to be active. > > > > > > Last release 2018. > > > > > > Compilation failures on all Java versions with: > > > > > > org/apache/commons/weaver/privilizer/PrivilizingVisitor.java:[55,76] > > > an enclosing instance that contains > > > org.apache.commons.weaver.privilizer.Privilizer.PrivilizerClassVisitor > > > is required > > > > > > Tests fail on Java15+ with: > > > > > > IllegalArgument Unsupported class file... > > > > > > Download stats show almost no traffic over last 3 months: > > > https://infra-reports.apache.org/#downloads&project=commons/weaver > > > What traffic there is looks like it comes from bots. > > > > > > Sebb > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > >
Re: [WEAVER] - move to dormant?
Let me know if/when you need a release candidate... Gary On Mon, Oct 9, 2023 at 10:05 PM Romain Manni-Bucau wrote: > > Guess we can delay it of a few years (maybe one more LTS) to avoid to > import it in bval to drop it later, sounds like useless work, but overall, > also sounds like java direction for the project. > > Le mar. 10 oct. 2023 à 00:36, Matt Benson a écrit : > > > This was spun out to support security manager stuff in Apache BVal. Until > > that known ASF client is able (at the specification level) to exclusively > > support Java versions with no SecurityManager whatsoever, I'd personally > > prefer to fix [weaver], but having made my preference known I will defer to > > the consensus of the community. > > > > Matt > > > > On Mon, Oct 9, 2023, 10:26 AM sebb wrote: > > > > > Does not seem to be active. > > > > > > Last release 2018. > > > > > > Compilation failures on all Java versions with: > > > > > > org/apache/commons/weaver/privilizer/PrivilizingVisitor.java:[55,76] > > > an enclosing instance that contains > > > org.apache.commons.weaver.privilizer.Privilizer.PrivilizerClassVisitor > > > is required > > > > > > Tests fail on Java15+ with: > > > > > > IllegalArgument Unsupported class file... > > > > > > Download stats show almost no traffic over last 3 months: > > > https://infra-reports.apache.org/#downloads&project=commons/weaver > > > What traffic there is looks like it comes from bots. > > > > > > Sebb > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [WEAVER] - move to dormant?
Note that changes to the code since 2.0 mean that it no longer compiles or passes all tests. Whether it is worth fixing these is unclear to me. On Tue, 10 Oct 2023 at 13:00, Gary Gregory wrote: > > Let me know if/when you need a release candidate... > > Gary > > On Mon, Oct 9, 2023 at 10:05 PM Romain Manni-Bucau > wrote: > > > > Guess we can delay it of a few years (maybe one more LTS) to avoid to > > import it in bval to drop it later, sounds like useless work, but overall, > > also sounds like java direction for the project. > > > > Le mar. 10 oct. 2023 à 00:36, Matt Benson a écrit : > > > > > This was spun out to support security manager stuff in Apache BVal. Until > > > that known ASF client is able (at the specification level) to exclusively > > > support Java versions with no SecurityManager whatsoever, I'd personally > > > prefer to fix [weaver], but having made my preference known I will defer > > > to > > > the consensus of the community. > > > > > > Matt > > > > > > On Mon, Oct 9, 2023, 10:26 AM sebb wrote: > > > > > > > Does not seem to be active. > > > > > > > > Last release 2018. > > > > > > > > Compilation failures on all Java versions with: > > > > > > > > org/apache/commons/weaver/privilizer/PrivilizingVisitor.java:[55,76] > > > > an enclosing instance that contains > > > > org.apache.commons.weaver.privilizer.Privilizer.PrivilizerClassVisitor > > > > is required > > > > > > > > Tests fail on Java15+ with: > > > > > > > > IllegalArgument Unsupported class file... > > > > > > > > Download stats show almost no traffic over last 3 months: > > > > https://infra-reports.apache.org/#downloads&project=commons/weaver > > > > What traffic there is looks like it comes from bots. > > > > > > > > Sebb > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Standardise Maven defaultGoal in components?
On Mon, Oct 9, 2023 at 7:50 PM sebb wrote: > > On Sun, 8 Oct 2023 at 18:52, Gary Gregory wrote: > > > > The default goal is always used by GitHub builds > > Are you sure about that? Yes, UNLESS, someone has decided to circumvent the default goal with a custom goal list in a .github file. Gary > > GH does not automatically know how to call Maven. > We have to configure the calls in the workflows. > Not all workflows rely on the default goal, though most do. > > > and it is nice to use as a dev before you push. > > This lets us avoid putting some custom mvn call in the > > GH build definition. We can also document to users that calling 'mvn' is a > > all you need to do to validate a PR or push. > > But only if the defaultGoal is suitably configured. > AFAICT that is not the case for all components at present. > > > Gary > > > > On Sun, Oct 8, 2023, 1:25 PM Phil Steitz wrote: > > > > > What exactly is the point of the default goal? I mean when is it expected > > > to be used? Automations? Pipes of some kind? It’s not always executed, > > > right? So if I say “clean” was the default, “mvn test” would not mean > > > “mvn > > > clean test”, right? > > > > > > Phil > > > > > > > On Oct 8, 2023, at 7:11 AM, sebb wrote: > > > > > > > > There are currently lots of variations of the defaultGoal in different > > > > components. > > > > > > > > It may be sensible to establish a standard setting which components > > > > should adopt (unless there is a good reason to do otherwise). > > > > > > > > If so, what should that be, and where does it get documented? > > > > > > > > Personally, I don't think install should ever be a default goal as it > > > > changes the environment outside the component. > > > > > > > > Main goals seen: > > > > clean > > > > install > > > > package > > > > site > > > > test > > > > verify > > > > > > > > Other goals seen: > > > > apache-rat:check > > > > checkstyle:check > > > > clirr:check > > > > findbugs:check > > > > japicmp:cmp > > > > javadoc:javadoc > > > > pmd:check > > > > pmd:cpd-check > > > > spotbugs:check > > > > > > > > Sebb > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Standardise Maven defaultGoal in components?
On Tue, 10 Oct 2023 at 13:05, Gary Gregory wrote: > > On Mon, Oct 9, 2023 at 7:50 PM sebb wrote: > > > > On Sun, 8 Oct 2023 at 18:52, Gary Gregory wrote: > > > > > > The default goal is always used by GitHub builds > > > > Are you sure about that? > > Yes, UNLESS, someone has decided to circumvent the default goal with a > custom goal list in a .github file. I agree with you inasmuch as the default goal is used by Maven if no other goals are provided. But this is true of any Maven invocation; there is nothing special about the GitHub builds. Note however, that most of the Commons GH workflows don't use a bare 'mvn' command; they generally include additional options which are more suited to non-interactive, automated use. The problem here is that the options can easily obscure the fact that a goal has also been used. For example, which (if any) of the following override the default goal? mvn -V --batch-mode -Ddoclint=all --file pom.xml --no-transfer-progress mvn -V --file pom.xml --no-transfer-progress -Ddoclint=none -Darguments=-Xdoclint:none mvn -V --file pom.xml --no-transfer-progress -DtrimStackTrace=false '-Djdk.tls.client.protocols=TLSv1.2' mvn -V --batch-mode --no-transfer-progress install -D"maven.javadoc.skip=true" -D"org.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn" As an aside, I don't see the point of cluttering up the command line with '--file pom.xml', as that is the default. For options that are common for batch jobs I think the convention should be to use the short names to avoid clutter, eg. mvn -V -B -ntp instead of mvn -V --batch-mode --file pom.xml --no-transfer-progress > Gary > > > > > GH does not automatically know how to call Maven. > > We have to configure the calls in the workflows. > > Not all workflows rely on the default goal, though most do. > > > > > and it is nice to use as a dev before you push. > > > This lets us avoid putting some custom mvn call in the > > > GH build definition. We can also document to users that calling 'mvn' is a > > > all you need to do to validate a PR or push. > > > > But only if the defaultGoal is suitably configured. > > AFAICT that is not the case for all components at present. > > > > > Gary > > > > > > On Sun, Oct 8, 2023, 1:25 PM Phil Steitz wrote: > > > > > > > What exactly is the point of the default goal? I mean when is it > > > > expected > > > > to be used? Automations? Pipes of some kind? It’s not always > > > > executed, > > > > right? So if I say “clean” was the default, “mvn test” would not mean > > > > “mvn > > > > clean test”, right? > > > > > > > > Phil > > > > > > > > > On Oct 8, 2023, at 7:11 AM, sebb wrote: > > > > > > > > > > There are currently lots of variations of the defaultGoal in > > > > > different > > > > > components. > > > > > > > > > > It may be sensible to establish a standard setting which components > > > > > should adopt (unless there is a good reason to do otherwise). > > > > > > > > > > If so, what should that be, and where does it get documented? > > > > > > > > > > Personally, I don't think install should ever be a default goal as it > > > > > changes the environment outside the component. > > > > > > > > > > Main goals seen: > > > > > clean > > > > > install > > > > > package > > > > > site > > > > > test > > > > > verify > > > > > > > > > > Other goals seen: > > > > > apache-rat:check > > > > > checkstyle:check > > > > > clirr:check > > > > > findbugs:check > > > > > japicmp:cmp > > > > > javadoc:javadoc > > > > > pmd:check > > > > > pmd:cpd-check > > > > > spotbugs:check > > > > > > > > > > Sebb > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Standardise Maven defaultGoal in components?
I agree that '--file pom.xml' is superfluous, it probably comes from something that was generated or from copy pasta. RE other options, I prefer full option names like: 'mvn -V --batch-mode --no-transfer-progress' because it makes maintenance and eyeballing straightforward without requiring Maven-foo. Gary On Tue, Oct 10, 2023 at 8:45 AM sebb wrote: > > On Tue, 10 Oct 2023 at 13:05, Gary Gregory wrote: > > > > On Mon, Oct 9, 2023 at 7:50 PM sebb wrote: > > > > > > On Sun, 8 Oct 2023 at 18:52, Gary Gregory wrote: > > > > > > > > The default goal is always used by GitHub builds > > > > > > Are you sure about that? > > > > Yes, UNLESS, someone has decided to circumvent the default goal with a > > custom goal list in a .github file. > > I agree with you inasmuch as the default goal is used by Maven if no > other goals are provided. > But this is true of any Maven invocation; there is nothing special > about the GitHub builds. > > Note however, that most of the Commons GH workflows don't use a bare > 'mvn' command; they generally include additional options which are > more suited to non-interactive, automated use. > > The problem here is that the options can easily obscure the fact that > a goal has also been used. > > For example, which (if any) of the following override the default goal? > > mvn -V --batch-mode -Ddoclint=all --file pom.xml --no-transfer-progress > mvn -V --file pom.xml --no-transfer-progress -Ddoclint=none > -Darguments=-Xdoclint:none > mvn -V --file pom.xml --no-transfer-progress -DtrimStackTrace=false > '-Djdk.tls.client.protocols=TLSv1.2' > mvn -V --batch-mode --no-transfer-progress install > -D"maven.javadoc.skip=true" > -D"org.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn" > > As an aside, I don't see the point of cluttering up the command line > with '--file pom.xml', as that is the default. > For options that are common for batch jobs I think the convention > should be to use the short names to avoid clutter, eg. > > mvn -V -B -ntp > instead of > mvn -V --batch-mode --file pom.xml --no-transfer-progress > > > Gary > > > > > > > > GH does not automatically know how to call Maven. > > > We have to configure the calls in the workflows. > > > Not all workflows rely on the default goal, though most do. > > > > > > > and it is nice to use as a dev before you push. > > > > This lets us avoid putting some custom mvn call in the > > > > GH build definition. We can also document to users that calling 'mvn' > > > > is a > > > > all you need to do to validate a PR or push. > > > > > > But only if the defaultGoal is suitably configured. > > > AFAICT that is not the case for all components at present. > > > > > > > Gary > > > > > > > > On Sun, Oct 8, 2023, 1:25 PM Phil Steitz wrote: > > > > > > > > > What exactly is the point of the default goal? I mean when is it > > > > > expected > > > > > to be used? Automations? Pipes of some kind? It’s not always > > > > > executed, > > > > > right? So if I say “clean” was the default, “mvn test” would not > > > > > mean “mvn > > > > > clean test”, right? > > > > > > > > > > Phil > > > > > > > > > > > On Oct 8, 2023, at 7:11 AM, sebb wrote: > > > > > > > > > > > > There are currently lots of variations of the defaultGoal in > > > > > > different > > > > > > components. > > > > > > > > > > > > It may be sensible to establish a standard setting which components > > > > > > should adopt (unless there is a good reason to do otherwise). > > > > > > > > > > > > If so, what should that be, and where does it get documented? > > > > > > > > > > > > Personally, I don't think install should ever be a default goal as > > > > > > it > > > > > > changes the environment outside the component. > > > > > > > > > > > > Main goals seen: > > > > > > clean > > > > > > install > > > > > > package > > > > > > site > > > > > > test > > > > > > verify > > > > > > > > > > > > Other goals seen: > > > > > > apache-rat:check > > > > > > checkstyle:check > > > > > > clirr:check > > > > > > findbugs:check > > > > > > japicmp:cmp > > > > > > javadoc:javadoc > > > > > > pmd:check > > > > > > pmd:cpd-check > > > > > > spotbugs:check > > > > > > > > > > > > Sebb > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --
Re: [ALL] Standardise Maven defaultGoal in components?
On Tue, 10 Oct 2023 at 13:52, Gary Gregory wrote: > > I agree that '--file pom.xml' is superfluous, it probably comes from > something that was generated or from copy pasta. > > RE other options, I prefer full option names like: 'mvn -V > --batch-mode --no-transfer-progress' because it makes maintenance and > eyeballing straightforward without requiring Maven-foo. That should actually be: mvn --show-version --batch-mode --no-transfer-progress If every workflow used the same prefix, people would soon get used to it. > Gary > > On Tue, Oct 10, 2023 at 8:45 AM sebb wrote: > > > > On Tue, 10 Oct 2023 at 13:05, Gary Gregory wrote: > > > > > > On Mon, Oct 9, 2023 at 7:50 PM sebb wrote: > > > > > > > > On Sun, 8 Oct 2023 at 18:52, Gary Gregory > > > > wrote: > > > > > > > > > > The default goal is always used by GitHub builds > > > > > > > > Are you sure about that? > > > > > > Yes, UNLESS, someone has decided to circumvent the default goal with a > > > custom goal list in a .github file. > > > > I agree with you inasmuch as the default goal is used by Maven if no > > other goals are provided. > > But this is true of any Maven invocation; there is nothing special > > about the GitHub builds. > > > > Note however, that most of the Commons GH workflows don't use a bare > > 'mvn' command; they generally include additional options which are > > more suited to non-interactive, automated use. > > > > The problem here is that the options can easily obscure the fact that > > a goal has also been used. > > > > For example, which (if any) of the following override the default goal? > > > > mvn -V --batch-mode -Ddoclint=all --file pom.xml --no-transfer-progress > > mvn -V --file pom.xml --no-transfer-progress -Ddoclint=none > > -Darguments=-Xdoclint:none > > mvn -V --file pom.xml --no-transfer-progress -DtrimStackTrace=false > > '-Djdk.tls.client.protocols=TLSv1.2' > > mvn -V --batch-mode --no-transfer-progress install > > -D"maven.javadoc.skip=true" > > -D"org.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn" > > > > As an aside, I don't see the point of cluttering up the command line > > with '--file pom.xml', as that is the default. > > For options that are common for batch jobs I think the convention > > should be to use the short names to avoid clutter, eg. > > > > mvn -V -B -ntp > > instead of > > mvn -V --batch-mode --file pom.xml --no-transfer-progress > > > > > Gary > > > > > > > > > > > GH does not automatically know how to call Maven. > > > > We have to configure the calls in the workflows. > > > > Not all workflows rely on the default goal, though most do. > > > > > > > > > and it is nice to use as a dev before you push. > > > > > This lets us avoid putting some custom mvn call in the > > > > > GH build definition. We can also document to users that calling 'mvn' > > > > > is a > > > > > all you need to do to validate a PR or push. > > > > > > > > But only if the defaultGoal is suitably configured. > > > > AFAICT that is not the case for all components at present. > > > > > > > > > Gary > > > > > > > > > > On Sun, Oct 8, 2023, 1:25 PM Phil Steitz > > > > > wrote: > > > > > > > > > > > What exactly is the point of the default goal? I mean when is it > > > > > > expected > > > > > > to be used? Automations? Pipes of some kind? It’s not always > > > > > > executed, > > > > > > right? So if I say “clean” was the default, “mvn test” would not > > > > > > mean “mvn > > > > > > clean test”, right? > > > > > > > > > > > > Phil > > > > > > > > > > > > > On Oct 8, 2023, at 7:11 AM, sebb wrote: > > > > > > > > > > > > > > There are currently lots of variations of the defaultGoal in > > > > > > > different > > > > > > > components. > > > > > > > > > > > > > > It may be sensible to establish a standard setting which > > > > > > > components > > > > > > > should adopt (unless there is a good reason to do otherwise). > > > > > > > > > > > > > > If so, what should that be, and where does it get documented? > > > > > > > > > > > > > > Personally, I don't think install should ever be a default goal > > > > > > > as it > > > > > > > changes the environment outside the component. > > > > > > > > > > > > > > Main goals seen: > > > > > > > clean > > > > > > > install > > > > > > > package > > > > > > > site > > > > > > > test > > > > > > > verify > > > > > > > > > > > > > > Other goals seen: > > > > > > > apache-rat:check > > > > > > > checkstyle:check > > > > > > > clirr:check > > > > > > > findbugs:check > > > > > > > japicmp:cmp > > > > > > > javadoc:javadoc > > > > > > > pmd:check > > > > > > > pmd:cpd-check > > > > > > > spotbugs:check > > > > > > > > > > > > > > Sebb > > > > > > > > > > > > > > - > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > ---
