Re: [VOTE] Require Java 17 for Maven 4

[Kemal Soysal]

+1 (set JDK17 min version for Maven 4.x)

Re: Is it okay to deploy additional artifacts for an identical POM? (as in MDEPLOY-118)

[Kemal Soysal]

Hi Mathias,

I commented on the pull request.
For me it is crucial to be able to upload additional artifacts to a coordinate.
It has various reasons.
When you work in an agile mind set, you do not need every artifact in the very 
beginning.
You do approach agile and deliver first the most needed part.
In case you have a heterogenous development environment that you want to 
provide with a native library
you deliver first your own machines native library….
And then when needed the other machines will follow…

Another much forgotten usage of this additional artifact attachment is, when 
for example a CVE to a coordinate comes up.
At the moment, there is a hard work to maintain the CVEs and related 
coordinates.
It would be great to put a CVE where it belongs… to the coordinate itself

These are my 5 cents,

I vote +1

Best Regards

Kemal

> Am 26.05.2023 um 10:10 schrieb Mathias de Riese :
> 
> Hey there,
> 
> I did not get a reply to this message. Does that mean, all is fine and you 
> would like to merge the PR? (Once review comments are handled, of course.)
> 
> Cheers,
> Mathias
> 
> On Tue, May 23, 2023, at 11:16, Mathias de Riese wrote:
>> Hi,
>> 
>> some time ago I had the problem described in 
>> https://issues.apache.org/jira/browse/MDEPLOY-118: The company I was 
>> working wants to build multiple native artifacts of the same software 
>> on different machines and deploy them. Since additional platforms / 
>> build hosts may be added later as needed by projects and some software 
>> stays rather stable, it is desirable to add artifacts for the same 
>> version over time while preventing re-deploys of artifacts via the repo.
>> 
>> As the same problem was described in the issue, I went ahead and 
>> implemented it in 
>> https://github.com/apache/maven-deploy-plugin/pull/28, which 
>> unfortunately was not merged at the time.
>> 
>> Now, Elliotte remarks that my change might violate Maven repos stare 
>> decisis properties. My intent was to keep these in place while allowing 
>> to add artifacts consistently.
>> 
>> The question to you guys is:
>> 
>> Is adding an artifact to an existing deployment a change of the 
>> deployment in the sense that guarantees are broken?
>> 
>> 
>> In case you would like to merge my PR, I am willing to do the conflict 
>> resolution work by now required. Please contact me via the PR or 
>> directly, in case I loose track of this discussion here, which might 
>> happen, since I am busy with other stuff right now.
>> 
>> Cheers,
>> Mathias de Riese
> 
> -- 
> Mathias de Riese
> math...@de-riese.de
> 
> -----
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

GF Kemal Soysal

__
Kemal Soysal
LS IT-Solutions GmbH
kemal.soy...@ls-it-solutions.de
Mobil: +49 1512 404 55 66
Marthashof 6
D-10435 Berlin

Re: And while I'm on the subject of logging

[Kemal Soysal]

Hi Elliot,

did you try to use mvnDebug?

