Re: Logging in Maven 4
Hi,
sorry to jump into a conversation, but isn't System.Logger mainly for JDK
internals? I always thought that using it is in a similar ballpark as using
java.util.Optional in method arguments (i.e. „please don’t“).
Pavel
On Sun, 3 Mar 2024 at 23:54, Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> Le 2024-03-03 à 22 h 53, Romain Manni-Bucau a écrit :
>
> > It is expected to use System so the logger finder. if it is not the
> > case you broke the contract of this API.
> >
> Can you point to the contract saying that?
>
>
> > As a matter of fact it is current state so not sure what you want to
> > enable.
> >
> For the third time: more useful log information ("real" source class and
> source method) when desired, e.g. for debugging.
>
>
> > It is the same rational than creating maven-api to not restate the 10
> > years of discussion leading to that.
> >
> I'm not questioning the whole Maven API, only a part that does not seem
> to have any added value compared to a standard Java interface that did
> not existed 10 years ago.
>
>
> > JUL had been proposed multiple times (…snip…) but core committers
> > always had been opposed to that and System.Logger has some limitations
> >
> Okay, so Log was the compromise between java.util.logging and println. I
> understand that. But System.Logger is the same compromise and is as
> suitable as Log. Its only drawback compared to Log was to not be
> available before Java 9.
>
>
> > Ok, assume we do nothing, we reached that stage sine ~10 years - ok
> > the way to do it changed a bit but we didn't loose it, this is where
> > you lost me.
> >
> I'm just proposing to replace Log by System.Logger, which provides the
> exact same API in only a slightly different way. So:
>
> logger.info("My information");
>
> Become:
>
> logger.log(System.Logger.Leven.INFO, "My information");
>
> That's all. The benefit is the one that I repeated 3 times. Part of my
> discussion in previous email was an attempt to justify that the extra
> verbosity caused by having to write "System.Logger.Leven.INFO" is not
> necessarily a bad thing if it creates an incentive to not invoke "log"
> for every line in multi-line messages.
>
> Martin
>
>
Re: Possible improvements on Maven
Hi, not a maintainer here, but just want to add to this: > Compare to newer package managers such as NPM, which only has two scopes (i.e., dependencies, devdependencies) NPM has dependencies, devDependencies, peerDependencies, bundleDependencies and optionalDependencies :) Pavel On Sat, 1 Jul 2023 at 08:11, #ZHAO LIDA# wrote: > Dear Maven maintainers, > > > we are studying Maven dependency specifications and we would like to offer > several possible improvements for Maven. > > > (1) The scope management of Maven is complicated and hard to distinguish. > Maven maintained 6 scopes (i.e., compile, runtime, provided, system, test, > and import). Compare to newer package managers such as NPM, which only has > two scopes (i.e., dependencies, devdependencies), Maven has too many types > of scopes, which makes it more difficult for users to understand. We went > over all POMs on the Maven Central (around 8M artifacts, collected in March > 2022) and count the frequency of all types of scope. Some of the scopes are > rarely used. Only 0.35% of POMs in the Maven Center used system scope. > Also, system scope is similar to provided scope, and import scope can > hardly be regarded as a dependency scope. We suggest simplifying the types > of scopes by merging system into provided and removing import. > > > (2) In the documentation of Default Artifact Handlers ( > https://maven.apache.org/ref/3.9.3/maven-core/artifact-handlers.html), > type and classifier should introduce more commonly used values as their > default value to provide better examples. We found that the default values > are rarely used and are not good examples for users to understand the use > of the settings. Setting commonly used values as default can help users > understand the usage of the settings. We went over all POMs on the Maven > Central (around 8M artifacts, collected in March 2022) and count the > frequency of all possible values of classifier and type. According to our > research, in classifier, the default values have low frequencies, including > tests (1.05%), javadoc (0.35%), sources (0.29%), and client(0.01%). More > commonly used values are features (1.20%), linux-x86_64 (0.34%), and > osx-x86_64 (0.27%). As for type, the top default values are pom (4.38%), > test-jar (2.85%), war (1.08%) and the rest of the values are all below > 0.1%. Other common examples are esa (2.53%), zip (1.88%), and xml (1.31%). > > > Regards, > > NTU CSL > >
Re: Bug report - maven shade plugin - transitive dependencies of provided dependency included in uber-jar
Hi, there is a configuration for including/excluding provided scope dependencies - https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#keepDependenciesWithProvidedScope . It is not apparent what should be the default behavior from the documentation though. Pavel On Thu, 9 Feb 2023 at 07:52, Adam Cervenka (ZA) wrote: > Hello, > > I would like to report a bug. > > I declared a dependency as provided, but the shade plugin still includes > its transitive dependencies in the uber-jar. > > To demonstrate the issue, I created following repository: > https://github.com/cerveada/shade-plugin-issue > > Using the poms and instructions in the repo it should be easy to replicate > the issue. > > Thanks, > Adam Cervenka > > Absa Bank Limited is a subsidiary of Absa Group Limited and is an > Authorised Financial Services Provider and Registered Credit Provider, > registration number: NCRCP7. > > Absa Bank Limited provides services to Absa Group Limited and its > subsidiaries. > > Absa is committed to complying with applicable data privacy laws and to > safeguarding the privacy and security of the personal information it > collects and processes, in respect of all current and prospective clients. > To understand more about how we collect, store, and process your personal > information, please view our privacy statement at absa.co.za > > This e-mail and any attachments are confidential and intended solely for > the addressee and may also be privileged or exempt from disclosure under > applicable law. If you are not the addressee, or have received this e-mail > in error, please notify the sender immediately, delete it from your system > and do not copy, disclose or otherwise act upon any part of this e-mail or > its attachments. Internet communications are not guaranteed to be secure or > virus-free. We do not accept responsibility for any loss arising from > unauthorised access to, or interference with, any Internet communications > by any third party, or from the transmission of any viruses. We may monitor > replies to this e-mail for operational or business reasons. Any opinion or > other information in this e-mail or its attachments that does not relate to > our business is personal to the sender and we do not endorse it. >
Re: MD5, SHA1, but nothing (still) safe?
Hello, i see two mixed topics in this discussion - verifying artifact transfer integrity and verifying that the downloaded artifact is really the one expected from the security perspective. The latter does not have anything to do with Maven Central or any other repository. Checksums in repositories (used by Wagon) can only be used for verifying transfer integrity. Verifying artifact via secure checksum that is obtained from a trusted source (e.g. local file like package-lock.json in NodeJS) and having some sort of lock file in the project is a different topic that is for example being addressed by checksum-maven-plugin. I think it would be awesome if Maven itself can support this use case... I would love to be sure that a specific JAR downloaded a year ago is exactly the same as JAR with the same coordinates downloaded today. Pavel On Thu, 14 Oct 2021 at 10:47, Mickael Istria wrote: > On Thu, Oct 14, 2021 at 10:36 AM Romain Manni-Bucau > > wrote: > > > I agree with Bernd, checksums are there to validate the consistency of > the > > artifact, nothing linked to security. > > > > Ensuring user gets a consistent artifact as desired -and not a malicious > forged one- is 1 aspect of security. > > On central the security side is provided by the asc file which is > > sufficient if you trust only allowed releasers keys in practise, > pretending > > you are a releaser will be quite hard so this is likely the best security > > you can setup as of today and no checksum algorithm can make it stronger > > (it is 1-1 in terms of security). > > > > That is as far as I understand another aspect of security, which is more > about authenticating provenance of the artifact when publishing it to the > repo and verifying the author. I can be used as an alternative to checksums > as well because the signature contains a form of hash, but -correct me if > I'm wrong- if the only goal is to verify consistency, then signatures are > overkill and will perform worse than checksum algorithms anyway. >