> Am 24.02.2023 um 13:26 schrieb Elliotte Rusty Harold :
> 
> Real world example from the non-Apache project built with Maven I'm
> working on this morning.
> 
> 1. Build fails
> 2. 591 lines of log output in my console, almost all of which are
> artifacts being downloaded.
> 3. Relevant lines: 1
> 4. Percentage useful content: .17%
> 
> That's bad. But wait. It gets worse.
> 
> The only useful output is
> 
> [ERROR] Failed to execute goal XXX (default) on project XXX: Execution
> default of goal XXX failed.: NullPointerException -> [Help 1]
> 
> So somewhere in my code (I'm writing the plugin that failed) there's a
> NullPointerException. Where? The logs don't tell me! There's no stack
> trace. There's no line number. The most critical information I need to
> debug this isn't included by default. Of course,
> 
> [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> 
> So I rerun with -e and there's the info I need. But
> 
> 1. I shouldn't have had to rerun. The information I actually needed
> should have been shown to me up front.
> 2. I shouldn't have been bombarded with 590 lines of irrelevant log junk.
> 
> Is anyone really willing to argue that the list of artifacts Maven
> downloaded and the amount of time each took are somehow more likely to
> be relevant than an exception arising in the developer's own code? And
> yet that is exactly what we're doing.
> 
> On Mon, Feb 20, 2023 at 9:33 AM Elliotte Rusty Harold
>  wrote:
>> 
>> Typical log message in build:
>> 
>> Downloaded from central:
>> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
>> (14 kB at 776 kB/s)
>> 
>> I have never, ever needed or wanted to know how fast a single artifact
>> was downloaded. And in the extremely unlikely event  I cared how big
>> it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
>> 776 kB/s)?
>> 
>> Maven log files today are often multiple megabytes. Many continuous
>> integration Web UIs truncate them to a 1 MB or so. Any unread info we
>> can remove to bring the size down is helpful, and also makes it much
>> easier for devs to find the lines they actually care about.
>> 
>> --
>> Elliotte Rusty Harold
>> elh...@ibiblio.org
> 
> 
> 
> -- 
> Elliotte Rusty Harold
> elh...@ibiblio.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: And while I'm on the subject of logging

[Kemal Soysal]

+1 logback

> Am 23.02.2023 um 06:39 schrieb Guillaume Nodet :
> 
> Maven Daemon uses logback instead of the simple logger.  This definitely
> allows more configuration freedom.
> Should we switch maven 4 to logback or log4j too ?
> 
> Le mer. 22 févr. 2023 à 18:45, Ralph Goers  a
> écrit :
> 
>> Might I suggest that you are never going to make everyone happy.  That is
>> why Logging frameworks such as Log4j support using Logger names, Log
>> Levels, and Markers as basic ways of categorizing log events. With those
>> you can continue to log events but filter them down to just what the user
>> wants.
>> 
>> Unfortunately, doing this will tie you to a logging implementation if you
>> try to do it programmatically.  If you let the user supply (or override)
>> the logging configuration then this wouldn’t be an issue.
>> 
>> Ralph
>> 
>>> On Feb 22, 2023, at 5:54 AM, Romain Manni-Bucau 
>> wrote:
>>> 
>>> +1 to Guillaume proposal for default behavior while -X still logs
>>> everything (in logs ;))
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
>>> Le mer. 22 févr. 2023 à 13:33, Gary Gregory  a
>>> écrit :
>>> 
 This echoes IMO what a higher level app (Maven in this case) should do,
 tell me when something unusual happens, like when something is taking a
 long time. For us Windows users, the Explorer UI only pops up its
>> progress
 dialog when you are copying "a lot" or its taking "a long time",
>> otherwise
 it is quiet.
 
 Question: when I ask mvn for -U behavior, I do like to see the download
 logging, because I am asking for non-default behavior, I expect the
>> extra
 output.
 
 As previously mentioned, there won't be change that makes everyone
>> happy,
 but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
 folks happy.
 
 Gary
 
 On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:
 
> I do agree that logging all downloads is unneeded, and I do agree that
 the
> hanging case can happen quite often and one needs to be informed.
> However, both goals are not conflicting, we just need to enhance the
> logger/downloader to:
> * print a single statement that it starts downloading things
> * if a download is too slow (for example, nothing has been received
 since
> a few seconds), log a warning message
> * log a summary when the download finished (like "Downloaded 5
 artifacts
> from central and yyy repositories")
> It should not be very difficult to detect stalled downloads.
> 
> Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau <
>> rmannibu...@gmail.com
> 
> a
> écrit :
> 
>> Eliotte I kind of fail to follow your reasoning because it literally
> means
>> don't log any info and just set default log level to ERROR which I
 don't
>> think will make anyone happy.
>> You also tend to think everything works all the time but network
>> issues
> are
>> not work/fail kind of issue, the hanging case is really bothering and
>> downloading logs really help there when you can keep them.
>> Lastly downloads are not expected by maven after one build so being a
 bit
>> more verbose is not an issue and going outside the machine should
 likely
>> always be logged at the beginning these days.
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> 
> 
 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>> 
>> 
>> Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold <
 elh...@ibiblio.org
>> 
>> a
>> écrit :
>> 
>>> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
>>>  wrote:
 
 
 except there is no issue, the download is just slow so why
 would
>> you
 fail?
 Hapoy to discuss a better solution but logging is a very satisfying
>> one.
>>> 
>>> If there is no issue, don't log it. If being slow is an issue
>>> (arguably it isn't) report it when it's slow enough to be an issue,
>>> and only then. Too many developer tools don't finish the job by
>>> accurately diagnosing and reporting on errors. Instead they throw up
>>> their hands and say, "Oops. Something went wrong. Here's an
>>> incomprehensible dump of 50% of everything that happened. Maybe 

Re: And while I'm on the subject of logging

[Kemal Soysal]

The logging discussion is well underway.
According to my experience with build management,
there has always been these contradicting requirements no logging to heaps of 
more logging in case of an error.
If the build seemed to run smoothly you were fooled by everything looking fine, 
unless you saw the output with -X -e.
Therefore our build pipeline always switched to full output.
Locally for the development build we just had info.

For combining these contradictions we decided to log into a file by providing 
the -l -, 
so the output is saved quicker on disk for local builds and is not blocked by 
the terminal 
(specially under windows with the small output buffer and sometimes someone 
accidentally marking a spot that blocks the process io), 
and with an adjacent check script we could assure that certain unwelcome 
situations could be detected.

From this experience… I would suggest to bring in a configurable log validator, 
that can be extended to specific needs, to judge the outcome of the build too.
Not everything of a green build is ok.
The custom validator can collect information about these problems and report 
them well.

These are my 2 cents or less,

Best Regards


> Am 22.02.2023 um 12:56 schrieb Guillaume Nodet :
> 
> I do agree that logging all downloads is unneeded, and I do agree that the
> hanging case can happen quite often and one needs to be informed.
> However, both goals are not conflicting, we just need to enhance the
> logger/downloader to:
>  * print a single statement that it starts downloading things
>  * if a download is too slow (for example, nothing has been received since
> a few seconds), log a warning message
>  * log a summary when the download finished (like "Downloaded 5 artifacts
> from central and yyy repositories")
> It should not be very difficult to detect stalled downloads.
> 
> Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau  a
> écrit :
> 
>> Eliotte I kind of fail to follow your reasoning because it literally means
>> don't log any info and just set default log level to ERROR which I don't
>> think will make anyone happy.
>> You also tend to think everything works all the time but network issues are
>> not work/fail kind of issue, the hanging case is really bothering and
>> downloading logs really help there when you can keep them.
>> Lastly downloads are not expected by maven after one build so being a bit
>> more verbose is not an issue and going outside the machine should likely
>> always be logged at the beginning these days.
>> 
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>> 
>> 
>> Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold 
>> a
>> écrit :
>> 
>>> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
>>>  wrote:
>>>> 
>>>> 
>>>> except there is no issue, the download is just slow so why would
>> you
>>>> fail?
>>>> Hapoy to discuss a better solution but logging is a very satisfying
>> one.
>>> 
>>> If there is no issue, don't log it. If being slow is an issue
>>> (arguably it isn't) report it when it's slow enough to be an issue,
>>> and only then. Too many developer tools don't finish the job by
>>> accurately diagnosing and reporting on errors. Instead they throw up
>>> their hands and say, "Oops. Something went wrong. Here's an
>>> incomprehensible dump of 50% of everything that happened. Maybe the
>>> thing that went wrong is in there somewhere. Maybe it isn't. You
>>> figure it out."
>>> 
>>> Imagine a compiler that instead of identifying the offending line of
>>> syntactically incorrect code simply printed every line of source code
>>> as it parsed it, twice. Would anyone put up with such a compiler or
>>> would the bug reports overflow the Github issue tracker? Why do we
>>> accept that level of error reporting in Maven downloads?
>>> 
>>> We shouldn't force people to do what computers can easily do. One of
>>> the things a computer can do is notice when one out of hundreds of
>>> dependencies is causing a problem, and blame  exactly that one
>>> artifact.
>>> 
>>> --
>>> Elliotte Rusty Harold
>>> elh...@ibiblio.org
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>>> 
>> 
> 
> 
> -- 
> 
> Guillaume Nodet


--
Kemal Soysal


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

skip execution behavior for a mojo

[Kemal Soysal]

Hi,

I am trying to understand the reason for the skip execution behavior not being 
implemented in the AbstractMojo class already.

If there is no specific reason, would Yous agree to introduce it with Maven 4.0 
or even back port to 3.x ?

Kemal
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org