Re: Less info please.

[Bernd Eckenfels]

I am afraid there is no good concept to get
only relevant output (it’s not trivial) but you
can use maven daemon I feel it compresses
the output better for interactive consumption.

In addition to that some plugins might be
especially bad (for your use case) - I would
communicate that to the plugin project it’s
nothing maven parent project has control over
in all cases.

And finally warnings should be actually
addressed. 

Gruß
Bernd

Arbol One wrote on 3. May 2024 12:32 (GMT +02:00):

> Debian 12
> NetBeans 21
> Apache Maven 3.8.7
> 
> Hello.
> 
> The Ant tool produces very little information regarding its work. On the 
> other hand, Maven displays lots and lots of output telling me what's 
> happening under the hood.
> I am not interested in so much data about what Maven does in the 
> background, all I need to know, for now, is that there are not errors 
> and what the compilation output is.
> 
> What can I do to make Maven display less data about what it does under 
> the hood?
> 
> Thanks in advance!
> 
> -- 
> */ArbolOne.ca/* Using Fire Fox and Thunderbird. ArbolOne is composed of 
> students and volunteers dedicated to providing free services to 
> charitable organizations. ArbolOne on Java Development is in progress [ í
> ]


Gruß
Bernd
— 
https://bernd.eckenfels.net

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

Re: Maven & Github codespaces

[Bernd Eckenfels]

Tommy Svensson wrote on 31. Mar 2024 14:52 (GMT +02:00):

> …I have old jars somewhere! I should clean my
> ~/.m2/repository! 

It should work regardless what you have on your local reponczche since it’s 
versioned. But other question how is that related to what’s in a fresh 
codespace? Something goes not check out. Or are you saying it does never work?

Gruß
Bernd
— 
https://bernd.eckenfels.netOops! My bad! I assumed that org.codehaus.plexus.utils.StringUtils was part of 
maven! I'm building Groovy code and org.codehaus... is where Groovy used to be, 
until CodeHaus closed down and Groovy moved to apache.org! I have old jars 
somewhere! I should clean my ~/.m2/repository! 

/Tommy
__
Tommy Svensson
to...@natusoft.se



Från: Tamás Cservenák 
Svara: Maven Users List 
Datum: 28 mars 2024 at 13:15:24
Till: Maven Users List 
Ämne:  Re: Maven & Github codespaces

Yes, it works! I just said a few emails ago that I am using Maven 3.9.6 on  
Java 21 since that Java was out.  

T  

On Thu, Mar 28, 2024 at 12:47 PM Tommy Svensson  wrote:  

> I can add that on my computer I can do "mvn wrapper:wrapper" to install  
> mvnw, and then build using that problems, but on github codespaces the  
> wrapper instalation fails due to the same "StringUtils" failure!  
>  
> Do maven support the higher number versions of the JDK ?  
>  
> __  
> Tommy Svensson  
> to...@natusoft.se (mailto:to...@natusoft.se)  
>  
> På 27 mars 2024 till 18:05:18, Mantas Gridinas (mgridi...@gmail.com  
> (mailto:mgridi...@gmail.com)) skrev:  
>  
> > Are you sure jdk21 is default on codespaces? An hour ago i cloned a java  
> > repository only to find that codespaces comes with 11 by default. Whats  
> > your output of java -version?  
> >  
> > Regardless, you can download your needed jdk from adoptium, and setup  
> both  
> > $PATH and $JAVA_HOME to point to the downloaded jdk just as you would on  
> > normal machine.  
> >  
> >  
> > On Wed, Mar 27, 2024, 19:01 Tommy Svensson  wrote:  
> >  
> > > Hello Maven users!  
> > >  
> > > I am having problem building with maven on a GitHub codespace!  
> > >  
> > > It complains about; Caused by: java.lang.ClassNotFoundException:  
> > > org.codehaus.plexus.util.StringUtils  
> > >  
> > > I believe this is due to only JD17 and JDK21 is available with JDK21  
> being  
> > > the default.  
> > >  
> > > My problem is that locally on my private machine it builds fine, but on  
> > > GitHub spaces I get:  
> > >  
> > > Caused by: java.lang.ClassNotFoundException:  
> > > org.codehaus.plexus.util.StringUtils  
> > > at  
> > >  
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
>   
> > > at  
> > >  
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
>   
> > > at  
> > >  
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
>   
> > > at  
> > >  
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
>   
> > >  
> > > The maven version is:  
> > > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)  
> > >  
> > > Is there any known solution for this combination / situation or is it  
> just  
> > > "forgett maven on GitHub codespaces" ?  
> > >  
> > > Best Regards,  
> > > Tommy Svensson  
> > > __  
> > > Tommy Svensson  
> > > to...@natusoft.se (mailto:to...@natusoft.se)  
> > >  
> > >  
>

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

Re: Independent verification of reproducible builds

[Bernd Eckenfels]

Hello,

Railean, Alexander wrote on 28. Mar 2024 15:36 (GMT +01:00):
> They need the details of my environment (e.g., OS, version of Java), but
> this information is not among the artifacts published on Maven Central. I
> was expecting the "buildinfo" file to be distributed too, but it is not
> the case. I did not find it in the repositories of various libraries which
> claim to offer reproducible builds.

I would say the process is not yet mature
Enough for that but following buildinfo 
Convention sounds like it’s custom.

For the time being I guess you have to dig
It up from mailing list - ideally release
announcement.

> [2] What is the recommended practice regarding outputTimestamp?

Personally I prefer having a fixed timestamp which is roughly in release order 
so that users can deduce age, branching relationships and fidelity.

That timestamp can come from buildinfo / commandline or embedded in the 
released source. If the source fixes the timestamp it should be a profile to 
make sure snapshot builds don’t inherit it.

Using 1 would be my second best option especially if this turns out to be a 
strong convention (used with salsa tooling and co)

In any case the tutorial should cover it.

Gruß
Bernd

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

Re: POM license guidance (and need for documentation/FAQ)

[Bernd Eckenfels]

Nils Breunese wrote on 27. Mar 2024 20:33 (GMT +01:00):

> That sounds like a good idea when the code is actually licensed under the
> “Companyname Commercial License”

No, in my case it’s not a existing license (or actually there are of course 
licenses for
the resulting product). But I use the name to make sure:

- „commercial“ keeps people from thinking it’s unrestricted (if
  they happen to get in contact with Pom or repo)
- companyname gives a namespace
- allows to be included in manifest

In the end this is mostly that SBOM and build-reports list all projects 
together.
(A vendor grouping would be better but I think normal maven reports don’t).

Not specifying a license has two problems, first it might inherit unwanted 
licenses
from parent, and secondly it makes it harder to find actual not yet documented
missing licenses.

Therefore I can only recommend to always use a common license even if those
Poms  and artifacts never are to be exposed to external participants.

Gruss
Bernd

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

Re: POM license guidance (and need for documentation/FAQ)

[Bernd Eckenfels]

I use name=„Companyname Commercial License“, 
url=„https://www.companyname.com/terms“, distribution=„manual“ but also think 
it would be good to have standard distribution and classifier for properitary 
code.

Nils Breunese wrote on 27. Mar 2024 20:02 (GMT +01:00):
> I personally omit the  element when there are no applicable
> licenses. But it sounds like you'd want to be able to distinguish between
> ’there are no applicable licenses’ and ’there may or may not be
> applicable licenses’?

Gruss
Bernd

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

Re: Configuring plugins by composition rather than inheritance

[Bernd Eckenfels]

Hello,

I think that’s a long-standing restriction of mavens Pom-model, not sure it can 
easily be solved. Spring boot (and other frameworks) did not make the situation 
easier with their parent requirement (but then again there is not much 
alternatives).

>From my experience it seems a good idea to get away from a strict „simple 
>company root“ requirement. (Due to release cycles it doesn’t do much for 
>unifying build jobs anyway).

Maven could improve with importing build/plugin sections like BOMs. I haven’t 
seen much talk about that in recent 4.0 discussions,

Having said that a consumer Pom goes a good distance to make the parents less 
relevant. (Especially licensing/orga matters)

Gruß
Bernd

Mantas Gridinas wrote on 5. Dec 2023 09:17 (GMT +01:00):

> In my current project i'm working we already have a parent POM that I
> should be inheriting from, but when trying to integrate the spring boot I
> come into an issue that I should inherit their super pom instead of using
> our own. For dependencies its pretty simple - you use the import scope,
> but
> what about plugins? I'm seeing some stackoverflow posts about the sameish
> issue from 11 years ago that the suggestion was to use tiles plugin. Was
> there any movement regarding this in the mean time?
> 
> As a workaround I currently have a dedicated springboot runtime module
> that
> includes a single entry point with respective annotations to start the
> application, and it directly inherits the spring boot super pom while
> importing our dependencies via the depencendy management block but having
> a
> submodule not inherit a parent module feels weird
> 


Gruß
Bernd
— 
https://bernd.eckenfels.net

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

Re: what javac is actually used?

[Bernd Eckenfels]

Hallo,

Dave Dyer wrote on 4. Dec 2023 08:27 (GMT +01:00):

> It seems odd to me for maven to have its own javac, 

It does not, when you use the compiler plugin in the default config it uses the 
Java compiler from the JDK you started maven with. It just uses the Tool API 
instead of the cli, but it’s basically same functionality.

You have either different JDKs or the settings are different. Most likely you 
did not set a release version, since maven does not default to the JDK version 
you are building with.

> For starters I'd like to convince maven to use one lf mine.

You can use toolchain and fork options, but I think you mostly need to use 
correct release switch I suspect.

https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html

https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html

Gruß
Bernd

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

Re: .sha256 artifact checksums on Central

[Bernd Eckenfels]

Michael Osipov wrote on 22. Nov 2023 17:18 (GMT +01:00):

> Look at this:
> https://repo.maven.apache.org/maven2/com/microsoft/sqlserver/mssql-jdbc/12.4.2.jre11/
> 
> Whatever they did, they did wrong.

Microsoft is responsive in their bug tracker, will let them know.

But how can you upload a incomplete submission to oss, is that a bug on 
sonatype?

Gruß
Bernd

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

Re: .sha256 artifact checksums on Central

[Bernd Eckenfels]

Bernd Eckenfels wrote on 21. Nov 2023 19:44 (GMT +01:00):
> Strange enough central did accept those, but seems to not support it with
> Remote Included Strategy (X- headers):

Now that I thought about it, another possible explanation: I think 
-Daether.checksums.algo=
rithms=SHA-256 is effectiv, all downloads WARN.

So I suspect maven with direct connections to Central use the synthetic SHA-1 
checksum
Headers and does never miss the .sha1 files. but with a proxy-repo in between 
it fails to do
that.

I guess I need to trace more interactions along those lines.
Will it somehow know not to request .sha256 or does my nexus just not mirror 
them?

For my testing convinience, do I need a dummy Pom or can I trigger the resolve 
with cli in exactly the same way?


Gruß
Bernd
— 
https://bernd.eckenfels.net

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

.sha256 artifact checksums on Central

[Bernd Eckenfels]

Hello,


I have noticed that Microsoft started to add .sha256 checksums to their POMs
instead of .sha1.

It looks like Maven Central accepts this, so is this a global policy change?


https://repo.maven.apache.org/maven2/com/microsoft/sqlserver/mssql-jdbc/12.4.1.jre11/mssql-jdbc-12.4.1.jre11.pom.sha1

https://repo.maven.apache.org/maven2/com/microsoft/sqlserver/mssql-jdbc/12.4.2.jre11/mssql-jdbc-12.4.2.jre11.pom.sha256


Strange enough central did accept those, but seems to not support it with
Remote Included Strategy (X- headers):


curl -I
https://repo.maven.apache.org/maven2/com/microsoft/sqlserver/mssql-jdbc/12.4.2.jre11/mssql-jdbc-12.4.2.jre11.pom

HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 19942
ETag: "61cb3f21b65ec7957c85f899a7f5cbc4"
Content-Type: text/xml
Last-Modified: Fri, 27 Oct 2023 02:53:09 GMT
X-Checksum-MD5: 61cb3f21b65ec7957c85f899a7f5cbc4
X-Checksum-SHA1: 70d487ee6dd908c60527158246d03baf18269511
Via: 1.1 varnish, 1.1 varnish
Accept-Ranges: bytes
Date: Tue, 21 Nov 2023 18:30:23 GMT
Age: 1531300
X-Served-By: cache-iad-kiad7000176-IAD, cache-fra-eddf8230077-FRA
X-Cache: HIT, HIT
X-Cache-Hits: 3, 1
X-Timer: S1700591424.912411,VS0,VE1

In any case Maven 3.8 seems to not like it, it prints:


Warning: Could not validate integrity of download from
https://repo.maven.apache.org/maven2/com/microsoft/sqlserver/mssql-jdbc/12.4.2.jre11/mssql-jdbc-12.4.2.jre11.pom

org.eclipse.aether.transfer.ChecksumFailureException:
  Checksum validation failed, no checksums available
  at org.eclipse.aether.internal.impl.AbstractChecksumPolicy.onNoMoreChecksums
(AbstractChecksumPolicy.java:64)
  at org.eclipse.aether.connector.basic.ChecksumValidator.validate
(ChecksumValidator.java:107)
  at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
(BasicRepositoryConnector.java:460)
  at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
(BasicRepositoryConnector.java:364)
  at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
(RunnableErrorForwarder.java:75)
  at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
(BasicRepositoryConnector.java:628)
  at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:262)
  at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
(DefaultArtifactResolver.java:514)
  ...

This happens with 3.8.8 in Github Action: (Example for that, here Line 19:)

https://github.com/seeburger-ag/bis-resources/actions/runs/6947706560/job/18902089277?pr=20#step:4:20

but not sure if this is somehow GH cache related (since there are no downloads)


With 3.9.4 directly, the warning seems to not happen - even when I specify
mvn -Daether.checksums.algorithms=SHA-1 to a empty local repo I get no
warning.

When I use the same version through a nexus 3 mirror, it does fail.


So questions:

- is this a policy change in central or does central neglect to enforce
sha1?

- does central need to include a sha2 header?

- since when does maven resolver test for both?

- is it still controlled with aether.checksums.algorithms?

- Does anybody know if nexus3 can support that?


Gruss
Bernd
-- 
https://bernd.eckenfels.net

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

Re: Can the jar plugin respect .gitignore?

[Bernd Eckenfels]

Hello,

Joseph Kesselman wrote on 11. Nov 2023 17:27 (GMT +01:00):
> ... Right. I was thinking specifically about source assembly, where a good
> initial approximation is to include the same files checked into git.

If you stick to the maven way, this is pretty trivial: you only need to exclude 
the target/ directory - or only include the src/ directory which is common for 
-src artifacts. I fully agree, don’t try to mold maven projects in a custom 
structure… it can be done to some extend, but it will not make you happy.

Gruß
Bernd
— 
https://bernd.eckenfels.net

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

Re: Are "M" versions of Surefire plugin pre-release?

[Bernd Eckenfels]

Those M version schemes are quite annoying, but the download site lists M7 as 
„current stable“ and since ASF projects are not supposed to provide pre-release 
archives anyway I would say go for  it. Especially if you need 3.x.x 
API/Format/Features.

However, the version Progression on this page suggests otherwise: 
https://maven.apache.org/surefire/maven-surefire-plugin/history.html - maybe it 
should give an ETA or the number of upcoming milestones…

BTW the release notes link on the m-s-p subsite is broken.
BTW in maven numbing the -M qualifiers will sort before the unqualified 3.0.0 
version.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Олег АндреичЪ 
Gesendet: Tuesday, September 6, 2022 7:54:40 AM
An: users@maven.apache.org 
Betreff: Are "M" versions of Surefire plugin pre-release?

Hello

Are "M" versions of the Surefire plugin (like 3.0.0-M7) pre-release?

Should one use "M" versions or the latest version without "M" (2.22.2)?

Usually, I see "M" as a "Milestone," which is pre-release, but I want to be
sure this time.

Unfortunately, I haven't found info about my question in docs and mailing
list. In case there is a prior discussion about this, please point me to it.

Re: Maven multiple requests transaction

[Bernd Eckenfels]

Hello,

While some repository managers have additional logic (like staging repos where 
the user can review and integrate the result of single/multiple uploads) the 
protocol is not particular transactional. It’s a bunch of single file uploads 
and the Repo managers are more or less smart to do that in a consistent way.

This includes correlating and checking checksums, signatures and pom file. Most 
probably the most important part is the meta data file for that, uploaded last.

(Simple Repo managers rely on the merging of existing versions by wagon Repo 
merge)

https://maven.apache.org/ref/3.8.4/maven-repository-metadata/index.html

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: amruta kawade 
Gesendet: Saturday, July 30, 2022 4:55:44 AM
An: users@maven.apache.org 
Betreff: Maven multiple requests transaction

Hi

I wanted to understand if there is any marker or handshake by which we will
get to know how many files will be uploaded in maven deploy project.

as maven uploads a single file at a time and there is no indication of how
many files will be uploaded once you receive a request for any particular
release version. how will the maven repository understand that all file
requests are received ? how many pending file requests are there.

Also how does the central maven repository handle this scenario ?

Thanks,
Amruta Kawade

Re: java.lang.ClassNotFoundException: com.google.common.base.Preconditions

[Bernd Eckenfels]

The problem is how your app (or the memory measuit lib) is loading classes. It 
does not seem to use the classloader from your application main class (which is 
the one maven provides prepared with your dependencies).

 Maybe it helps to set the thread context classloader with the app classloader 
(not sure if the maven plugin does that or not). But it might just not be 
possible to make your external code use this classloader, in that case starting 
a stand alone java might be easier.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Siddharth Jain 
Gesendet: Monday, July 25, 2022 2:13:30 AM
An: Maven Users List 
Betreff: Re: java.lang.ClassNotFoundException: 
com.google.common.base.Preconditions

could you explain this to me? we have tried running without configuring any
agent
mvn exec:java -X -Dexec.mainClass=com.example.App

and the exception is still there. and maven:exec works for other projects.

On Sun, Jul 24, 2022 at 1:19 PM Bernd Eckenfels 
wrote:

> Since exec:java executes in the running JVM it does not reconfigure the
> (boot)classpath but provides a configured classloader. It looks like the
> measuring agent does not like that. In that Case you need either
> exec:exec or a plug-in for that purpose.
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Siddharth Jain 
> Gesendet: Sunday, July 24, 2022 8:46:04 PM
> An: users@maven.apache.org 
> Betreff: java.lang.ClassNotFoundException:
> com.google.common.base.Preconditions
>
> we are running into the dreaded ClassNotFoundException in a project. Here
> is the setup. Using JDK 11 and Maven 3.8.5. Trying to create sample test
> project that uses memory-measurer
> <https://github.com/DimitrisAndreou/memory-measurer> to measure memory.
> First we mvn packaged and installed the memory-measurer artifact into M2
> repository. Then we created a test project in which we add dependency on
> memory-measurer. The project compiles fine but gives error on running (we
> run using mvn exec:java plugin):
>
> Caused by: java.lang.ClassNotFoundException:
> com.google.common.base.Preconditions
> at jdk.internal.loader.BuiltinClassLoader.loadClass
> (BuiltinClassLoader.java:581)
> at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass
> (ClassLoaders.java:178)
> at java.lang.ClassLoader.loadClass (ClassLoader.java:521)
> at objectexplorer.InstrumentationGrabber.checkSetup
> (InstrumentationGrabber.java:20)
> at objectexplorer.InstrumentationGrabber.instrumentation
> (InstrumentationGrabber.java:25)
> at objectexplorer.MemoryMeasurer. (MemoryMeasurer.java:24)
> at com.example.App.main (App.java:20)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:254)
> at java.lang.Thread.run (Thread.java:834)
>
>
> What have we tried? Here is output of mvn dependency:build-classpath:
>
>
> /Users/xxx/.m2/repository/objectexplorer/memory-measurer/1.0-SNAPSHOT/memory-measurer-1.0-SNAPSHOT.jar:/Users/xxx/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/xxx/.m2/repository/com/google/guava/guava/19.0/guava-19.0.jar:/Users/xxx/.m2/repository/junit/junit/4.11/junit-4.11.jar:/Users/xxx/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
>
> we unpacked guava-19.0.jar in a temp directory and can see
>
> -rw-r--r--  1 xxx  staff  5252 Aug 25  2014
> /Users/xxx/temp/com/google/common/base/Preconditions.class
>
> in it. The next thing we tried is printing
> System.getProperty("java.class.path"). This gives:
>
> /Library/Downloads/apache-maven-3.8.5/boot/plexus-classworlds-2.6.0.jar
>
> above does not contain the classpath calculated by mvn dependency plugin.
> Question 1: Why?
>
> Question 2: When we printed System.getProperty("java.class.path") in
> another working project we got same result. It seems the classpath when
> using mvn exec:java is always
>
> /Library/Downloads/apache-maven-3.8.5/boot/plexus-classworlds-2.6.0.jar
>
> How is the other project able to load classes from above classpath? Why is
> mvn
> exec:java not using correct classpath? How do we fix this?
>
>
> Here <https://gist.github.com/siddjain/5d2afee15a756b689c5231488e6c29be>
> is
> output of maven with the -X switch. You can see following debug info:
>
>
> [DEBUG] Adding project dependency artifact: memory-measurer to classpath
> [DEBUG] Adding project dependency artifact: jsr305 to classpath
> *[DEBUG] Adding project dependency artifact: guava to classpath* here
> <https://gist.github.com/siddjain/2ceaca405acdaf460df94a064e07c17f> is
> pom.xml. would be great if someone could help us out.
>

Re: java.lang.ClassNotFoundException: com.google.common.base.Preconditions

[Bernd Eckenfels]

Since exec:java executes in the running JVM it does not reconfigure the 
(boot)classpath but provides a configured classloader. It looks like the 
measuring agent does not like that. In that Case you need either exec:exec or a 
plug-in for that purpose.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Siddharth Jain 
Gesendet: Sunday, July 24, 2022 8:46:04 PM
An: users@maven.apache.org 
Betreff: java.lang.ClassNotFoundException: com.google.common.base.Preconditions

we are running into the dreaded ClassNotFoundException in a project. Here
is the setup. Using JDK 11 and Maven 3.8.5. Trying to create sample test
project that uses memory-measurer
 to measure memory.
First we mvn packaged and installed the memory-measurer artifact into M2
repository. Then we created a test project in which we add dependency on
memory-measurer. The project compiles fine but gives error on running (we
run using mvn exec:java plugin):

Caused by: java.lang.ClassNotFoundException:
com.google.common.base.Preconditions
at jdk.internal.loader.BuiltinClassLoader.loadClass
(BuiltinClassLoader.java:581)
at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass
(ClassLoaders.java:178)
at java.lang.ClassLoader.loadClass (ClassLoader.java:521)
at objectexplorer.InstrumentationGrabber.checkSetup
(InstrumentationGrabber.java:20)
at objectexplorer.InstrumentationGrabber.instrumentation
(InstrumentationGrabber.java:25)
at objectexplorer.MemoryMeasurer. (MemoryMeasurer.java:24)
at com.example.App.main (App.java:20)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:254)
at java.lang.Thread.run (Thread.java:834)


What have we tried? Here is output of mvn dependency:build-classpath:

/Users/xxx/.m2/repository/objectexplorer/memory-measurer/1.0-SNAPSHOT/memory-measurer-1.0-SNAPSHOT.jar:/Users/xxx/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/xxx/.m2/repository/com/google/guava/guava/19.0/guava-19.0.jar:/Users/xxx/.m2/repository/junit/junit/4.11/junit-4.11.jar:/Users/xxx/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar

we unpacked guava-19.0.jar in a temp directory and can see

-rw-r--r--  1 xxx  staff  5252 Aug 25  2014
/Users/xxx/temp/com/google/common/base/Preconditions.class

in it. The next thing we tried is printing
System.getProperty("java.class.path"). This gives:

/Library/Downloads/apache-maven-3.8.5/boot/plexus-classworlds-2.6.0.jar

above does not contain the classpath calculated by mvn dependency plugin.
Question 1: Why?

Question 2: When we printed System.getProperty("java.class.path") in
another working project we got same result. It seems the classpath when
using mvn exec:java is always

/Library/Downloads/apache-maven-3.8.5/boot/plexus-classworlds-2.6.0.jar

How is the other project able to load classes from above classpath? Why is mvn
exec:java not using correct classpath? How do we fix this?


Here  is
output of maven with the -X switch. You can see following debug info:


[DEBUG] Adding project dependency artifact: memory-measurer to classpath
[DEBUG] Adding project dependency artifact: jsr305 to classpath
*[DEBUG] Adding project dependency artifact: guava to classpath* here
 is
pom.xml. would be great if someone could help us out.

Re: How to tell maven to use https instead of http...

[Bernd Eckenfels]

Besides the already suggested maven version update, did you also check your 
~/.m2/settings.xml?

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Stefano Fornari 
Gesendet: Sunday, June 19, 2022 7:11:27 PM
An: Maven Users List 
Betreff: How to tell maven to use https instead of http...

I am trying to create a project from an archetype:

mvn archetype:generate \
-DarchetypeGroupId=org.openjfx \
-DarchetypeArtifactId=javafx-archetype-simple \
-DarchetypeVersion=0.0.3 \
-DgroupId=org.openjfx \
-DartifactId=sample \
-Dversion=1.0.0 \
-Djavafx-version=17.0.1


But I am getting the following error:

rg.apache.maven.wagon.TransferFailedException: Failed to transfer file:
http://repo1.maven.org/maven2. Return code is: 501 , ReasonPhrase:HTTPS
Required.

Shouldn't maven central be hardcoded in the apache-maven package? How can I
fix it?

Many thanks in advance.

Ste

Re: How to retrieve target folder or jar paths from multi-module Maven project

[Bernd Eckenfels]

The Maven Help Plugin has some functions, including printing evaluated project 
parameters.


RESULT=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)

https://maven.apache.org/plugins/maven-help-plugin/evaluate-mojo.html


--
http://bernd.eckenfels.net

Von: Laurian Angelescu 
Gesendet: Tuesday, June 7, 2022 5:43:26 PM
An: users@maven.apache.org 
Betreff: How to retrieve target folder or jar paths from multi-module Maven 
project

Is it possible to invoke *mvn* on the command line to output either 1) the
paths to all target folders where jars get packaged or 2) the file paths of
the jars themselves?

For example, in a multi-module project like
https://github.com/apache/httpcomponents-core.git, I would like to invoke:

*mvn *

and have output to standard out:

//httpcore5/target/httpcore5-5.2-beta1.jar
//httpcore5-h2/target/httpcore5-h2-5.2-beta1.jar
...
etc.

I want to essentially be able to get a list of the JARs created in *any *Maven
multimodule project.

Re: Kubernetes Build Environment

[Bernd Eckenfels]

Hello,

Well there are so many plugins, so I don’t know what would be enough. Hopefully 
somebody else would have a few recommendations.

And also starting test classes or groovy scripts from Maven Invoker could be 
considered pure Maven. However I would not say that credential management, 
workflows, orchestration and native applications are Mavens forté. And from my 
experience in this area you safe time and gain reliability/automation if you 
don’t try to force it into mavens structure.

BTW i just noticed that JKube really seems to have excellent APIs for stuff 
like building images, so thank you for the hint :) (i Wonder what part works 
without an docker daemon, will have to try this. Docker files are just not very 
flexible for things like repeatable builds and optimized layers (not even with 
builtkit - it seems)

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Philipp Kraus 
Gesendet: Monday, June 6, 2022 7:47:34 PM
An: Maven Users List 
Betreff: Re: Kubernetes Build Environment



> Am 06.06.2022 um 05:55 schrieb Bernd Eckenfels :
>
> do you need to test K8s or just have some external containers to set up, 
> maybe using Testcontainers with Docker APi is an alternative? (Advantage is 
> you can simpler test it locally)

Yes I’m using TestContainers for some test, but here I would like to focus on a 
full test-case of the whole system, so interaction between all components

>
> Another alternative is to use a CI pipeline script/system instead of 
> orchestrating it in maven - at least if there is no plugin which does what 
> you need, instead from junit/testng (IT) test cases, using the kubernetes or 
> f8 client might also be an option.

Yes this sound something what is possible, I would like to do some 
stress-testing with JMeter and also some integration testing, so I’m think 
about Kubernetes KinD within the CI pipeline. But so you would like to suggest 
to use Maven to build the artifact
And run it in a Kubernetes cluster via some CI pipeline scripts.

So based on your answer there is no pure Maven solution for this testing?

Thanks for the ideas

> 
> Von: Philipp Kraus 
> Gesendet: Monday, June 6, 2022 5:38:58 AM
> An: users@maven.apache.org 
> Betreff: Kubernetes Build Environment
>
> Hello,
>
> I need some idea how to solve this issue. I have got a MultiMaven project, 
> which has got multiple web services. Each service will be run later in a 
> container in Kubernetes.
> I have found this plugin 
> https://www.eclipse.org/jkube/docs/kubernetes-maven-plugin to build 
> everything, but I would like to get integration testing within the Kubernetes 
> environment,
> Because all services has got a Kafka connection and I would like to run some 
> complex integration test directly from the Maven build.
>
> Can you give me some ideas how to do it?
>
> Thanks a lot


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

Re: Kubernetes Build Environment

[Bernd Eckenfels]

do you need to test K8s or just have some external containers to set up, maybe 
using Testcontainers with Docker APi is an alternative? (Advantage is you can 
simpler test it locally)

 Another alternative is to use a CI pipeline script/system instead of 
orchestrating it in maven - at least if there is no plugin which does what you 
need, instead from junit/testng (IT) test cases, using the kubernetes or f8 
client might also be an option.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Philipp Kraus 
Gesendet: Monday, June 6, 2022 5:38:58 AM
An: users@maven.apache.org 
Betreff: Kubernetes Build Environment

Hello,

I need some idea how to solve this issue. I have got a MultiMaven project, 
which has got multiple web services. Each service will be run later in a 
container in Kubernetes.
I have found this plugin 
https://www.eclipse.org/jkube/docs/kubernetes-maven-plugin to build everything, 
but I would like to get integration testing within the Kubernetes environment,
Because all services has got a Kafka connection and I would like to run some 
complex integration test directly from the Maven build.

Can you give me some ideas how to do it?

Thanks a lot

Re: Determine Maven Dependencies after a build

[Bernd Eckenfels]

Hello,

I think you can’t publish ranges to central, but yes if a dependency has a 
range each built will resolve the Version new, and unless there is a mother 
dependency fixing the version you get the latest one in that range from your 
repo.

As others said, just don’t use ranges.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Creager, Greg 
Gesendet: Thursday, April 14, 2022 5:37:21 PM
An: Maven Users List 
Betreff: RE: Determine Maven Dependencies after a build

Another question, if the published pom has a range:
Published pom:

   com.hp.cp.dfe.shared
common-types
[1.0,1.1) 



Does that mean when another maven build that depends on this will select the 
latest available common-types in that range, not the one that was used for that 
build? (my hunch is yes, constant moving target)

-Original Message-
From: Nils Breunese 
Sent: Thursday, April 14, 2022 2:01 AM
To: Maven Users List 
Subject: Re: Determine Maven Dependencies after a build

Alexander Kriegisch  wrote:

> A personal note: I am trying to keep my hands off version ranges. I am
> not sure the assumed flexibility is worth the trouble of using it and
> running into the same issues as you. It also potentially creates a
> huge matrix of possible dependency version combinations which might or
> might not play nice with each other. How can you ensure to run your
> tests on all of them? Sometimes, there is a bug which affects you in
> 2.5.3, but not in 2.5.2, and quickly fixed in 2.5.4. Maybe you did or
> did not notice that it even exists. Then suddenly, someone uses the
> buggy version, and the software does not work despite green tests.

I would indeed also recommend to not use version ranges, and using a tool like 
Dependabot or Renovate to keep your dependencies up-to-date.

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


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

Re: CVE-2022-22963 and CVE-2022-22965

[Bernd Eckenfels]

Hello Donnel,

We need you to do your own research, the Apache Open Source Project Maven is 
not “your vendor” and also not related with Spring. How should “we” know what 
and how you are using it?

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: DONNELL M GARRETT 
Gesendet: Freitag, April 8, 2022 9:25 PM
An: users@maven.apache.org 
Betreff: CVE-2022-22963 and CVE-2022-22965

On March 31, 2022 a pair of significant vulnerabilities were identified in the 
Java Spring Framework which would allow an attacker to execute malicious code.

  *   CVE-2022-22963 - https://tanzu.vmware.com/security/cve-2022-22963
  *   CVE-2022-22965 - https://tanzu.vmware.com/security/cve-2022-22965

It is critical for all of our vendors to determine if their software is 
impacted so that remediation steps can be taken.  We need your company to 
respond to the following questions immediately:


  *   Is your product impacted by CVE-2022-22963 or CVE-2022-22965?
  *   Is your product built on Java?
  *   Does your product depend on the Spring Cloud Function project?  If so, 
what version?
  *   Does your product depend on Spring Framework?  If so, what version?
  *   Does the product require JDK 9 or higher?
  *   Does the product have a dependency on spring-webmvc?
  *   Does the product have a dependency on spring-webflux?

Re: How can I tell what value of "maxmem" the maven-compiler-plugin is using by default?

[Bernd Eckenfels]

If you don’t provide the fork=true parameter then javac will be started inline 
and no heap settings are applicable.

Beside that the debug (-X) output is correctly showing you the expanded values, 
if the property is not expanded it was not specified.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: KARR, DAVID 
Gesendet: Friday, April 1, 2022 8:02:37 PM
An: Maven Users List 
Betreff: How can I tell what value of "maxmem" the maven-compiler-plugin is 
using by default?

I noticed that we have one build that is trying to compile so many files that 
it is running out of memory in the maven-compiler-plugin execution.  I see that 
I can set the "maxmem" property in that plugin's configuration.  What would be 
nice to know is what the default value is.  I thought that perhaps "mvn -X" 
would tell me that, but that only tells me that the default value is 
"${maven.compiler.maxmem}".  That doesn't help me.  How can I get the default 
value of this property, or any particular property, from a given pom?

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

Re: How to produce a pom.xml that is guaranteed to fail, with specific error messages

[Bernd Eckenfels]

Syntax error sounds like the best thing - using a enforcer plugin to produce an 
error will not be possible in arbritary locations.

And of course you also can add a commit or review hook to block template 
snippets to be committed.

Not sure if any of that is required if you have a commit review process.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: David Karr 
Gesendet: Wednesday, March 30, 2022 7:46:35 PM
An: Maven Users List 
Betreff: How to produce a pom.xml that is guaranteed to fail, with specific 
error messages

I work in a large company on a large project with hundreds of services,
most of which are Java Maven projects.  We have an "archetype" we use for
new services. It doesn't use the Maven archetype process.  There are
particular areas in the pom.xml that is generated that really need to be
modified by the developer to reflect their actual application.

We could certainly put comments in the template that tell the developer
what sort of changes need to be made, but I wonder if there's any way we
can ensure that they notice and handle particular areas of the pom.xml.
Just generating a comment with directions isn't enough.  I wish there was
some way I could ensure that running the build would fail with a specific
error message if they haven't dealt with each area. I suppose I could
create an XML syntax error in each area that should be addressed, with text
near the error that explains what to do, but that seems like a bit of a
hack, although it may be the only strategy I can use.  Is there a cleaner
way to do this sort of thing that I'm not aware of?

Re: Can anyone confirm the behavior of updatePolicy never for repositories?

[Bernd Eckenfels]

-U works on release artifacts as well. Alternatively you can delete the version 
(either manually in the filesystem or with a maven 
dependency:purge-local-repository).

I think the Never-policy was not meant to deal with errors, it is more about 
immutability of the actual releases.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Shipp, Scott 
Gesendet: Friday, March 25, 2022 5:03:03 PM
An: users@maven.apache.org 
Betreff: Can anyone confirm the behavior of updatePolicy never for repositories?

Hi fellow Maven users,

I have used Maven for 10 years or more and I’m writing with a first. I have a 
project which was set up in Jenkins with a settings.xml that has updatePolicy 
set to “never” for a certain repository.

I have experienced that when Maven 3.3.9 fails to resolve an artifact for any 
reason (could be connection error, the artifact is not there at the time, or 
any other reason) the first build notes that it will “cache the failure” as 
follows:


Failure to find org.example:foo:jar:0.0.1-RELEASE in 
https://example.org/foo/repository/ was cached in the local repository, 
resolution will not be reattempted until the update interval of foo.repository 
has elapsed or updates are forced



Subsequent builds then always fail with log output similar to the below, 
regardless of whether the connection can be re-established or the dependency is 
now available:


14:01:07 [ERROR] Failed to execute goal on project foo: Could not resolve 
dependencies for project org.example:foo:jar:0.0.1-RELEASE: Failed to collect 
dependencies for org.example:foo:jar:0.0.1-RELEASE: Failed to read artifact 
descriptor for org.example:foo:jar:0.0.1-RELEASE: Could not find artifact 
org.example:foo:jar:0.0.1-RELEASE in foo.repository 
(https://example.org/foo/repository/) ….


Unfortunately, I believe the -U flag cannot be used here as it applies to 
SNAPSHOT dependencies only. An experiment of passing -U further bore this out 
and did not resolve the issue.

My questions here are:


  1.  Is this the expected behavior for “never” value of updatePolicy?
  2.  If so, what purpose is this “never” setting meant to serve? What is a 
valid use case?
  3.  Is there any way to force the update for a RELEASE artifact when 
updatePolicy is “never”?

Scott

Re: Strategies for automatically fixing local maven repo corruption?

[Bernd Eckenfels]

You should avoid concurrent builds on a local Repo. Either use a “per worker” 
Repo (all good CI servers should support that, but you can also do it by hand 
command line option) or use a Container build process.

There is also a locking scheme for Maven now, but I would start with Seperate 
repos.

And also clean them up at least once a week or more often, that also helps 
against other corruptions and reproducibility issues.

You always should have a caching mirror to make this less impactful.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: David Karr 
Gesendet: Wednesday, March 23, 2022 11:11:19 PM
An: Maven Users List 
Betreff: Strategies for automatically fixing local maven repo corruption?

Our enterprise has builds for a couple of hundred services running many
times a day, on a set of Jenkins build nodes, most of which are Maven
builds.The builds use a settings.xml that doesn't override the
"localRepository", so it will use a local repository on the build node that
is used by all builds.

We often run into weird build errors like "Could not find artifact", for
artifacts that I can clearly show are available in our intranet repository.
In every one of those cases, when we inspect the directory in the local
maven repo on that build node, we see that it's "corrupted", in that
perhaps the pom file is there, but the jar file is missing.

We fix these errors by simply removing the directory where the key files
are missing, then rerun the build, which correctly downloads the artifact,
and the build succeeds.  We often have to do this on multiple build nodes,
although I don't have visibility to that (not on ops team), so I don't
really know if the same artifact gets corrupted on multiple build nodes at
the same time. I doubt that.

I wish there was some way that we could either prevent some of these
incidents, or somehow automatically fix them (by removing the corrupted
directory). The latter seems like it's in the realm of possibilities, but
it would have to be constantly scanning the entire repository, looking at
leaf directories that haven't changed in several minutes, and somehow
verifying the "sanity" of the contents from a very limited perspective.

Is there anything we can do to improve this situation?

Re: Want to understand the .dumpstream file contents

[Bernd Eckenfels]

Hello,

Sounds like the default console logger for the JUL root gets the events and 
writes them to stdout.

Did you try to use an anonymous logger or specify setUseParentHandler(false) on 
your trace logger?

Doesn’t sound very surefire or maven specific, that would also happen in a 
stand alone execution.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Laurian Angelescu 
Gesendet: Friday, March 11, 2022 3:56:16 PM
An: users@maven.apache.org 
Betreff: Want to understand the .dumpstream file contents


I've built a trivial Java agent that uses java.util.logging.Logger and a 
FileHandler to trace out the program into a log file. I've attached a log file 
produced as a sample: agent_03112022_064424.log.

The point is to run some tests under instrumentation. To do so I run:

mvn test -DargLine="-javaagent:C:\JARS\agent.jar" on a target project, also 
built with Maven, to run a test suite under instrumentation. After completion, 
the folder /target/surefire-reports contains file 
2022-03-11T07-01-03_983.dumpstream which contains similar information to the 
agent_03 log file.

I want to understand why the surefire dumpstream contains the traces I am 
outputting using the logger in my agent code (to the agent_03 file)? The agent 
is a self-contained JAR and is outputting to its own file. The surefire plugin 
is running tests on a completely different package.

The second question is how do I turn it off?

Re: swap space not being used

[Bernd Eckenfels]

Unless you use large pages java will automatically use all available virtual 
memory, maven does not change that.

Typically maven will start java launcher with default memory size, so maybe 
your problem is not related to your limited ram but a general java config? What 
is the exact memory error you get?

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Nathan Fisher 
Gesendet: Friday, March 4, 2022 5:53:45 PM
An: Maven Users List 
Betreff: Re: swap space not being used

Is there a reason you wouldn't use a CI service like GitHub actions or
similar and then deploy the Artifact to the VPS? Or are you using the VPS
as a build server?

On Fri, Mar 4, 2022 at 10:25 AM John Rinehart 
wrote:

> I'm trying to build an application (dbeaver) on a VPS with limited physical
> resources (~1GiB of RAM). To compensate I've set up 8GiB of swap space.
> Trying to build dbeaver always results in a Java heap space error. None of
> my swap is being used, though. I already tried to change the kernel
> swappiness values to fix this, but it hasn't. Once the physical memory is
> exhausted the build fails.
>
> How can I ensure that swap space is used for maven builds?
>
> -- John Rinehart
>


--
Nathan Fisher
Computer Systems Analyst - Infrastructure Engineering Team
Instana Inc.

Re: Possible protocol error, handshake_error when using Maven

[Bernd Eckenfels]

The checksum incorrect can be caused by hardware features or truncated packets, 
it is normally not a sign you have to care about. You can specify -K to ignore 
it.

Try tcpdump -nnpvKX to get the packet content. But I would write the capture to 
a file and use Wireshark to visualize the tls handshake (or TLS-hello-dump or 
ssldump).

But the java debug trace should be much easier to read it will show the TLS 
flags in text.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: christopher.mil...@gd-ms.com 
Gesendet: Monday, February 21, 2022 11:25:46 PM
An: Maven Users List 
Betreff: RE: Possible protocol error, handshake_error when using Maven


I did a tcpdump, but felt it was off topic to post it here.  But since you 
brought it up, this is what command I used and the output when I ran the 
following command:  java GetUrls 
https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom

sudo tcpdump -ni eno1 "tcp port 443 and (tcp[((tcp[12] & 0xf0) >> 2)] = 0x16)" 
-vv
[sudo] password for millerc:
tcpdump: listening on eno1, link-type EN10MB (Ethernet), capture size 262144 
bytes
14:24:28.325528 IP (tos 0x0, ttl 64, id 2230, offset 0, flags [DF], proto TCP 
(6), length 297)
10.XX.XXX.XXX.52022 > 146.75.36.215.https: Flags [P.], cksum 0x8708 (incorrect 
-> 0xb913), seq 1440532052:1440532297, ack 2840419613, win 229, options 
[nop,nop,TS val 1152993612 ecr 2048890113], length

I see incorrect entry.



-Original Message-
From: Bernd Eckenfels 
Sent: Monday, February 21, 2022 3:36 PM
To: Maven Users List 
Subject: Re: Possible protocol error, handshake_error when using Maven


External E-mail --- CAUTION: This email originated from outside GDMS. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

The exception means that the other side closed the connection with an alert 
message. So it is a bit hard to say why it did that (without looking in the 
server logfile).

However the normal reasons for that is only missing agreement on protocol or 
cipher (not certificates).

There can now be 2 problems, one is that you are not connecting to the correct 
server but maybe a firewall or proxy appliance. The other option is that your 
client (your JSSE client in Java runtime) is not supporting the usual ciphers 
and protocols. There could be a number of reasons (maybe FIPS hardening or 
modified jcl or net.properties or security.properties).

I would turn on the verbose JSSE debug messages or do a tcpdump. Both should 
show you what the client is suggesting for protocol and ciphers in the 
ClientHello message. (If those look fine you need to look at the other side).

Try java -Djavax.net.debug=all GetUrl

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: christopher.mil...@gd-ms.com 
Gesendet: Monday, February 21, 2022 8:32:59 PM
An: Maven Users List 
Betreff: RE: Possible protocol error, handshake_error when using Maven


Sorry for the late reply, I'm still troubleshooting this and went back and 
re-read what was written and now understand it.

I'm still getting handshake_failure when running the following command:

[cmiller@gungan java]$ java GetUrls 
https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom
Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received fatal 
alert: handshake_failure
at sun.security.ssl.Alert.createSSLException(Alert.java:131)
at sun.security.ssl.Alert.createSSLException(Alert.java:117)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:311)
at sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)
at sun.security.ssl.TransportContext.dispatch(TransportContext.java:185)
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:152)
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1392)
at 
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1300)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:435)
at 
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at 
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:197)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1570)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1498)
at 
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at 
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:352)
at GetUrls.main(GetUrls.java:10)


For the sake of troubleshooting, I've also done the following.  Upgraded the 
Red Hat package ca-certificates to 2021.2.50 and still have the same issue.

For Java, 

Re: Possible protocol error, handshake_error when using Maven

[Bernd Eckenfels]

The exception means that the other side closed the connection with an alert 
message. So it is a bit hard to say why it did that (without looking in the 
server logfile).

However the normal reasons for that is only missing agreement on protocol or 
cipher (not certificates).

There can now be 2 problems, one is that you are not connecting to the correct 
server but maybe a firewall or proxy appliance. The other option is that your 
client (your JSSE client in Java runtime) is not supporting the usual ciphers 
and protocols. There could be a number of reasons (maybe FIPS hardening or 
modified jcl or net.properties or security.properties).

I would turn on the verbose JSSE debug messages or do a tcpdump. Both should 
show you what the client is suggesting for protocol and ciphers in the 
ClientHello message. (If those look fine you need to look at the other side).

Try java -Djavax.net.debug=all GetUrl

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: christopher.mil...@gd-ms.com 
Gesendet: Monday, February 21, 2022 8:32:59 PM
An: Maven Users List 
Betreff: RE: Possible protocol error, handshake_error when using Maven


Sorry for the late reply, I'm still troubleshooting this and went back and 
re-read what was written and now understand it.

I'm still getting handshake_failure when running the following command:

[cmiller@gungan java]$ java GetUrls 
https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom
Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received fatal 
alert: handshake_failure
at sun.security.ssl.Alert.createSSLException(Alert.java:131)
at sun.security.ssl.Alert.createSSLException(Alert.java:117)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:311)
at sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)
at sun.security.ssl.TransportContext.dispatch(TransportContext.java:185)
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:152)
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1392)
at 
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1300)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:435)
at 
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at 
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:197)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1570)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1498)
at 
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at 
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:352)
at GetUrls.main(GetUrls.java:10)


For the sake of troubleshooting, I've also done the following.  Upgraded the 
Red Hat package ca-certificates to 2021.2.50 and still have the same issue.

For Java, there is a UI Control Panel, where I unchecked both TLS 1.0 and 1.1 
and still having the same issue.

Thanks again to everyone for helping with this.

-Original Message-----
From: Bernd Eckenfels 
Sent: Friday, February 4, 2022 2:02 PM
To: Maven Users List 
Subject: Re: Possible protocol error, handshake_error when using Maven


External E-mail --- CAUTION: This email originated from outside GDMS. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

Yes that's expected. What does the next command print.


--
http://bernd.eckenfels.net

Von: christopher.mil...@gd-ms.com 
Gesendet: Friday, February 4, 2022 7:39:44 PM
An: Maven Users List 
Betreff: RE: Possible protocol error, handshake_error when using Maven


No output when running the following command:  javac GetURLS.java

Just getting GetUrls.class file.

Thanks



-Original Message-----
From: Bernd Eckenfels 
Sent: Friday, February 4, 2022 12:54 PM
To: Maven Users List 
Subject: Re: Possible protocol error, handshake_error when using Maven


External E-mail --- CAUTION: This email originated from outside GDMS. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

The javac command creates the .class file the java command executes it (modern 
java also can execute the .Java file). What is the output of the last java 
command in your case? (You also might ask internally a developer)


--
http://bernd.eckenfels.net

Von: christopher.mil...@gd-ms.com 
Gesendet: Friday, February 4, 2022 6:32:49 PM
An: Maven Users List 
Betreff: RE: Possible protocol error, handshake_error when using Maven



Sorry for the late reply, busy week.

I ran this on my RHEL 8 workstation, and didn't get any output, other then a 
new file was creat

Re: zip file is empty

[Bernd Eckenfels]

First thing would be to determine if those are failed downloads or creates 
(installed from local built). In both cases however failures should not result 
in that. For downloads you have checksum checks and for build artifacts they 
are copied from target/ (depending on the plugins used to install them of 
course).

Is that a groupid and Version you built on that machine or are those external 
artifacts? Are there any remote.properties in the artifact directory in your 
Repo cache dir?

One possible cause could be process or OS crashes since maven does probably not 
fdsync new files (before rename). But you probably would know if that happens 
more often.


--
http://bernd.eckenfels.net

Von: Thomas Matthijs 
Gesendet: Friday, February 18, 2022 4:14:52 PM
An: Maven Users List 
Betreff: Re: zip file is empty

If maven is creating these and then failing to write to them, then maybe instead
it can write to a tmp file first and then move/rename it into place to
solve the
problem more nicely

Regards

On Fri, 18 Feb 2022 at 16:07, Andy Feldman  wrote:
>
> This is also common at my workplace, with the resolution always being to
> delete the empty file and try again. We haven't nailed down a
> reproducible way to cause it, but it does seem to happen more often when
> network conditions are flaky. I agree that deleting the file would be a
> user-friendly thing for Maven to do automatically, assuming only one Maven
> process is operating on the repository at once (which I think Maven already
> assumes).
>
> On Fri, Feb 18, 2022 at 7:03 AM Mantas Gridinas  wrote:
>
> > Even empty jars that were produced by maven would contain
> > META-INF/maven.{groupid}.{artifactid}/pom.* files, wouldn't they? Looking
> > at ZipFile.java such error is thrown when the file is truly empty, and
> > doesnt contain the zip metadata (ZipFile.java:1409 as per adopt openjdk
> > sources).
> >
> > On Fri, Feb 18, 2022, 14:57 Jacques Etienne Beaudet 
> > wrote:
> >
> > > Maven repository is not safe when running multiple concurrent builds (not
> > > the -T1C option). You need to use an external synchronization technique
> > if
> > > you need this.
> > >
> > https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html
> > >
> > > Not sure of the implications of assuming an empty zip file means a failed
> > > download, it seems reasonable to me but I'll let others chip in.
> > > On Feb 18, 2022, 7:43 AM -0500, Nils Breunese , wrote:
> > > > Hi,
> > > >
> > > > I’ve been encountering Maven warnings like these for years from time to
> > > time:
> > > >
> > > > 
> > > > WARN: zip file is empty:
> > >
> > /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
> > > > java.util.zip.ZipException: zip file is empty
> > > > 
> > > >
> > > > I know that when I encounter this I can just delete the file and run
> > > Maven again and then it’ll generally download ok, but recently I’ve been
> > > getting questions from a lot of colleagues with this issue. I was
> > > wondering: would it make sense for Maven to assume that an empty JAR file
> > > was not downloaded correctly and try re-downloading it automatically?
> > > >
> > > > Nils.
> > >
> >

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

Re: Possible protocol error, handshake_error when using Maven

[Bernd Eckenfels]

Yes that’s expected. What does the next command print.


--
http://bernd.eckenfels.net

Von: christopher.mil...@gd-ms.com 
Gesendet: Friday, February 4, 2022 7:39:44 PM
An: Maven Users List 
Betreff: RE: Possible protocol error, handshake_error when using Maven


No output when running the following command:  javac GetURLS.java

Just getting GetUrls.class file.

Thanks



-Original Message-
From: Bernd Eckenfels 
Sent: Friday, February 4, 2022 12:54 PM
To: Maven Users List 
Subject: Re: Possible protocol error, handshake_error when using Maven


External E-mail --- CAUTION: This email originated from outside GDMS. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

The javac command creates the .class file the java command executes it (modern 
java also can execute the .Java file). What is the output of the last java 
command in your case? (You also might ask internally a developer)


--
http://bernd.eckenfels.net

Von: christopher.mil...@gd-ms.com 
Gesendet: Friday, February 4, 2022 6:32:49 PM
An: Maven Users List 
Betreff: RE: Possible protocol error, handshake_error when using Maven



Sorry for the late reply, busy week.

I ran this on my RHEL 8 workstation, and didn't get any output, other then a 
new file was created, called GetUrls.class.   Didn't get the output you have 
below.  Disclosure, I'm not a software developer by trade, so bear with me.

Thanks



-Original Message-
From: Nils Breunese 
Sent: Tuesday, February 1, 2022 12:13 PM
To: Maven Users List 
Subject: Re: Possible protocol error, handshake_error when using Maven


External E-mail --- CAUTION: This email originated from outside GDMS. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

christopher.mil...@gd-ms.com wrote:

> I was able to curl that URL along with pulling that .pom file with the 
> following command:
>
> curl -o maven-archiver-2.5.pom  
> https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom
>
> So I'm still at a loss where I'm experiencing this issue currently.

Have you tried fetching that URL from a simple Java program to check whether 
your Java stack can access that URL?

--
? cat GetUrls.java
import java.net.HttpURLConnection;
import java.net.URL;

class GetUrls {
public static void main(String[] args) throws Exception {
for (String arg : args) {
URL url = new URL(arg);
HttpURLConnection con = (HttpURLConnection) url.openConnection();
con.setRequestMethod("GET");
int status = con.getResponseCode();
System.out.println("[" + status + "] " + url);
}
}
}
? javac GetUrls.java
? java GetUrls 
https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom
[200] 
https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom
--

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


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


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

Re: Possible protocol error, handshake_error when using Maven

[Bernd Eckenfels]

The javac command creates the .class file the java command executes it (modern 
java also can execute the .Java file). What is the output of the last java 
command in your case? (You also might ask internally a developer)


--
http://bernd.eckenfels.net

Von: christopher.mil...@gd-ms.com 
Gesendet: Friday, February 4, 2022 6:32:49 PM
An: Maven Users List 
Betreff: RE: Possible protocol error, handshake_error when using Maven



Sorry for the late reply, busy week.

I ran this on my RHEL 8 workstation, and didn't get any output, other then a 
new file was created, called GetUrls.class.   Didn't get the output you have 
below.  Disclosure, I'm not a software developer by trade, so bear with me.

Thanks



-Original Message-
From: Nils Breunese 
Sent: Tuesday, February 1, 2022 12:13 PM
To: Maven Users List 
Subject: Re: Possible protocol error, handshake_error when using Maven


External E-mail --- CAUTION: This email originated from outside GDMS. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

christopher.mil...@gd-ms.com wrote:

> I was able to curl that URL along with pulling that .pom file with the 
> following command:
>
> curl -o maven-archiver-2.5.pom  
> https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom
>
> So I'm still at a loss where I'm experiencing this issue currently.

Have you tried fetching that URL from a simple Java program to check whether 
your Java stack can access that URL?

--
? cat GetUrls.java
import java.net.HttpURLConnection;
import java.net.URL;

class GetUrls {
public static void main(String[] args) throws Exception {
for (String arg : args) {
URL url = new URL(arg);
HttpURLConnection con = (HttpURLConnection) url.openConnection();
con.setRequestMethod("GET");
int status = con.getResponseCode();
System.out.println("[" + status + "] " + url);
}
}
}
? javac GetUrls.java
? java GetUrls 
https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom
[200] 
https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom
--

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


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

Re: request for documentation update about mirrors

[Bernd Eckenfels]

Well, it’s just a file to edit.


--
http://bernd.eckenfels.net

Von: mark.yagnatin...@barclays.com.INVALID 

Gesendet: Thursday, December 9, 2021 6:22:46 AM
An: users@maven.apache.org 
Betreff: RE: request for documentation update about mirrors

> But if you insist, I heared you can remove the blocked tag in your maven/conf 
> settings.. ;)
But I can't, right?  I'd have edit the global settings file bundled with maven 
itself.
Or no?

_
?This message is for information purposes only, it is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is not intended for retail customer use. Intended for 
recipient only. This message is subject to the terms at: 
www.barclays.com/emaildisclaimer.

For important disclosures, please see: 
www.barclays.com/salesandtradingdisclaimer
 regarding market commentary from Barclays Sales and/or Trading, who are active 
market participants; 
https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html
 regarding our standard terms for the Investment Bank of Barclays where we 
trade with you in principal-to-principal wholesale markets transactions; and in 
respect of Barclays Research, including disclosures relating to specific 
issuers, please see http://publicresearch.barclays.com.?
_
If you are incorporated or operating in Australia, please see 
https://www.home.barclays/disclosures/importantapacdisclosures.html for 
important disclosure.
_
How we use personal information  see our privacy notice 
https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html
_

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

Re: request for documentation update about mirrors

[Bernd Eckenfels]

Hello,

I would define a single caching mirror repository (and maybe exclude all 
internal repositories which are already HTTPS). The mirror applies 
automatically to all repos, you don’t need to configure them individually.

And you should really really start on enabling HTTPS. It is imho no problem if 
some POM define a central with http, your settings.xml for that Repo-Id (and 
the mirror anyway) will have precedence.

But if you insist, I heared you can remove the blocked tag in your maven/conf 
settings.. ;) just be aware that most likely your compliance and network 
departments will love you for getting rid of a insecure intrusion vector in 
your supply chain.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: mark.yagnatin...@barclays.com.INVALID 

Gesendet: Wednesday, December 8, 2021 4:07:31 PM
An: users@maven.apache.org 
Betreff: request for documentation update about mirrors

I hope this is the right mailing list; if I not, would appreciate a redirect.
In the release notes for maven 3.8.1, here:
https://maven.apache.org/docs/3.8.1/release-notes.html
There is a helpfully titled section "How to fix when I get a HTTP repository 
blocked?"
https://maven.apache.org/docs/3.8.1/release-notes.html#how-to-fix-when-i-get-a-http-repository-blocked
It mentions 2 options:

* Update to a newer version of the artifact you're fetching, which is 
presumably available over https

* Define a mirror in your settings, which links to this page:
https://maven.apache.org/guides/mini/guide-mirror-settings.html

The first option is not helpful, since we are using a settings.xml which lists 
many http-only repositories, including one with an id of "central".
Since these are all on our internal network, the usual concerns about security 
don't apply, or at least not in full force like they would on the public 
internet.

(We don't let maven access the public internet.  If a fellow coworker is trying 
to hijack my maven downloads, I suppose they might succeed.  We'll keep taking 
that risk for now :))

That brings us to the second option: create a mirror.  Unfortunately, the 
linked page doesn't even mention anything about blocking and unblocking.
In fact, I can't find the  tag documented anywhere, though perhaps I'm 
looking in the wrong places.

What I'd ideally like to see is a way to "undo" the mirror defined in the 
global settings in one fell swoop.
That is, I do NOT want to go through the repos listed in our repositories, and 
then tediously create a mirror for each of them, one by one, and then remember 
to keep the two lists in sync if anything changes.

So: can the documentation be updated to mention anything about unblocking, and 
is there any way to do what I want?

Thanks,
Mark.

_
?This message is for information purposes only, it is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is not intended for retail customer use. Intended for 
recipient only. This message is subject to the terms at: 
www.barclays.com/emaildisclaimer.

For important disclosures, please see: 
www.barclays.com/salesandtradingdisclaimer
 regarding market commentary from Barclays Sales and/or Trading, who are active 
market participants; 
https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html
 regarding our standard terms for the Investment Bank of Barclays where we 
trade with you in principal-to-principal wholesale markets transactions; and in 
respect of Barclays Research, including disclosures relating to specific 
issuers, please see http://publicresearch.barclays.com.?
_
If you are incorporated or operating in Australia, please see 
https://www.home.barclays/disclosures/importantapacdisclosures.html for 
important disclosure.
_
How we use personal information  see our privacy notice 
https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Bernd Eckenfels]

Even for nfs fcntl locking can work and create/ln/mv are atomic. Do you know if 
there is any file lock based impl available?

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Tamás Cservenák 
Gesendet: Monday, October 4, 2021 10:02:27 PM
An: Maven Users List 
Betreff: Re: Local repository accessed by multiple Maven instances - how is it 
solved ?

Hi Bernd,

nothing is wrong with advisory file locking, as long as you don't store
local repo on NFS ;)
Will re-add file locking once I get there, as in my opinion it is the most
"lightweight" MP (multi process) solution on a single host.
Redis and Hazelcast are more for "farms", where several hosts with many
processes (and each with many threads) is bashing local repo (that MAY be
on NFS as well).

Thanks
Tamas

On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels 
wrote:

> What’s the problem with adivisory locking, as long as Maven honors the
> advice it is the same as it’s a redis lock? (But much less footprint). In
> fact on the same machine it should even work without locking as Long as you
> use pidfiles?
>
> Gruss
> Bernd
>
>

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Bernd Eckenfels]

What’s the problem with adivisory locking, as long as Maven honors the advice 
it is the same as it’s a redis lock? (But much less footprint). In fact on the 
same machine it should even work without locking as Long as you use pidfiles?

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Michael Osipov 
Gesendet: Monday, October 4, 2021 9:15:23 PM
An: users@maven.apache.org 
Betreff: Re: Local repository accessed by multiple Maven instances - how is it 
solved ?

Am 2021-10-04 um 14:31 schrieb Francois Marot:
> Hello all,
>
> I would like clarifications on MNG-2802[*] that seems to be solved. If I
> understand correctly it solves the problem where multiple simultaneous
> Maven executions shared the same local repository.
> I have been keeping for years a bit of code in my Jenkinsfiles ensuring the
> local repos were accessed only by a single jenkins executor at the same
> time, so it seems like I can get rid of this doesn't it ?
> I'd like your input on this because reproducing the bug is difficult so I'd
> like to be sure before simplifying my Jenkinsfile.
>
> Moreover, does anyone know how this problem is solved technically ? Using
> files lock ? Can anybody explain ?
>
> Thanks you and thanks the Maven team for keeping up the good work at such
> pace !

Salut François,

I don't know what you exactly fiddled in your Jenkinsfile, but there is
no way make it right just with Jenkinsfile foo when you want access
*one* local repo with *multiple* processes you *must* use an external
coordinator process.
Forget also about file locks, they are all advisory, at least on
POSIX-like filesystems. There is no way, or a very hard way to make them
right. We tried and removed them.

Now, let me give you bit of history: I have integrated/implemented a
fully working multi-process Redisson-based synchronization lock factory
for Maven Resolver 1.6.x which ships with Maven 3.8.x. (It has already
been battle tested for several months by a user on a busy CI server).
Tamás took it to the next level in Resolver 1.7.x and generalized it to
a named lock approach where the Redisson Lock Factory plugs in nicely
with other lock implementations. Almost nine months of work and it works
very good now.
Now here is the problem: Maven Resolver 1.7.x comes only with Maven 4.x.
I have created a branch which reconciles best of breed: Maven 3.8.x and
Maven Resolver 1.7.x. It just works (also verified by this user). I also
ran more than a thousand builds with 8 parallel processes and 4 threads.
It will easily handle thousands of locks in parralel with an one digit
percent overhead.

I don't know for what documentation you are waiting for, but everything
is there, you can start *now* to leverage it: [2], [3]. With Resolver
2.0.0 and Maven 4.0.0 it will likely be even easier to integrate.

Hazelcast will also work, but Tamás is the special here.

Again: You *must* use an external process to synchronize access. No excuses.

Michael

[1] https://github.com/apache/maven/tree/maven-3.8.x-resolver-1.7.x
[2] https://maven.apache.org/resolver/maven-resolver-named-locks/index.html
[3]
https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html



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

Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext

[Bernd Eckenfels]

An easy fix is to run maven with one local Repo cache per executor thread. 
Jenkins has a option for that. Alternatively run the whole build in a container 
with Repo overlay. (I wish Jenkins had more support to prepopulate those)

Gruss
Bernd

--
http://bernd.eckenfels.net

Von: Austin Witt 
Gesendet: Monday, October 4, 2021 5:27:28 PM
An: Maven Users List 
Betreff: Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext

Is it broken in that it doesn't actually solve the problem? Or broken in
that it doesn't actually install correctly in Maven?

Regardless, is there a solution you would recommend for solving the "many
concurrent instances of Maven are running against the same local
repository, and sometimes their file writes conflict" problem?

On Sun, Oct 3, 2021 at 10:59 AM Michael Osipov  wrote:

> Am 2021-09-29 um 21:18 schrieb Austin Witt:
> > I wish to install a Maven extension - Takari's Concurrent Safe Local
> > Repository extension (
> >
> http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository
> )
> > - on a system such that it's picked up by all Maven runs.
> >
>
> Don't! It is broken! Throw it away!
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Questions on best practice for POM Code Convention setup and how to know what tags can be setup where

[Bernd Eckenfels]

BTW I find distribution management should be in a parent (shared and hidden) or 
not in there at all. I prefer my POMs as landscape independent as possible.


--
http://bernd.eckenfels.net

Von: christopher.mil...@gd-ms.com 
Gesendet: Friday, September 24, 2021 7:08:46 PM
An: users@maven.apache.org 
Betreff: Questions on best practice for POM Code Convention setup and how to 
know what tags can be setup where



I'm cleaning up the POM files that I have based on the Maven documentation, 
especially using the POM Code Convention as reference.

Want to ask this, to confirm that I'm following the best 
practice(https://maven.apache.org/developers/conventions/code.html#pom-code-convention)
  for setting up the correct over for the tags in the POM file that is using 
deploy plugin:



http://maven.apache.org/POM/4.0.0 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance 
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
https://maven.apache.org/xsd/maven-4.0.0.xsd>













Also, I'm still not understanding the following:

What tags can I use?

And where can I use certain tags?


For example under the  tags, I've inherited a POM file that has the tag 
iso and iso  I know that packaging for ISO 
isn't one that can be setup where ,  and  tags 
are setup as this isn't one of the artifacts that can be generated.  So how do 
I know that I can setup  and  tags here?  That will deploy an 
iso file to a remote repo?

Thanks

Re: Questions on best practice for POM Code Convention setup and how to know what tags can be setup where

[Bernd Eckenfels]

Check the POM reference about what goes where, and then check the definition of 
the plugins (the so called mojos) what properties/config they Need.

https://maven.apache.org/pom.html

In your example you are missing the dependencies which is most likely the most 
powerful part of the whole project model.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: christopher.mil...@gd-ms.com 
Gesendet: Friday, September 24, 2021 7:08:46 PM
An: users@maven.apache.org 
Betreff: Questions on best practice for POM Code Convention setup and how to 
know what tags can be setup where



I'm cleaning up the POM files that I have based on the Maven documentation, 
especially using the POM Code Convention as reference.

Want to ask this, to confirm that I'm following the best 
practice(https://maven.apache.org/developers/conventions/code.html#pom-code-convention)
  for setting up the correct over for the tags in the POM file that is using 
deploy plugin:



http://maven.apache.org/POM/4.0.0 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance 
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
https://maven.apache.org/xsd/maven-4.0.0.xsd>













Also, I'm still not understanding the following:

What tags can I use?

And where can I use certain tags?


For example under the  tags, I've inherited a POM file that has the tag 
iso and iso  I know that packaging for ISO 
isn't one that can be setup where ,  and  tags 
are setup as this isn't one of the artifacts that can be generated.  So how do 
I know that I can setup  and  tags here?  That will deploy an 
iso file to a remote repo?

Thanks

Re: Maven tries to download twice, first one without auth

[Bernd Eckenfels]

Hello,

Hm… I thought preemptive=false is the default - but anyway, good that it works 
now for you.

Gruß
Bernd

--
https://Bernd.eckenfels.net

From: Francois Marot 
Sent: Monday, August 30, 2021 4:43:33 PM
To: Maven Users List 
Subject: Re: Maven tries to download twice, first one without auth

Hello Bernd and Slawomir,
I want to thank you both for the advice. Using the preemptive auth works
like a charm.
In the end, the analysis showed that a network component was seeing all the
"401 Unauthorized" errors and was randomly deciding
to stop the requests. It must have been mistakenly associated to a network
attack or something.

The setting to use is this one:



false



I would advise anyone in a corporate network to configure its settings.xml
with this setting to access his corporate repository.
I even believe it should be the default setting for predefined servers
located in settings.xml because Maven does not try to communicate with
random servers on the internet by itself (in which case disabling
preemptive auth may be worth it).
Should I create an issue ?


Le ven. 20 août 2021 à 23:12, Bernd Eckenfels  a
écrit :

> Hello,
>
> This is, for some reason intentional, the client is supposed to only sent
> auth when challenged. Since this is not done in a smart way it can slow
> transfers down.
>
> There used to be ways to configure it pre-emptively, but not sure if the
> doc is still valid:
> http://maven.apache.org/guides/mini/guide-http-settings.html#Example:_Using_Preemptive_Authentication
>
> Greetings
> Bernd
>
>
> --
> http://bernd.eckenfels.net<http://bernd.eckenfels.networks>
> 
> Von: Francois Marot 
> Gesendet: Friday, August 20, 2021 4:12:33 PM
> An: Maven Users List 
> Betreff: Maven tries to download twice, first one without auth
>
> Hello Maven users,
>
> I face a strange problem that I'd like to describe. I'm setting up a new
> artifact repository and this is JFrog's Artifactory.
> I have build freeze problems (which I still no have solved) so during my
> investigations I found this in Artifactory's logs:
>
> - - - - - - - - - - - - - - - - - - - - - - - - -
>
> 2021-08-19T16:07:55.729Z|339817580d4decc9|192.168.38.137|non_authenticated_user|GET|/maven-libs-release/org/apache/velocity/velocity/1.5/velocity-1.5.pom|
> *401*|-1|0|0|Apache-Maven/3.8.2 (Java 11.0.8; Linux
> 3.10.0-1160.25.1.el7.x86_64)
>
>
> 2021-08-19T16:07:55.734Z|123110ba8a2e7eb9|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/org/apache/velocity/velocity/1.5/velocity-1.5.pom|200|-1|7714|2|Apache-Maven/3.8.2
> (Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)
>
> 2021-08-19T16:07:55.743Z|f0d9c80461c879fd|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/org/apache/velocity/velocity/1.5/velocity-1.5.pom.sha1|200|-1|40|3|Apache-Maven/3.8.2
> (Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)
>
>
> 2021-08-19T16:07:55.752Z|6500587859c8a99c|192.168.38.137|non_authenticated_user|GET|/maven-libs-release/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.pom|
> *401*|-1|0|0|Apache-Maven/3.8.2 (Java 11.0.8; Linux
> 3.10.0-1160.25.1.el7.x86_64)
>
>
> 2021-08-19T16:07:55.758Z|32c027e38c5f6b49|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.pom|200|-1|12403|3|Apache-Maven/3.8.2
> (Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)
>
> 2021-08-19T16:07:55.766Z|1dce46d14ae35ed3|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.pom.sha1|200|-1|40|2|Apache-Maven/3.8.2
> (Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)
>
>
> 2021-08-19T16:07:55.774Z|a37b50bee467027a|192.168.38.137|non_authenticated_user|GET|/maven-libs-release/org/apache/commons/commons-parent/39/commons-parent-39.pom|
> *401*|-1|0|1|Apache-Maven/3.8.2 (Java 11.0.8; Linux
> 3.10.0-1160.25.1.el7.x86_64)
>
>
> 2021-08-19T16:07:55.779Z|8c4ca838bc43d3b2|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/org/apache/commons/commons-parent/39/commons-parent-39.pom|200|-1|61975|2|Apache-Maven/3.8.2
> (Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)
>
> 2021-08-19T16:07:55.793Z|9d2ce78abf97f47e|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/org/apache/commons/commons-parent/39/commons-parent-39.pom.sha1|200|-1|40|3|Apache-Maven/3.8.2
> (Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)
>
>
> 2021-08-19T16:07:55.801Z|8d5e469c8d929120|192.168.38.137|non_authenticated_user|GET|/maven-libs-release/org/apache/apache/16/apache-16.pom|
> *401*|-1|0|0|Apache-Maven/3.8.2 (Java 11.0.8; Linux
> 3.10.0-1160.25.1.el7.x86_64)
>
>
> 2021-08-19T16:07:55.807Z|2e1b208f4afeae52|192.168.38.137|to

Re: Maven tries to download twice, first one without auth

[Bernd Eckenfels]

Hello,

This is, for some reason intentional, the client is supposed to only sent auth 
when challenged. Since this is not done in a smart way it can slow transfers 
down.

There used to be ways to configure it pre-emptively, but not sure if the doc is 
still valid: 
http://maven.apache.org/guides/mini/guide-http-settings.html#Example:_Using_Preemptive_Authentication

Greetings
Bernd


--
http://bernd.eckenfels.net

Von: Francois Marot 
Gesendet: Friday, August 20, 2021 4:12:33 PM
An: Maven Users List 
Betreff: Maven tries to download twice, first one without auth

Hello Maven users,

I face a strange problem that I'd like to describe. I'm setting up a new
artifact repository and this is JFrog's Artifactory.
I have build freeze problems (which I still no have solved) so during my
investigations I found this in Artifactory's logs:

- - - - - - - - - - - - - - - - - - - - - - - - -
2021-08-19T16:07:55.729Z|339817580d4decc9|192.168.38.137|non_authenticated_user|GET|/maven-libs-release/org/apache/velocity/velocity/1.5/velocity-1.5.pom|
*401*|-1|0|0|Apache-Maven/3.8.2 (Java 11.0.8; Linux
3.10.0-1160.25.1.el7.x86_64)

2021-08-19T16:07:55.734Z|123110ba8a2e7eb9|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/org/apache/velocity/velocity/1.5/velocity-1.5.pom|200|-1|7714|2|Apache-Maven/3.8.2
(Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)
2021-08-19T16:07:55.743Z|f0d9c80461c879fd|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/org/apache/velocity/velocity/1.5/velocity-1.5.pom.sha1|200|-1|40|3|Apache-Maven/3.8.2
(Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)

2021-08-19T16:07:55.752Z|6500587859c8a99c|192.168.38.137|non_authenticated_user|GET|/maven-libs-release/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.pom|
*401*|-1|0|0|Apache-Maven/3.8.2 (Java 11.0.8; Linux
3.10.0-1160.25.1.el7.x86_64)

2021-08-19T16:07:55.758Z|32c027e38c5f6b49|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.pom|200|-1|12403|3|Apache-Maven/3.8.2
(Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)
2021-08-19T16:07:55.766Z|1dce46d14ae35ed3|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.pom.sha1|200|-1|40|2|Apache-Maven/3.8.2
(Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)

2021-08-19T16:07:55.774Z|a37b50bee467027a|192.168.38.137|non_authenticated_user|GET|/maven-libs-release/org/apache/commons/commons-parent/39/commons-parent-39.pom|
*401*|-1|0|1|Apache-Maven/3.8.2 (Java 11.0.8; Linux
3.10.0-1160.25.1.el7.x86_64)

2021-08-19T16:07:55.779Z|8c4ca838bc43d3b2|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/org/apache/commons/commons-parent/39/commons-parent-39.pom|200|-1|61975|2|Apache-Maven/3.8.2
(Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)
2021-08-19T16:07:55.793Z|9d2ce78abf97f47e|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/org/apache/commons/commons-parent/39/commons-parent-39.pom.sha1|200|-1|40|3|Apache-Maven/3.8.2
(Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)

2021-08-19T16:07:55.801Z|8d5e469c8d929120|192.168.38.137|non_authenticated_user|GET|/maven-libs-release/org/apache/apache/16/apache-16.pom|
*401*|-1|0|0|Apache-Maven/3.8.2 (Java 11.0.8; Linux
3.10.0-1160.25.1.el7.x86_64)

2021-08-19T16:07:55.807Z|2e1b208f4afeae52|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/org/apache/apache/16/apache-16.pom|200|-1|15507|2|Apache-Maven/3.8.2
(Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)
2021-08-19T16:07:55.815Z|b634f0399cad3c56|192.168.38.137|token:ci-fake-user|GET|/maven-libs-release/org/apache/apache/16/apache-16.pom.sha1|200|-1|40|2|Apache-Maven/3.8.2
(Java 11.0.8; Linux 3.10.0-1160.25.1.el7.x86_64)

2021-08-19T16:07:55.825Z|befe40b044d34700|192.168.38.137|non_authenticated_user|GET|/maven-libs-release/commons-lang/commons-lang/2.1/commons-lang-2.1.pom|
*401*|-1|0|1|Apache-Maven/3.8.2 (Java 11.0.8; Linux
3.10.0-1160.25.1.el7.x86_64)
- - - - - - - - - - - - - - - - - - - - - - - - -

as you can see, for each pom artifact, it seems like Maven does a first
request not authenticated (hence the "|401|" in the logs) and then another
one authenticated. This second one succeeds.
I corrected this problem by adding a httpHeader property (see below) with
the same value as the "password" field (that was previously the only place
where I wrote the password) and now I have correct logs with only one
request and no 401 anymore.

- - - - - - - - - - - - - - - - - - - - - - - - -


  ci-fake-user
  XXX
  releases
 

  
Authorization
Bearer XXX
  

  


  ci-fake-user
  XXX
  snapshots
 

  
Authorization
Bearer XXX
  

  

  
- - - - - - - - - - - - - - - - - - - - - - - - -

I 

Re: Question on installing Maven from Red Hat (RHEL8), missing .m2 directory for users

[Bernd Eckenfels]

If you want to deploy a pre-configured ~/.m2/settings.xml you can do that 
perfectly fine with ansible, just configure it to generate missing parent 
directories. It is normal that dot files/dirs in user directory are created 
only on first use. This is not specific to RedHat, and there is also nothing 
special to the directory, just create it as needed and make sure it has the 
correct owner and permission.

We have good experiences with doing that in a developer workplace provisioning, 
but as mention by others we would not force ancient versions upon developers.

BTW you really need a internal repository Server anyway, if you have that you 
can also use it to download the actual maven archive for installation.

Gruss
Bernd

--
http://bernd.eckenfels.net

Von: christopher.mil...@gd-ms.com 
Gesendet: Thursday, August 19, 2021 6:43:34 PM
An: Maven Users List 
Betreff: RE: Question on installing Maven from Red Hat (RHEL8), missing .m2 
directory for users



Thanks for the reply.

I've worked with different version of RHEL for sometimes now and its my 
understanding that Red Hat packages older versions of software because they 
know it "should" work out of the box.

Forgot to mention, this is a air-gapped environment, so its hard to get things 
in and out of it, so going with the Maven release from Red Hat maybe our only 
option, but I want to test a tarball in a virtualized environment, see how that 
works too.



-Original Message-
From: Michael Osipov 
Sent: Wednesday, August 18, 2021 2:15 PM
To: users@maven.apache.org
Subject: Re: Question on installing Maven from Red Hat (RHEL8), missing .m2 
directory for users


External E-mail --- CAUTION: This email originated from outside GDMS. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

Please note that:

Am 2021-08-18 um 17:44 schrieb christopher.mil...@gd-ms.com:
> [user_a@rhel8-maven3 bin]$ mvn --version Apache Maven 3.5.4 (Red Hat
> 3.5.4-5)
   ^^^
Custom distributions are discouraged and not supported by us.

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



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

Re: Sharing Test Dependencies

[Bernd Eckenfels]

We have one case in commons, there rhe -test JAR of VFS can be used by 
Providers to test their implementation. I did that for my custom provider, but 
it is a bit ugly. I think that’s mostly due to relying on some src files and 
also the JUnit setup when I remember correctly. But it did work, even when it’s 
not what maven project normally do. The test suite could be its own module, but 
it would probably not make it much nicer to run in that case, don’t know.

I would not expect Test jars to play nicely with application servers, OSGi 
bundles or JPMS for that matter. Only with shared classpath junit “deployment”

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Tibor Digana 
Gesendet: Sunday, July 4, 2021 10:19:45 PM
An: Maven Users List 
Betreff: Re: Sharing Test Dependencies

I did not have time to read it all but I have to say that even the first
point is bad.
Many people want to share test JAR as they initially think it is a good
idea. And then the problems would come.

sharing stubs? This domain/project may not fit to other domain/project, and
it creates dangerous cohesion.
sharing testing utility classes? Maybe, it depends. It must be universal
and independent of the project's domain. Do it in a separate Git project.
sharing JUnit superclasses? The inheritance must be domain/business
independent. It must be only a technical class. Do it in a separate Git
project.

T



On Thu, Jul 1, 2021 at 7:15 PM Brandon Mintern  wrote:

> Hello all,
>
> I'm running up against an issue that I'm sure has come up countless times.
> How can we share test dependencies in a principled way? I would like to
> configure our projects such that:
>
>1. For a project *P*, its tests are associated with the project, so that
>`mvn install` from the project directory *p/* fails when P's tests fail.
>2. Some of P's testing functionality (e.g., stubs, testing utility
>classes, JUnit superclasses) are packaged for use in the tests of other
>projects* D* that depend on P.
>3. P's shared testing functionality has dependencies on P. For example,
>P defines a repository interface R, and its tests define and use an
> RStub
>that implements R. We want to package RStub for use by D's tests.
>4. When D declares a scope:test dependency on P's testing functionality,
>automatically pull in the transitive dependencies of that testing
>functionality.
>5. Avoid cycles in the Maven dependency graph.
>
> Some things I've tried so far:
>
>- Create test-jars for P. This fails on #2 and #4:
>- The test-jars include all of P's test classes instead of just the
>   testing functionality that needs to be shared for use by D's tests.
>   - All transitive dependencies of P's test-jar must be manually
>   specified with scope:test in the D's POM.
>- Extract the stubs to an independent "P - Stubs" project, which P's
>tests depend on.
>   - p-stubs depends on P.
>   - Stubs, testing utilities, etc. go in p-stubs/src/main/.
>   - P depends on p-stubs with scope:test.
>   - D depends on p-stubs with scope:test.
>   - This fails on #5: it causes a cycle in the dependency graph since P
>   depends on p-stubs (scope:test) and p-stubs depends on P. See
>   https://stackoverflow.com/questions/10174542
>- Create an independent "P - Tests" project, with P's stubs and tests.
>   - p-tests depends on P.
>   - Stubs, testing utilities, etc. go in p-tests/src/main/.
>   - P's tests go in p-tests/src/test/.
>   - D depends on p-tests with scope:test.
>   - This almost works but fails on #1: P's build succeeds when its
>   tests fail.
>   - This approach also seems to be fighting Maven and IDE tooling. For
>   example, NetBeans will automatically create p/src/test even
> though we never
>   intend to put anything there.
>
> My searches so far have not turned up any complete solutions to this
> problem. The maven-jar-plugin documentation has a section
> <
> https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html#The_preferred_way
> >
> that touches on this issue:
>
> The preferred way
>
> In order to let Maven resolve all test-scoped transitive dependencies you
> should create a separate project.
>
>
>1. 
>2.groupId
>3. artifactId-tests
>4. version
>5.   ...
>6. 
>
>
>- Move the sources files from src/test/java you want to share from the
>original project to the src/main/java of this project. The same type of
>movement counts for the resources as well of course.
>- Move the required test-scoped dependencies and from the original
>project to this project and remove the scope (i.e. changing it to the
>compile-scope). And yes, that means that the junit dependency (or any
>other testing framework dependency) gets the default scope too. You'll
>probably need to add some project specific dependencies as well to let
> 

Re: Getting version upgrade advise to upgrade a BOM..

[Bernd Eckenfels]

If your bom version is in a property you must run display-properties-update 
instead 
https://www.mojohaus.org/versions-maven-plugin/display-property-updates-mojo.html

--
http://bernd.eckenfels.net

Von: Niels Basjes 
Gesendet: Monday, May 3, 2021 1:26:58 PM
An: Maven Users List 
Betreff: Re: Getting version upgrade advise to upgrade a BOM..

Hi,

Update: I did some experiments to see how all of this works right now.
If I do this in my test project (with a few extra deliberately placed 'old'
dependencies)
*  mvn versions:display-dependency-updates
versions:display-plugin-updates*
I get
- All the dependencies inside the google libraries-bom that need to be
updated (like grpc).
- I do *not* get a hint to update the libraries-bom itself.
- The hint to update this dependency   :   org.slf4j:slf4j-api
. 1.7.25 -> 1.7.30
- The hint to update this test dependency:   junit:junit
... 4.13 -> 4.13.2
- The hint to update this plugin:
 org.sonarsource.scanner.maven:sonar-maven-plugin  3.8.0.2131 -> 3.9.0.2155

If I run the mentioned

*  mvn versions:use-latest-versions versions:update-properties
-DgenerateBackupPoms=false*
The ONLY thing that has been updated is the  libraries-bom version (in a
property)
None of the things mentioned in the previous command have been changed or
mentioned.

I had a quick look at the manual of this version plugin and even tried this
(with no changes)
 *mvn versions:use-latest-releases versions:use-releases
 versions:use-latest-versions versions:update-properties
-DgenerateBackupPoms=false*

What am I doing wrong here?

Niels Basjes



On Sun, May 2, 2021 at 4:38 PM Niels Basjes  wrote:

> Thanks,
>
> This actually works.
> I find this surprising because apparently this plugin cannot indicate what
> needs to be changed, but it can do the change.
>
> Niels
>
> On Sun, May 2, 2021 at 4:25 PM Nick Stolwijk 
> wrote:
>
>> To update the BOM dependencies you can use the Maven versions plugin:
>>
>> mvn versions:use-latest-versions versions:update-properties
>> -DgenerateBackupPoms=false
>>
>> Hth,
>>
>> Nick Stolwijk
>>
>> ~~~ Try to leave this world a little better than you found it and, when
>> your turn comes to die, you can die happy in feeling that at any rate you
>> have not wasted your time but have done your best ~~~
>>
>> Lord Baden-Powell
>>
>>
>> On Sun, May 2, 2021 at 3:12 PM Niels Basjes  wrote:
>>
>> > Hi,
>> >
>> > Thanks for the suggestion.
>> > Apparently the "standard" maven versions plugin does not do this
>> correctly
>> > yet.
>> >
>> > I was looking at this renovate tool yet what I found is that it seems to
>> > only support creating pull/merge requests.
>> > This is very nice but not what I want right now.
>> > Is there a way to run it locally (without any github/gitlab/... system)
>> and
>> > generate a patch file or just a list of problematic versions?
>> >
>> > Niels Basjes
>> >
>> >
>> > On Fri, Apr 30, 2021 at 3:40 AM Tomo Suzuki > >
>> > wrote:
>> >
>> > > Hi Niels,
>> > > (Thank you for using the libraries-bom! I'm one of the maintainers of
>> the
>> > > BOM.)
>> > >
>> > > I don't know how to do it in Maven. However, I often see people using
>> > > dependabot or
>> > > renovatebot integrated with their repositories.
>> > > An example pull request by renovatebot:
>> > > https://github.com/googleapis/java-securitycenter/pull/472
>> > >
>> > > Note that RenovateBot doesn't require GitHub.com repository:
>> > > https://github.com/renovatebot/renovate#self-hosting
>> > >
>> > >
>> > >
>> > >
>> > > On Thu, Apr 29, 2021 at 5:12 PM Delany 
>> > wrote:
>> > >
>> > > > Is it this
>> > https://github.com/mojohaus/versions-maven-plugin/issues/395
>> > > > Regards,
>> > > > Delany
>> > > >
>> > > >
>> > > > On Thu, 29 Apr 2021, 22:22 Niels Basjes,  wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > I see quite a few situations where the dependencies for toolkit
>> are
>> > > > > provided in the form of a dependency you must "import" in
>> > > > > the dependencyManagement section.
>> > > > > They provide this to ensure you always have a working combination
>> > for a
>> > > > lot
>> > > > > of closely related dependencies.
>> > > > >
>> > > > > To illustrate the problem I ran into I created this minimal
>> pom.xml:
>> > > > >
>> > > > > 
>> > > > > http://maven.apache.org/POM/4.0.0;
>> > > > >  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>> > > > >  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> > > > > http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>> > > > > 4.0.0
>> > > > >
>> > > > > nl.basjes.example
>> > > > > dependency-version-test
>> > > > > 0.1-SNAPSHOT
>> > > > > jar
>> > > > >
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > com.google.cloud
>> > > > > libraries-bom
>> > > > > 19.0.0
>> > > > 

Re: maven-gpg-plugin SHA512

[Bernd Eckenfels]

Other question, why not change the defaults to include at least one less 
challenged checksum?


--
http://bernd.eckenfels.net

Von: Michael Osipov 
Gesendet: Sunday, March 14, 2021 9:46:55 PM
An: users@maven.apache.org 
Betreff: Re: maven-gpg-plugin SHA512

Am 2021-03-11 um 17:25 schrieb Andreas Sewe:
> Andreas Sewe wrote:
>> Michael Osipov wrote:
 Michael Osipov wrote:
> Don't waste your time. Read [1]: aether.checksums.algorithms
>
> [1] https://maven.apache.org/resolver/configuration.html

 Thank you for the pointer. Just found this post when searching for a way
 to create .sha256 and .sha512 files during a "mvn deploy" but can't get
 it to work:

mvn deploy -Daether.checksums.algorithms=SHA-512,SHA-256,SHA1,MD5

 The above still only created .sha1 and .md5 files in my staging
 repository. What am I doing wrong?
>>>
>>> You need to update the bundled Maven Resolver version and it will work.
>>> Mark Thomas is already using it with Maven Resolver Ant Tasks to push
>>> Tomcat releases.
>>
>> Thanks Michael. That works like a charm.
>
> Alas, I spoke too soon. It works on the command line, but I can't make
> it an permanent part of my parent POM:
>
>
>
> SHA-512,SHA-256,SHA-1,MD5
>

This will not work. I do recommend to use
https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#arguments

Please try and tell...

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

Re: Has maven central index stopped updating?

[Bernd Eckenfels]

Yes, maven central index has quite regularly problems with beeing stuck or 
laggy ,-/

Luckily normal maven resolving uses the meta data or direct path instead, which 
is reachable and shows the 2/12 versions

https://repo.maven.apache.org/maven2/org/springframework/security/spring-security-bom/

You can open a sonatype ticket, but one would expect this condition to be 
monitored quite easily by them.

https://issues.sonatype.org/projects/MVNCENTRAL/

There is a huge backlog of unanswered or unclosed (but answered) community 
tickets, I really wonder how the community could help here a bit. They should 
not have to carry the whole burden alone. If midweek a indexer failure is 
unnoticed for days (or an ongoing rebuild is not announced?) it is a warning 
sign (and it’s not new)

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Jim Sellers 
Gesendet: Friday, February 12, 2021 8:56:56 PM
An: Maven Users List 
Betreff: Has maven central index stopped updating?

Hi all.

I'm looking at the central index and the last timestamp is from the 9th,
but it looks like spring security 5.4.4 was released on the 12th.

https://repo.maven.apache.org/maven2/.index/
https://search.maven.org/artifact/org.springframework.security/spring-security-bom/5.4.4/pom

Does anyone know if there's something stuck?

Thanks for your time,
Jim

Re: Maven 3.6.3 configuration enquiry

[Bernd Eckenfels]

This (setting automatically of M2_HOME) does not work in all cases, especially 
not if the launch script is not used (IDE or Maven Agents), but it would be 
best to not set it, if not needed (agreed).


--
http://bernd.eckenfels.net

Von: Jörg Schaible 
Gesendet: Thursday, January 7, 2021 10:38:45 PM
An: Maven Users List 
Betreff: Re: Maven 3.6.3 configuration enquiry

Am Donnerstag, 7. Januar 2021, 20:23:27 CET schrieb Bernd Eckenfels:
> You did not say what build servers you use, but normally you can have many
> different maven versions installed in different directories. Usually CI
> servers are fine to pick one (some like Jenkins can even install them
> dynamically).
>
> If you do it, you need to watch out for not using/inheriting environment
> variables (especially PATH, java and maven home), when using a user/global
> settings.xml it should be valid for all versions (it usually is) or specify
> a unique file for each environment with the -s flag. Also make sure to
> specify the full path to the mvn launcher. Some plugins like maven release
> plugin also prefer if you set the correct M2_HOME env variable.

Best is not to set it at all. Then it is automatically set by the individual
shell script that starts Maven (bin/mvn or bin/mvn.cmd) and will automatically
point to the current Maven in use.

[snip]

Cheers,
Jörg




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

Re: Maven 3.6.3 configuration enquiry

[Bernd Eckenfels]

You did not say what build servers you use, but normally you can have many 
different maven versions installed in different directories. Usually CI servers 
are fine to pick one (some like Jenkins can even install them dynamically).

If you do it, you need to watch out for not using/inheriting environment 
variables (especially PATH, java and maven home), when using a user/global 
settings.xml it should be valid for all versions (it usually is) or specify a 
unique file for each environment with the -s flag. Also make sure to specify 
the full path to the mvn launcher. Some plugins like maven release plugin also 
prefer if you set the correct M2_HOME env variable.

When sharing the local maven cache, it usually works across different maven 
versions, just be careful when using it in parallel (using one cache per 
executor is sometimes more robust).

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Nitish Mittal 
Gesendet: Thursday, January 7, 2021 6:18:57 PM
An: users@maven.apache.org 
Betreff: Fwd: Maven 3.6.3 configuration enquiry

Hi team,

We are already using maven 3.3.9 and for some projects we want to configure
3.6.3 in the same set of build agents. Can you please help me to understand
if there would be any issue if both versions co-exist on the same set of
servers. Is there any setting that needs to be done for them to co-exist.

Secondly, i see there are 2 improvement issues in release notes, can you
please halp me to know if we need to make those changes in our user
settings file? or the project settings file?

Thanks
Nitish Mittal

Re: maven enforcer plugin questions

[Bernd Eckenfels]

Hello,

Yes. this list can be used to reach users of maven, including maven plugins 
like the enforcer plugin (a official plugin has the name maven-something-plugin 
and is hosted on the Maven web site like 
https://maven.apache.org/enforcer/maven-enforcer-plugin/).

But even if it where a third party plugin, it is fine to discuss them here with 
other users.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Andrew Marlow 
Gesendet: Saturday, December 5, 2020 1:01:35 PM
An: users@maven.apache.org 
Betreff: maven enforcer plugin questions

Hello everyone,

excuse me, is this the right place to discuss questions about the maven
enforcer plugin please?

--
Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk

Re: Reporting in maven. help please

[Bernd Eckenfels]

Hello,

There are a number of static code analyses which also happen to have a maven 
plugin (with sire reporting integration), for example pmd, findbugs/spotbugs, 
checker framework, checkstyle, (static-Code-analysis) Javancss, taglist, l10n 
status, jdepend and dependency-Check, and a few external tools with maven 
integration like sonarqube, lgtm or Snyk, see also here 
https://maven.apache.org/code-quality-management.html

Most of those plugins are best used when you have a matching CI plugin to 
record long term trends or if they have their own database (like sonarqube).

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Aitor Iturriondobeitia 
Gesendet: Sunday, November 29, 2020 6:47:13 PM
An: Maven Users List 
Betreff: Reporting in maven. help please

Hello
i am new using maven and i am reading documentation.
Can you say me which plugins can i use for reporting the code quality?
any example?
thanks

Re: Maven plugin to replace text in file

[Bernd Eckenfels]

You can use the antrun plugin to run a ant search and replace, or you an call a 
jruby or groovy script. Or is the exec plugin to run a java class. The 
resources plugin can replace placeholders, but that does not sound like the 
right tool for your case.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: David Hoffer 
Gesendet: Sunday, November 8, 2020 6:00:41 PM
An: Maven Users List 
Betreff: Maven plugin to replace text in file

Hi,

I need to process a file during the build to replace constructs like this:

"allOf": [
  {
"$ref": "#/definitions/Eligibility"
  }
],

to be:

"$ref": "#/definitions/Eligibility",

Where the $ref can point to anything.  How can I do this sort of writing
custom code?

-Dave

Re: HTTP/2 support in Maven

[Bernd Eckenfels]

Hello,

I don’t really see where http/2 should have a speed performance compared to 
http/1.1 as long as both use keepalive. For larger artifacts even the header 
reduction should be negectible. Having said that, it is of course a good idea 
to go with the new protocols, but I would not expect much advantage. Especially 
not if you limit yourself to one or two tcp connections per repository.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Jakub Bartecek 
Gesendet: Thursday, November 5, 2020 6:28:05 PM
An: Maven Users List 
Betreff: Re: HTTP/2 support in Maven

Hi,
I'll look at it tomorrow and try to verify it really downloads the whole
content, I did some checks on POM files and it really downloaded it.

Thanks for testing it from your machine. It's interesting to see that you
have completely different results. Honestly I'm not sure how that is
possible, but I'll think about it more tomorrow. I'm about to call it a day
now.

Kuba

On Thu, Nov 5, 2020 at 6:10 PM Tamás Cservenák  wrote:

> (short disclaimer: am not a python speaking person, so the change I did
> above with intent to "consume response body, the artifact bytes" may not
> did what I wanted :D)
>

Re: exec:java doesn't find classes from jar files

[Bernd Eckenfels]

Hello,

I don't think it is a good idea to repackage or relocate common external 
libraries. It looks like you moved everything to groupid=lib, this is a not 
very common Maven usage. I am not saying you can't get it to work, but it needs 
some advanced skills and it is unlikely we can easily help you.

This might also be the reason why your transitive dependencies are no longer 
detected automatically, because you don't have the upstream POMs.

Your particular error seems to be an effect of that,  maybe mixing different 
library versions.

You can try to debug it by looking at "mvn dependency:tree"

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Raivo Rebane 
Gesendet: Saturday, October 31, 2020 2:20:21 PM
An: users@maven.apache.org 
Betreff: Re: exec:java doesn't find classes from jar files

Hello

My pom is as follows:

http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd;>
 4.0.0

 1
 p0
 0.0.1

 A Solr project
 http://www.devonlinux.net

 
 3.r4.0
 8983
 


   
 project.local
 project
 file:${project.basedir}/repo
   


 

 
   lib
   solrj
   1.0
 


 
   lib
   httpclient
   1.0
 

 
   lib
   httpcore
   1.0
 


 
   lib
   codec
   1.0
 

 
   lib
   logging
   1.0
 

 
   lib
   httpclient-beta
   1.0
 

 
   lib
   apache-httpmime
   1.0
 

 
   lib
   slf4j
   1.0
 

 
   lib
   logback-classic
   1.0
 

 
   lib
   logback-core
   1.0
 

 

 

 
 
src/main/resources
 true
 
 

 


 
 org.apache.maven.plugins
 maven-compiler-plugin
 
 1.7
 1.7
 
 

 
 org.mortbay.jetty
maven-jetty-plugin
 6.1.25
 
10
 foo
 
 /solr
 
 
 ${solr.port}
6
 
 
 
 
 solr.data.dir
 target/data
 
 
 
 
 
 start-jetty
pre-integration-test
 
 run
 
 
 true
 
 
 
 stop-jetty
post-integration-test
 
 stop
 
 
 
 


 
 org.owasp
dependency-check-maven
 6.0.2
 
true
true
 
 
 
 
 check
 
 
 
 

 
 org.easyb
maven-easyb-plugin
 1.3
 
 
integration-test
 
 test
 
 
 
 
${basedir}/src/test/stories
${project.build.directory}/easyb-stories.txt
${project.build.directory}/easyb-report.xml
 html
${project.build.directory}/acceptance/stories.html
 
 

 

 


And error message is as follows:

Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 11.0.9, vendor: Ubuntu, runtime:
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-52-generic", arch: "amd64", family: "unix"
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
com.google.inject.internal.cglib.core.$ReflectUtils$1
(file:/usr/share/maven/lib/guice.jar) to method
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of
com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will 

Re: mvn exec:java don't use jars from project repo

[Bernd Eckenfels]

Looks like your Solr.Pom does not define a dependency on httpclient. You can 
either change that or add it as a runtime dependency to your local Pom.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Raivo Rebane 
Gesendet: Friday, October 30, 2020 5:39:38 PM
An: users@maven.apache.org 
Betreff: mvn exec:java don't use jars from project repo

.Hello

I run following command :

mvn exec:java -Dexec.mainClass="SolrJExample"
-Dexec.classpathScope=runtime  -X

and

classpath conains following line :

 

end pom conains following lines :

 
 
   lib
   solrj
   1.0
 
 

And it compiles perfectly.

But command mvn exec:java

gives me :

java.lang.NoClassDefFoundError: org/apache/http/client/HttpClient
 at org.apache.solr.client.solrj.impl.HttpSolrClient$Builder.build
(HttpSolrClient.java:968)
 at SolrJExample.getSolrClient (SolrJExample.java:189)
 at SolrJExample. (SolrJExample.java:33)

but it declares following :

[DEBUG] Project Dependencies will be included.
[DEBUG] Collected project artifacts [lib:solrj:jar:1.0:compile]
[DEBUG] Collected project classpath
[/home/hydra/workspace1/p0/target/classes]
[DEBUG] Adding to classpath : /home/hydra/workspace1/p0/target/classes
[DEBUG] Adding project dependency artifact: solrj to classpath

What is wrong ?

Regards

Raivo





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

Re: No transfer protocol found

[Bernd Eckenfels]

Did you specify „repo“ as the url? I think it needs a valid URL here.


--
http://bernd.eckenfels.net

Von: Raivo Rebane 
Gesendet: Friday, October 30, 2020 2:27:05 PM
An: users@maven.apache.org 
Betreff: No transfer protocol found

Hello

I have trouble

I tried mvn deploy:deploy-file in different ways:

as example mvn deploy:deploy-file -Durl=repo
-Dfile=/opt/tomcat/latest/lib/or.jar -DgroupId=com.appserv
-DartifactId=devlib -Dpackaging=jar -Dversion=0.1
-Dmaven.wagon.provider.http=wagon-file

But in any cases I got error:

Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file
(default-cli) on project AppServ: No transfer protocol found.

What is wrong ?

Regards

Raivo



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

Re: How to build multiple .jars from a single /src/ tree?

[Bernd Eckenfels]

You can configure multiple jar creation runs (for example with the assembly or 
maven-jar-plugin) with include and exclude rules, which creates a second jar 
with a classifier. But derivations from a default build (one jar per module) 
should be done only if absolutely necessary. In the Long run it’s a good idea 
to restructure your projects and source directories for clean separation.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: /dev /local/ca 
Gesendet: Friday, October 16, 2020 10:12:50 AM
An: users@maven.apache.org 
Betreff: How to build multiple .jars from a single /src/ tree?

Using Apache Maven, I want to know the simplest way to build mutliple jar
files based on the package path from a single src/ directory hierarchy

I have src/com/pkg-path-one/.../ and src/com/pkg-path-two/.../

I am required to build one jar from src/pkg-path-one, and another jar from
src/com/pkg-path-two/.../

the repo I inherited does not have the typical layout: src/main/java/com
and so on, but starts at src/com
--

I am assuming two commands would need to be run specifying a target for
each jar (maybe - not sure), but having both jars built with a single
command would be helpful.

I am starting from ground zero with maven, so a full example of a pom.xml
would be helpful, if anyone has one around they have used for this in the
past.

thank you

Re: Using Apache Maven, what is the simplest way to include /lib/ directory in the classpath in the pom.xml

[Bernd Eckenfels]

Hello,

It is really not a good idea to fight maven. If you need something in the 
classpath for compile, specify it as dependency in the Pom. Otherwise your 
build cannot be repeated and the project is hard to set up.

All tomcat libraries needed to compile should be in the maven repository. If 
you have custom artifacts, the normal method is to upload them to a (own) 
repository Server and reference them there.

There is a way to specify a local („system“) location for dependencies, but I 
would not recommend that way. (And in all cases not possible to use a 
wildcard/directory search)

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: /dev /local/ca 
Gesendet: Friday, October 16, 2020 10:24:50 AM
An: users@maven.apache.org 
Betreff: Using Apache Maven, what is the simplest way to include 
/lib/ directory in the classpath in the 
pom.xml

What is the simplest way to specify a directory (and all jars underneath
this directory) to be in the maven classpath when it compiles .java classes
and builds a .jar?

The directory is not in my git repo or any directory under my IDE project
files.

I have a requirement to create a pom.xml that will reference the current
project, and external jars in a /lib/ directory.
--

The requirement is to put together a pom.xml for a maven build that depends
on jars in:

$TOMCAT_HOME/webapps//WEB-INF/lib/

I want to reference that location directly in the maven pom.xml file and
not copy the /lib/*.jar files to another directory under my git repo.

The .../WEB-INF/lib/ contains .jar files that contains classes that my
project imports.

The jar that is then built will be put into:
$TOMCAT_HOME/webapps//WEB-INF/lib/ to extend the product as
per the vendor instructions.
--

If anyone has had this exact issue, and has a reference pom.xml that can be
pasted here, it would be extremely helpful and get me going quickly.
--

Irrespective of the deployment part where I copy the jar to
/webapps//WEB-INF/lib/, I would be happy to just get files
under /src/com/.../.java/ compiled and put into a jar in the /target/
directory

Re: Why does POM have precedence over -D property expressions?

[Bernd Eckenfels]

Hello,

While I do agree that it is not very intuitive, I don’t think there is any 
chance to change this in a compatible way.

 Also it’s pretty easy to understand: just remember this simplification: you 
can only define properties, and if the configuration should be affected by them 
you need to have a property explicitly in the POMs or as implicated default 
value. With this info in mind Mojo Docs are much easier to read ;)

Gruß
Bernd
--
https://Bernd.eckenfels.net


Von: Andreas Sewe 
Gesendet: Mittwoch, September 16, 2020 10:02 AM
An: users@maven.apache.org
Betreff: Re: Why does POM  have precedence over -D property 
expressions?

Andy Feldman wrote:
>> My situation is unfortunately a bit more complex than that, as I have
>> *two* s of the maven-enforcer-plugin, only one of which
>> should be affected by -DskipChecks. The other simply uses the
>>  rule, which IMHO shouldn't easily be disabled (but
>> should still respect -Denforcer.skip)
>> [...]
>> What I want is this:
>> [...]
>
> -Denforcer.skip, being the more direct option, should
>> take precedence over -DskipChecks.
>
> Just an idea:
>
> 
>   false
>   ${enforcer.skip}
> 
>
> This way if you set -DskipChecks=true, then only checks would be
> skipped, but if you set -Denforcer.skip=true, it would also cause
> skipChecks to be true, so both executions would be skipped. I haven't
> actually tested it though.

Thanks, Andy. The above does have the desired behavior *if* the
maven-enforcer-plugin were the only plugin which should be governed by
-DskipChecks.

But as I said in my initial mail, that property should also control the
maven-checkstyle-plugin, maven-tidy-plugin, and others (kine of like
-DskipTests does for maven-surefire-plugin and maven-failsafe-plugin).
And that's just not doable with

  ${enforcer.skip}

I experimented quite a bit yesterday and have become convinced that the
desired behavior is not possible, at least without profiles (ugh!) --
and even then I am not sure, as the profile would need to affect only
some executions.

But maybe I am missing something.

Best wishes,

Andreas

Re: Strange maven sonar download warning?

[Bernd Eckenfels]

Wonder where the questionmark is coming from... is there somewhere in the Pom?


--
http://bernd.eckenfels.net

Von: Enrico Olivelli 
Gesendet: Sunday, August 30, 2020 8:24:49 AM
An: Maven Users List 
Betreff: Re: Strange maven sonar download warning?

Il Dom 30 Ago 2020, 05:52 Dan Tran  ha scritto:

> don't see similar warnings when using with sonar-maven-plugin-3.6.x
>
> -D
>
> On Sat, Aug 29, 2020 at 8:13 PM Dan Tran  wrote:
>
> >
> > Hello to all
> >
> > I am seeing the bellow warning at my build with no build failure.  Wonder
> > if anyone else sees the same thing?
> >
> > *19:22:30*  [WARNING] The POM for
> org.sonarsource.scanner.maven:sonar-maven-plugin:jar:?3.7.0.1746 is
> missing, no dependency information available*19:22:30*  [WARNING] Failed to
> retrieve plugin descriptor for
> org.sonarsource.scanner.maven:sonar-maven-plugin:?3.7.0.1746: Plugin
> org.sonarsource.scanner.maven:sonar-maven-plugin:?3.7.0.1746 or one of its
> dependencies could not be resolved: Failure to find
> org.sonarsource.scanner.maven:sonar-maven-plugin:jar:?3.7.0.1746 in
> https://my.inernal.maven .repo
> was cached in the local repository, resolution will not be reattempted
> until the update interval of brs has elapsed or updates are forced
>

Probably you had problems during the download of some file.

You can try to run your build with -U flag or clean up your .m2/repository
directory, this way you will start with a clean local repository (that's
basically a cache)

Enrico


>
> >
> > Thanks
> >
> >
> > -D
> >
> >
>

Re: maven failsafe plugin & POJO tests

[Bernd Eckenfels]

Hello,

The failsafe IntegrationTestMojo essentially is the surefire plugin (but with a 
different error lifecycle handled by the verifyMojo) and a different default 
include filter.

https://github.com/apache/maven-surefire/blob/master/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java#L223

I would have expected it only supports Junit4/5 and TestNG conventions (I.e. 
@Test annotations)

BTW one option would be to deliver a single regular JUnit annotated Test which 
dynamiclly introspective or calls the spring test wrapper - I don't know much 
about spring testing but I would asume such a thing already exists.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Nigel Jones 
Gesendet: Thursday, July 2, 2020 6:37:42 PM
An: users@maven.apache.org 
Betreff: maven failsafe plugin & POJO tests

I have some 'integration' tests that have been written as POJOs. They run 
manually

I'm looking at refactoring to automate, making use of the failsafe plugin, 
together with a few other plugins to launch a server process, and configure the 
server against which the integration tests run.

I'm struggling to get failsafe to call any tests...

We have a 300+ multi module maven project. A significant amount of those 
projects contribute to a spring boot application - this is all built/assembled 
through maven.

When the pojo tests were written, they were added as a regular maven module. As 
such the source is in the usual source folders, not test ... so I have added 
configuration like

   
${project.build.sourceDirectory}

${project.build.outputDirectory}

The classes didn't follow the failsafe naming convention, so I added:

   
 **/*.java
 **/*.java
 

This isn't where I finally want to get to (refactoring to naming conventions 
will be clearer for the future) but as a demonstration/first pass, I thought 
this would be a sensible evolutionary approach.

The tests themselves are not written using any framework like junit/testNG, and 
require input/parms, but in a class which begins:

 package org.odpi.openmetadata.accessservices.subjectarea.fvt;
// imports
 public class GlossaryFVT {

I could add a method like:

public static void testGlossary()
 {
 try {
 runIt("https://localhost:10443;, "fvtserver", "garygeeke");
 } catch (Exception e) {
 // Test method - so ok to do this
 Thread.dumpStack();
 }
 }

(here runIt is an existing method, which is also called via a main() entry 
point - but that's not of interest in  migrating to failsafe)

Not only is the method not reported by failsafe, but the class isn't either. 
For the method, I also tried prepending/appending with 'test' , 'Test', 'IT' 
but couldn't get any combination working. The code on github (for surefire) 
hinted at Test, but the docs refer to IT

In the actual source directory I have a number of classes:

CategoryFVT.java  GlossaryFVT.java  
RunAllFVTNow.java
CategoryHierarchyFVT.java GraphFVT.java 
SubjectAreaDefinitionCategoryFVT.java
EffectiveDatesFVT.javaProjectFVT.java   
SubjectAreaFVTCheckedException.java
FVTConstants.java RelationshipsFVT.java 
TermFVT.java
FVTUtils.java RunAllFVT.java

and when I run I actually get some of these classes picked up by surefire for 
example:

[INFO] --- maven-failsafe-plugin:3.0.0-M5:integration-test (local) @ 
subject-area-fvt ---
[INFO]
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] Running org.odpi.openmetadata.accessservices.subjectarea.fvt.FVTConstants
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 s 
- in org.odpi.openmetadata.accessservices.subjectarea.fvt.FVTConstants
[INFO] Running org.odpi.openmetadata.accessservices.subjectarea.fvt.RunAllFVT
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s - in 
org.odpi.openmetadata.accessservices.subjectarea.fvt.RunAllFVT
[INFO] Running org.odpi.openmetadata.accessservices.subjectarea.fvt.RunAllFVTNow
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 s 
- in org.odpi.openmetadata.accessservices.subjectarea.fvt.RunAllFVTNow
[INFO] Running org.odpi.openmetadata.accessservices.subjectarea.fvt.FVTUtils
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 s 
- in org.odpi.openmetadata.accessservices.subjectarea.fvt.FVTUtils
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

Interesting ... in fact I changed the includes to '**/*.FVT' as these represent 
the 

Re: 'mvn clean test' crashes

[Bernd Eckenfels]

Has the machine enough ram free? Did you try a reboot (sometimes windows memory 
map seems to be fragmented in a way that java can't start). Does your Pom 
overwrite command line and/or specify a very big or very small heap? Any crash 
dumps or hs_err files?

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Mukul Gandhi 
Gesendet: Wednesday, July 1, 2020 10:47:45 AM
An: Maven Users List 
Betreff: Re: 'mvn clean test' crashes

Hi Enrico,

On Wed, Jul 1, 2020 at 1:13 PM Enrico Olivelli  wrote:

> I suggest you to debug that test, with an IDE or just by adding some
> System.out.println
>

When I run only the tests present in offending java class
(com.haldiram.business.helper.test.ApplnHelperTest), from within the IDE,
all the tests in the class pass.

But, when I run all the tests present within my aggregated Maven project
(multi module Maven project), using the command 'mvn clean test', the Maven
build failure says following,

[ERROR] Crashed tests:
[ERROR] com.haldiram.business.helper.test.ApplnHelperTest
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
...

All of the above, were done on a Windows workstation.

Also, when a Jenkins build pipeline invokes the command 'mvn clean test' on
a Linux system for all of my same codebase, all the tests pass and Maven
build succeeds there.

I've a strong feeling that, all my unit tests have no issues from the tests
code perspective. I feel, there could be some other issue, that I'm unable
to solve at this moment. Any further pointers to solve the issues I've
mentioned in this thread would be welcome.




--
Regards,
Mukul Gandhi

Re: 'mvn clean test' crashes

[Bernd Eckenfels]

Anything in the mentioned dump files? Could be a environment variable problem 
or corrupted Java Home (less likely a problem in the test code).

You can also try to specify -DskipTests to see if the rest of the Maven build 
works.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Mukul Gandhi 
Gesendet: Wednesday, July 1, 2020 7:08:50 AM
An: users@maven.apache.org 
Betreff: 'mvn clean test' crashes

Hi all,
I've been facing some problem during last few weeks, when using the
'mvn clean test' command to run unit tests within my Maven project. At some
point before when this issue is creating problem for me, the 'mvn clean
test' command was working fine with me and all unit tests within my Maven
project were passing. But I'm yet unable to find the reason, why 'mvn clean
test' command is not working for me now.

When I run the command 'mvn clean test' now, my Maven build fails and
following error trace is emitted,

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time:  05:51 min
[INFO] Finished at: 2020-07-01T09:44:06+05:30
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test)
on project haldiram-restapis: There are test failures.
[ERROR]
[ERROR] Please refer to
F:\eclipseWorkspaces\haldiram_backend_sprint-19_sts\haldiram-backend\haldiram-restapis\target\surefire-reports
for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump,
[date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash
or System.exit called?
[ERROR] Command was cmd.exe /X /C "C:\jdk1.8.0_241\jre\bin\java -jar
C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817\surefirebooter5568422068326404815.jar
C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817
2020-07-01T09-38-42_797-jvmRun1 surefire5010876784124620015tmp
surefire_07470042422408053869tmp"
[ERROR] Process Exit Code: 0
[ERROR] Crashed tests:
[ERROR] com.haldiram.business.helper.test.ApplnHelperTest
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The
forked VM terminated without properly saying goodbye. VM crash or
System.exit called?
[ERROR] Command was cmd.exe /X /C "C:\jdk1.8.0_241\jre\bin\java -jar
C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817\surefirebooter5568422068326404815.jar
C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817
2020-07-01T09-38-42_797-jvmRun1 surefire5010876784124620015tmp
surefire_07470042422408053869tmp"
[ERROR] Process Exit Code: 0
[ERROR] Crashed tests:
[ERROR] com.haldiram.business.helper.test.ApplnHelperTest
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
[ERROR] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR] at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[ERROR] at

Re: PKIX path building error with Azul ZULU Open JDK 14

[Bernd Eckenfels]

Hello,

Are you talking about Maven Central, are private Repo or maybe some Proxy 
certificate? Normally the default cacerts trust Store contains a root 
certificate which is used by Maven central (and other public sites). For a Repo 
with company certificate you normally add the company root ca once.


--
http://bernd.eckenfels.net

Von: Raghavendra Chilakalapudi (rchilakalapu) 
Gesendet: Tuesday, June 16, 2020 11:56:18 AM
An: users@maven.apache.org 
Betreff: Re: PKIX path building error with Azul ZULU Open JDK 14

Thanks for the reply.
When I add the maven certificate to JRE certs, its working fine.
But every time there is change at maven side, I need to add the certification 
again.
Is there anything we can add to the setttings?

Thanks,
Raghavendra CH

On 2020/06/16 09:23:19, Michael Osipov  wrote:
> Am 2020-06-15 um 14:54 schrieb Raghavendra Chilakalapudi (rchilakalapu):>
> > Hi,>
> > >
> > Query :>
> > I am using Azul Zulu Open JDK (14.0)  and planning to integrate with Maven.>
> > But getting following error when running mvn command for archetype plugin :>
> > >
> > PKIX path building failed: 
> > sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> > valid certification path to requested target.>

> > >
> > Do I need to add anything specific in settings.xml for resolve this 
> > certification issue?>
> > >
> > Could you please help me out to resolve the issue as soon as possible.>
>
> This is not Maven problem. Add your CA to cacerts.>
>
> ->
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org>
> For additional commands, e-mail: users-h...@maven.apache.org>
>
>

Re: not storing/getting artifacts in/from local repository

[Bernd Eckenfels]

If you turn on debut logging for the build you can grep for the artifact name. 
In your specific case however I guess it's found in the relative parent of your 
project. An other option might be any profile which is auto activated.

Btw you can use the build helper plugin and ask it to produce the effective 
Pom, it should be the same for both system. You can also let it list (active) 
profiles.

https://maven.apache.org/plugins/maven-help-plugin/effective-pom-mojo.html

https://maven.apache.org/plugins/maven-help-plugin/active-profiles-mojo.html

Effective settings and help:system could also show differences.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Enrique Mingorance Cano 
Gesendet: Friday, May 8, 2020 2:09:42 PM
An: users@maven.apache.org 
Betreff: not storing/getting artifacts in/from local repository

Hello,

I have a question about how I can see an artifact being taken. Let me
explain the situation.

This is more a question than a bug itself (I guess so)

I have two machines:

   - I build the same project https://github.com/kiegroup/appformer/ from
   both of them.
   - same maven version in both of them 3.5.2
   - same settings.xml in both of them
   - clean repository ~/.m2/repository in both of them
   - both of them show the same DEBUG informationThis is more a question
   than a bug itself (I guess so)

[DEBUG] Reading global settings from
/opt/tools/apache-maven-3.5.2/conf/settings.xml
[DEBUG] Reading user settings from /home/user/settings.xml
[DEBUG] Reading global toolchains from
/opt/tools/apache-maven-3.5.2/conf/toolchains.xml
[DEBUG] Reading user toolchains from /home/user/.m2/toolchains.xml
[DEBUG] Using local repository at /home/user/.m2/repository
[DEBUG] Using manager EnhancedLocalRepositoryManager with priority
10.0 for /home/user/.m2/repository


I run the command (-pl and -am to make the test faster) with OK in both of
them

/opt/tools/apache-maven-3.5.2/bin/mvn -s /home/user/settings.xml
-DskipTests clean install -pl :appformer-js -am

In the first machine:


   - the kie-parent and the rest of the artifacts are in the
   ~/.m2/repository folder (org/kie/kie-parent)

In the second machine:


   - the kie-parent IS NOT but some other artifacts in the ~/.m2/repository
   folder

so... my question is, *where should/can they be? How can I know where maven
is taking the kie-parent artifact from?*


Thanks a lot,
Kike.

Re: build maven project without setting compiler source and target

[Bernd Eckenfels]

Can you show the actual error message and give a concrete project? Normally 
Maven works with not specifying target/source as long as your JDK is recent 
enough. (But it's not ways a good idea, it's better to specify the properties 
(IDEs normally read them)


--
http://bernd.eckenfels.net

Von: java-cry...@cryptearth.de 
Gesendet: Monday, February 17, 2020 4:27:16 AM
An: users@maven.apache.org 
Betreff: build maven project without setting compiler source and target

So as I just got new into using Netbeans someone on its list explained
me, that it's just a gui wrapper around maven and it's adviced to get
the basics of maven to correctly use netbeans.
Ok, so as I just used a simple editor and a terminal it didn't mattered
wich version I compiled with or for in the past as I ran the class with
the same vm I compiled them with. So, the I thought I could just ommit
the setting - but maven just fails with an error that no source/target
version was specified. So I had them re-add by re-apply the project
settings.
Is there a way I could tell the compiler plugin just to ignore the
version but also to ignore if it's missing and just compile it with
whatever version I ran maven with?
It's basically: I use different systems all with different jdk installed
- so when just clone the most recent version from github I always have
to set the correct version manual as netbeans doesn't seem to be handle
that by itself - and I could find an option to just get rid of it at
all.

Thanks in advance,

Matt

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

Re: Central Index Location

[Bernd Eckenfels]

Index generation problems seems to be common on Maven central. You might want 
to ping the sonatype ops team directly. I did so via twitter and blog, not sure 
if there is still a way to raise a ticket, but hopefully that should help.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Polo 
Gesendet: Thursday, January 30, 2020 12:03:59 PM
An: users@maven.apache.org 
Betreff: Re: Central Index Location

Ping

> 2020年1月28日 下午7:34，Polo  写道：
>
> Hi, Maven Users
>
> I have a problem with the central index.
>
> From this page (https://maven.apache.org/repository/central-index.html 
> ), I learned that the 
> central index is updated weekly.
>
> But in the central repository (https://repo1.maven.org/maven2/.index/ 
> ) it was not updated since 2019-12-24.
>
> So, is the central index location or the generating method has been changed?
>
> Looking forward for any response.
>
> Lei Zhang

Re: warning 3.3.9

[Bernd Eckenfels]

> Booch  Grady told me industrial strength
> software is beyond the
> Intellect of maven developers .

Is that intended as an insult or just a joke I dont understand?

Greetings
Bernd

Re: repo.maven.apache.org returning 403 forbidden when running maven

[Bernd Eckenfels]

Hello,

If you suspect there is something it would require a ticket for Apache Infra I 
guess. But unless your Organisation got banned it’s more likely it’s a client 
side filter (proxy, firewall or appliance).

Did you look at the html source and possibly the http headers of that error 
response for any server names or other indications of origin. How is the error 
page Styled? Can you quote the HTML.

Can you read maven central?

Gruß
Bernd



--
https://Bernd.eckenfels.net


Von: Henke, Zachary 
Gesendet: Dienstag, Dezember 31, 2019 7:52 AM
An: users@maven.apache.org
Cc: Gawande, Sameer
Betreff: repo.maven.apache.org returning 403 forbidden when running maven

Hello,

My name is Zach Henke and I work at Verisign. I am currently receiving ERROR 
403: Forbidden when attempting to access http://repo.maven.apache.org/maven2/ 
via linux server. On that same server, I am able to access the maven website 
(http://maven.apache.org/) which indicates public internet access. I am able to 
reach http://repo.maven.apache.org/maven2/ in browser from my local machine on 
a different IP/network than the linux server. These points make me think there 
is a blacklist of IPs in front of the maven repo causing the 403 Forbidden from 
the linux server. Anyone know how to confirm my IP isn’t in a blacklist? Any 
other suggestions to avoid the repo 403 issue would be great.

Thanks,
Zach

Re: Overriding plugin configuration via commandline

[Bernd Eckenfels]

yes user properties for plugins only work for default values. If you want to  
allow overwrite, you need to define the default as a property and overwrite it 
with system property or in a profile and the use the property in the plugin 
config.

Be aware that it is a good thing if a Pom without external config can be used 
for reproducebable builds, I would therefore use it only for limited cases.

Gruss
Bernd


--
http://bernd.eckenfels.net


Von: m...@mherrn.de
Gesendet: Freitag, November 29, 2019 10:00 PM
An: users@maven.apache.org
Betreff: Overriding plugin configuration via commandline

Hi,

When I specify a property for a plugins goal on the command line, like:

mvn kilt:reformat -Dformat=" = \n"

this works as expected, as long as this property (in this case "format")
isn't set in the pom for that plugin. Otherwise the configuration in the
pom.xml apparently takes precedence before the parameter that is given on
the command line. I would expect it the other way around.

This is the definition of the above mentioned property in the ReformatMojo:

@Parameter(property="format", defaultValue = " = \\n",
required = true)
private String format;

Do I need to configure something differently in the Mojo to be able to
override settings that are already set in the pom.xml?


(If someone is curios: the above mentioned plugin is this one:
https://github.com/hupfdule/kilt/tree/master/kilt-maven-plugin)


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

Re: Using the .m2 directory for deployment

[Bernd Eckenfels]

Hello,

Actually Karaf (OSGi) can watch and deploy bundles directly from the/a local 
repository. This means it will pick up artifacts as soon as they are locally 
installed. This works fine for quick turn-arounds in dev environments. I am not 
so sure if it is a good idea for production deployments (especially if it would 
need to watch a larger number of artifacts).

Gruss
Bernd

--
http://bernd.eckenfels.net


Von: Anders Hammar 
Gesendet: Mittwoch, November 20, 2019 4:32 PM
An: Maven Users List
Betreff: Re: Using the .m2 directory for deployment

Typically you should never access the local Maven repo directly, but use
Maven (or a Maven lib) for that. It would then handle download of any
dependency missing etc.

I think you're trying to do something "clever" by bypassing Maven and/or
the idea of Maven repositories. It could work, but you could very well run
into issues. One such issue is when people used to Maven assume you're
doing it in some way, but in fact you're doing it some other way.
I suggest that you follow Maven's best-practices and create a remote repo
where you deploy your artifacts. The during deployment you download from
there. A repository manager is more a less a must today and will give you
lots of other benefits (audit, auth, etc.).

/Anders

On Wed, Nov 20, 2019 at 4:01 PM Kruse, Stephen S 
wrote:

> Thanks for the response Anders! My question is would you ever use your
> local .m2/repository for you deployment since that in theory should contain
> all of your dependencies? Do you foresee any issues with doing this?
>
> Thanks,
> Steve
>
> -Original Message-
> From: Anders Hammar 
> Sent: Wednesday, November 20, 2019 8:23 AM
> To: Maven Users List 
> Subject: Re: Using the .m2 directory for deployment
>
> The .m2/repository folder i a local Maven repository, which is local for
> one machine. What you want to do is to deploy (Maven lingo for publish) to
> a repository manager (such as Nexus och Artifactory for example). You
> deployment script/system can then download from the repo manager and
> perform the deployment.
>
> /Anders
>
> On Wed, Nov 20, 2019 at 1:47 PM Kruse, Stephen S 
> wrote:
>
> > Hi,
> >
> >
> >
> > I am looking into possible deployment strategies with maven to support
> > the current project I’m working on. One strategy I am thinking about
> > is to use the .m2 for deployment as well as the development
> > environment. I have not seen anyone else talk of using the .m2 for
> > deployment purposes and was hoping that I could get a good
> > understanding of why. One benefit I foresee is having the same
> > environment used for both the development and runtime environment. Any
> thoughts are much appreciated.
> >
> >
> >
> > Thanks,
> >
> > Steve
> >
> >
> >
> > H Stephen Kruse
> >
> > General Dynamics (GD-MS)
> >
> > 12450 Fair Lakes Cir, Fairfax, VA 22033
> >
> > BYG-1/TCS Software Lead
> >
> > Office: (703) 272-1774
> >
> >
> >
> >
> >
>

Re: -D args not propagating from release plugin invocation

[Bernd Eckenfels]

Normally you need to use the -Darguments="-Dexec.skip=true" for the release 
plugin to pass on options to the child invocations.

mvn -DdryRun -Dexec.skip=true -Darguments="..." release:prepare

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Dani 
Gesendet: Mittwoch, November 20, 2019 11:30 AM
An: users@maven.apache.org
Betreff: -D args not propagating from release plugin invocation

Greetings.

I'm having trouble running a sentence like this:
"$> mvn release:prepare -DdryRun -Dexec.skip=true"

With this configuration:
"
...



org.apache.maven.plugins
maven-release-plugin
2.5.3


org.codehaus.mojo
exec-maven-plugin
1.2.1


test

java




com.globera.Main

environmentProperties

${exec.skip}




...
"

While defining the property inside the POM as:
"

true

"
Runs smoothly with "$> mvn release:prepare -DdryRun"

That configuration works fine too with other phases or goals when passed as
command line argument, so the guess, by this two reasons is the plugin is
flawed.

Actual output to ' mvn release:prepare -DdryRun -Dexec.skip=true' is:
...
[INFO] --- exec-maven-plugin:1.2.1:java (default) @ some-execution ---
11:13:59,288 INFO c.g.Main Parameter passed to main class =
environmentProperties (which is the hard coded literal in config of exec
plugin)

Which should not been executing, due to -Dexec.skip=true

If you have any hint on how to circumvent this, it will be much appreciated.

Best regards.
--
Saludos
***
Daniel G. Gamonal
Sistemas de Informacion
***

Re: Maven local repo in a common global directory for multiple parallel execution

[Bernd Eckenfels]

Hello,

It is the other way around, there might be situations where one job relies on 
the installed artifacts from the other, in this case you would need a shared 
Repo. It is however bad style. In all other cases you can use a executor- or 
even workspace-local local repository if you have enough space.

The advantage of avoiding concurrent access is that you get less influences 
from one job to the other (especially if you work with snapshots or multiple 
different upstream artifacts with same version in different Repos) and that 
there is no concurrent downloads (which in itself sometimes leads to checksum 
errors).

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Debraj Manna 
Gesendet: Montag, Mai 27, 2019 11:29 AM
An: Maven Users List
Betreff: Re: Maven local repo in a common global directory for multiple 
parallel execution

Yes disk required will be more .

I don't have a requirement where one of my projects requires artifact
created by another. So I can use a common local repo for all parallel
executions?

On Mon, May 27, 2019 at 11:34 AM Golan, Yaron 
wrote:

> Please remember that you need much bigger disk space as you are
> duplicating binaries.
>
>
> -Original Message-
> From: Debraj Manna 
> Sent: Sunday, May 26, 2019 4:49 PM
> To: Maven Users List 
> Subject: Maven local repo in a common global directory for multiple
> parallel execution
>
> I have a machine in which multiple parallel maven execution happen . Each
> execution executes the below command in a seperate workspace directory
>
> mvn -f main/pom.xml clean package -DskipTests -T 6
>
> Can someone let me know should I use a seperate maven local repo path (
> -Dmaven.repo.local=$MAVEN_REPO) for each execution or I can use a common
> .m2 directory for all parallel runs? What is the best practice?
>
>
> - Maven Version 3.5
> - Java 8
>

Re: Error occurred during mvn deploy

[Bernd Eckenfels]

You can try to open them with jar or an archived or compare them with the 
central Repo (checksum). If they are incomplete/different or corrupt (maybe 
contain a html error page) just delete them and run `man package` again.

Du you have unfiltered Internet Access?

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: 王聡 
Gesendet: Mittwoch, April 10, 2019 12:29 AM
An: users@maven.apache.org
Betreff: Error occurred during mvn deploy

Hello all,

I built a project and used several java library in my project, but I got some 
errors during mvn deploy whichi seemed frustrated.
The error log showed:

[ERROR] error: error reading 
/root/.m2/repository/org/slf4j/slf4j-api/1.7.25/slf4j-api-1.7.25.jar; zip END 
header not found
[ERROR] error: error reading 
/root/.m2/repository/ch/qos/logback/logback-classic/1.2.2/logback-classic-1.2.2.jar;
 zip END header not found
[ERROR] error: error reading 
/root/.m2/repository/com/fasterxml/jackson/core/jackson-databind/2.8.7/jackson-databind-2.8.7.jar;
 zip END header not found

Actually these jar files are public libraries downloaded from repository, but 
seems not worked properly.
Is there any advice on this problem?

P.S. My maven version:

$ mvn --version
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T18:41:47Z)
Maven home: /usr/share/maven
Java version: 11.0.3, vendor: Oracle Corporation, runtime: 
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "4.14.51-60.38.amzn1.x86_64", arch: "amd64", family: 
“unix"

maven-compiler-plugin
3.6.1

maven-jar-plugin
3.0.2

maven-dependency-plugin
3.0.0

maven-javadoc-plugin
2.10.4

maven-deploy-plugin
2.8.2

Regards.
C.Wang

Re: Enforce rules defined outside the pom.xml or its parent

[Bernd Eckenfels]

It’s not what you where asking, but many rules can  and should be put into a 
common parent - helps with local builds as well.

Maven enforcer can use rules on the command line it seems: 
https://issues.apache.org/jira/plugins/servlet/mobile#issue/MENFORCER-142

Besides that some static analysis with your own plugin or tools like jqassist 
can be run in CI Jobs also.

Gruß
Bernd

--
https://Bernd.eckenfels.net


Von: Martin D'Aloia 
Gesendet: Mittwoch, März 27, 2019 6:46 PM
An: users@maven.apache.org
Betreff: Enforce rules defined outside the pom.xml or its parent

Hello,

Is it possible to enforce a set of rules defined outside the pom.xml being
built (i.e. not defined in the current pom or in a parent pom)?

Ideally, I would like to define maven-enforcer-plugin rules in an external
pom.xml and evaluate them over the pom.xml being build in order to not
force to use a specific parent pom.

*CONTEXT:*
I'm defining a CI/CD pipeline and I would like to enforce a set of rules
over the pom.xml in order to be deployed to our internal repository (sort
of validations performed to publish to Maven Central).

Thanks in advance for any suggestions!

Re: Failsafe: Killing self fork JVM. PING timeout elapsed.

[Bernd Eckenfels]

I guess a timeout caused by FullGC can happen with TCP as well. Increasing the 
timeout might not be nice but does look like it would help in both cases. 
(Problems with stdout are more related to unexpected JVM messages I guess)

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Mikael Åsberg 
Gesendet: Mittwoch, März 20, 2019 9:40 AM
An: Maven Users List
Betreff: Re: Failsafe: Killing self fork JVM. PING timeout elapsed.

These issues regarding communication with forked JVMs, won't they be
resolved once surefire moves to interprocess communication using
tcp/ip sockets? This happens to be the target feature to be included
in the next surefire 3.0.0 milestone:
https://issues.apache.org/jira/projects/SUREFIRE/versions/12344668

There are s many issues relating to surefire reading stdout of
forked processes (which is my understanding that it is currently
doing). Many of us are really looking forward to the next milestone.

On Tue, Mar 19, 2019 at 8:59 PM Jason Young  wrote:
>
> Getting back to my original questions, I know that "ping" means to see if a
> process is there, and "NOOP" implies it's not a command to do anything. But
> what do the terms "ping" and "NOOP" mean in this context, i.e. how do the
> processes communicate? I assume they don't sonar. Do other processes also
> ping NOOPs? Can I PING Chrome with a NOOP from bash? Is it with TCP?
>
> I'm confused about what I should do regarding GC pauses. Previously I had
> code that would write the amount of remaining heap space (or something like
> that) to stdout after every test to troubleshoot OOMEs. Can writing to
> stdout cause the communication failure somehow?
>
> On Wed, Mar 13, 2019 at 5:57 PM Jason Young 
> wrote:
>
> > I upgraded failsafe and surefire to 3.0.0-M3 as advised; we encountered
> > the same exception. (Still using -Xmx5g, will switch to OpenJ9 soon in case
> > that helps.)
> >
> > BTW I also asked on StackOverflow previously, for anyone interested:
> > https://stackoverflow.com/questions/54755846/killing-self-fork-jvm-ping-timeout-elapsed
> >
> > On Tue, Feb 26, 2019 at 6:40 PM Jason Young 
> > wrote:
> >
> >> Thanks again for the information.
> >>
> >> We had increased the RAM to 3g some time ago to prevent OOMEs. More
> >> recently, I increased the RAM again to 5g for extra headroom since we had
> >> more headroom available; the problem hasn't happened since, but it hasn't
> >> been very long.
> >>
> >> We use a more customized image based on Alpine 3.8.2. The JDK and Maven
> >> are obtained via apk.
> >>
> >> I will try upgrading failsafe (and surefire while I'm at it) sooner, and
> >> probably do some experimentation with JVMs another time (not pressing for
> >> me ATM).
> >>
> >> On Tue, Feb 26, 2019 at 12:20 PM Tibor Digana 
> >> wrote:
> >>
> >>> >> I'll try to enable some logging about GC pauses to see what's up
> >>>
> >>> Pls do not keep such setting after tuning the GC because this may
> >>> sometime
> >>> break the interprocess communication between Maven process and surefire
> >>> process.
> >>> It's worth to list GC information in a file and not in the console logs.
> >>> This can be configured, I guess.
> >>>
> >>> >> Do you think the value is simply too low?
> >>>
> >>> GCing many objects may take some time and I remember we had a user who
> >>> had
> >>> this problem a year or two ago.
> >>> We check every third NOOP (which is 3 x 10 sec) as a fix instead of every
> >>> NOP. So 30 seconds looked satisfactory.
> >>> I think you use old version 2.20 or something like that. The fixes for
> >>> docker have been done so far, so please use the latest version 3.0.0-M3.
> >>> See this page
> >>> https://maven.apache.org/surefire/maven-surefire-plugin/docker.html, we
> >>> used maven:3.5.3-jdk-8-alpine in this test. Which base image did you use?
> >>>
> >>> Cheers
> >>> Tibor
> >>>
> >>> On Tue, Feb 26, 2019 at 5:24 PM Jason Young 
> >>> wrote:
> >>>
> >>> > Thanks for the information. It's good to see someone understands a
> >>> little
> >>> > about this.
> >>> >
> >>> > Incidentally, we have been looking at other GCs and VMs for the
> >>> application
> >>> > in production environments, so I'll look into how these affect tests as
> >>> > well. I'll try to enable some logging about GC pauses to see what's up.
> >>> >
> >>> > How would `-Xmx3g` cause long GC cycles? Do you think the value is
> >>> simply
> >>> > too low?
> >>> >
> >>> > FWIW we're running the Maven build in an Alpine-based Docker container.
> >>> >
> >>> > On Sat, Feb 23, 2019 at 6:36 AM Tibor Digana 
> >>> > wrote:
> >>> >
> >>> > > Hi Jason,
> >>> > >
> >>> > > We spoke about this issue on our chat in ASF Slack:
> >>> > > "I think his tests have been paused for a long GC periods and timed
> >>> out
> >>> > 3x
> >>> > > PING period = 30 seconds. After this period forked JVM supposed the
> >>> Maven
> >>> > > process was killed by JenkinsCI and therefore all surefire processes
> >>> are
> >>> > > killed as well and all the 

Re: Confusion with Dependency Paths

[Bernd Eckenfels]

Hello,

to add to this, after moving the source to src/main/java/* and Fixing the POM 
(removing the source path and potentialla the resource plugin) you can use 
eclipse alt+f5 t refresh from the pom, this will configure the ecplise Project 
layout (.classpath) to detect the same source Folders so it can work in 
combination with Maven.

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Marco Schulz
Gesendet: Montag, 4. Februar 2019 21:40
An: users@maven.apache.org
Betreff: Re: Confusion with Dependency Paths

Hey Dennis

Sorry for the late reply but I was all the day traveling by train and here in 
Germany the railway companies don't know as well that internet still exist :-)

I checked your pom - you did some semantic mistakes. I am quite sure this file 
is not generated by eclipse and heavy manually edited.
I attached you a change version. below I explain you a bit the entries.

As first please try to use as beginner the standard maven conventions about 
directory structures

java files goes to: src/main/java - this passes the compiler
non java files like xml goes to: src/main/resources - maven put everything well 
together

the output you will find in /target

I hope this helps you.

.regards
.marco

http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>;
4.0.0

KCBSEvents
KCBSEvents
0.0.1-SNAPSHOT

pom






maven-compiler-plugin
3.7.0

1.7
1.7






commons-io
commons-io
2.5


org.apache.httpcomponents
httpclient
4.5.6


org.apache.httpcomponents
httpcore
4.4.10


commons-codec
commons-codec
1.10


commons-logging
commons-logging
1.2





On Mon, 2019-02-04 at 08:48 -0500, Dennis Putnam wrote:
Hi Marco,

Thanks for the reply. Here is my pom.xml:


http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>

  4.0.0

  KCBSEvents

  KCBSEvents

  0.0.1-SNAPSHOT

  

src



  

src



  **/*.java



  





  

maven-compiler-plugin

3.7.0



  1.7

  1.7



  



  

   



commons-io

commons-io

2.5





org.apache.httpcomponents

httpclient

4.5.6





org.apache.httpcomponents

httpcore

4.4.10





commons-codec

commons-codec

1.10





commons-logging

commons-logging

1.2



   





I'm not sure what you mean by the exact error as the part I didn't post was 
just the source info. FWIW, here is the exact error:

 [javac] /usr/build/src/KCBSEvents/Helpers.java:36: error: package 
org.apache.commons.io does not exist
[javac] import org.apache.commons.io.IOUtils;
[javac] ^


I don't think I know what the DependencyManagement section is. I have 
, isn't that the correct section?


On 2/3/2019 1:59 PM, Marco Schulz wrote:

Hi Dennis


I suppose you use a simple Maven Project configuration. May you added the 
Dependency manually. Whitout seeing the exact error in the cmd and your pom I 
guess you added the dependency in the DependencyManagement section. You need to 
use the Dependencies section.


regards

.marco


Get Outlook for Android




From: Dennis Putnam 

Sent: Sunday, February 3, 2019 7:51:20 PM

To: users@maven.apache.org

Subject: Confusion with Dependency Paths


I have a Maven project that was created using Eclipse. The application

is working fine but I am having a problem compiling with 'javac'. I'm

getting the following compile error:


 error: package org.apache.commons.io does not exist


However, the build path contains:


../repository/commons-io/commons-io/2.5


When I added the dependency I specified:


GroupID: commons-io

Artifact: commons-io

Version: 2.5


That 

Re: Crashes while running "Maven In Five Minutes"

[Bernd Eckenfels]

I did: https://github.com/apache/maven-site/pull/57

BTW: should Maybe the minimal Java Version in the generated pom be an parameter 
or depend on the currently used runtime?

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Hervé BOUTEMY
Gesendet: Samstag, 8. Dezember 2018 01:51
An: Maven Users List
Betreff: Re: Crashes while running "Maven In Five Minutes"

Thank you for the report: yes, this should be improved to work in current 
latest version of everything

I updated the command line to use version 1.3 of maven-archetype-quickstart, 
which is the latest version and compiles with Java 7 target.

Unfortunately, when build with Java 11, the build now fails during tests with 
a known NPE issue: we need a new version of the archetype with updated maven-
surefire-plugin versions that has this issue fixed (I just created 
MARCHETYPES-63 [1] to track the fix)...

Once the version 1.4 of the archetype will be released, we'll have to update 
the documentation.

While waiting the updated archetype, don't hesitate to use the "edit" button 
in the breadcrumb and provide a Pull Request to explain about the current 
failure with Java 11 that will be fixed soon...

Re: How to rewrite POMs retaining the XML structure

[Bernd Eckenfels]

The Release Plugin does rewrite branch/version and does an exceptionally bad 
job since you have to manually configure the indention. Would be good to have a 
common utility for that.

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Marc Rohlfs 
Gesendet: Freitag, November 30, 2018 1:42 AM
An: users@maven.apache.org
Betreff: How to rewrite POMs retaining the XML structure

Hi all,

is there a way to rewrite pom.xml files without loosing formatting,
ordering and comments?

We need to (programmatically) do several changes on Maven POMs, e.g. adding
and removing dependencies and properties. Currently we're using
the MavenXpp3Reader and MavenXpp3Writer classes to read and write the
pom.xml files, but in the output files, all comments are removed, the XML
nodes are reordered and formatting (indentations, empty lines) is lost.
Does anybody know a way how to read and write POM files without loosing
formatting ordering and comments?

Best regards
Marc

Re: Security Questions - Maven

[Bernd Eckenfels]

Hello,

> 1) Is the software compliant with U.S. Federal Information Processing
Standard (FIPS) 140-2?

Maven is a modular open source, there is no single „Maven“ Body of work. When 
you use it, It dynamically uses plugins from various Sources, so it is hard to 
answer General Questions About ist properties. (and by Extension makes it hard 
to be certified to anything). Generally spoken most plugins use the Java VM and 
Standard libraries - so you could argue that most of ist cryptographic 
operations are done by the JCE in the JVM.

While there are JVM cryptographic extensions and JVMs which claim to be FIPS 
Level 1 compliant it is generally a very Long stretch to call software running 
on those to be FIPS compliant. Partially because FIPS has some quite impossible 
restrictions and require a tightly controlled Environment. (I spare us all the 
discussion how useful I think FIPS 140-2 certifications are)

> 2) Is any third party software bundled with the software?

Of Course - most of the Maven plugins use open source libraries from all over 
the world. The Software directly delivered with Maven core binary distributions 
is generally compatible with the ASL and requirements of the ASF for 
dependencies. This does not apply to all plugins

> 3) Can the software export security related audit trails to external 
> collection systems, such as syslog or ArcSight?

See my answer to 1, this seems to be a flawed understanding of development 
Tools. Having said that you can of Course parse Maven output in some specific 
context (or change ist log format). But it is more a Question of which CI, 
Repository and SCM Server to use – those would beneftit from Audit logs more 
than a command line tool.

> 5) Are user accounts required or optional?

Maven runs under the invoking user (which has to have an account on the 
development machine of course). There are some plugins which can interface with 
external Systems or require credentials for Services. Depending on how you set 
them up.

BTW: I cannot really say whats going wrong in this aquisition Evaluation but 
the questions do really not make much sense to an open source command line 
development tool. Instead of answering them I would question if the General 
classification which lead you to research them is correct.

Having said that, a secure Software development process/SDLC is a good thing to 
plan in advance, you should get some architects on board which can help you 
with that. A Requisition checklist wont do you any good for that.

Gruss
Bernd

Re: Ensuring artifact integrity with artifact pinning

[Bernd Eckenfels]

It’s an idea I also started a while back, but the problem is, it is not really 
a good security as long as you do the checksum Test before executing any 
plugins, which is a bit hard to do.
You find some older sample code here 
https://github.com/ecki/lockdep-maven-plugin

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Robert Scholte 
Gesendet: Dienstag, November 20, 2018 7:48 PM
An: Maven Users List
Betreff: Re: Ensuring artifact integrity with artifact pinning

Hi,

seems related to MNG-6026[1].

thanks,
Robert

[1] https://issues.apache.org/jira/browse/MNG-6026


On Tue, 20 Nov 2018 12:26:54 +0100, Andrew Todd 
wrote:

> Hello all,
>
> I am considering writing a Maven plugin to help improve confidence in the
> integrity of the Maven artifacts used by a project. I'm looking for
> feedback on this idea before I start working on it, hopefully this
> winter.
>
> Here's a brief overview of what I have in mind.
>
> Maven, like many other package and artifact managers, doesn't offer
> particularly strong protections against the compromise of artifacts. The
> situation has improved somewhat in the last few years, as more people
> have
> paid attention to the problem. When the central repository enabled HTTPS
> for everyone, it was a big step forward -- it's now much harder for
> someone
> to deliver a malicious package to you by intercepting your Web traffic,
> for
> instance. Central also requires code signing when artifacts are uploaded,
> which helps prevent the uploading of malicious artifacts somewhat.
>
> However, it's my understanding that there's no useful way for Maven
> clients
> to check those signatures -- not to mention that there's still other ways
> that a malicious or malformed package could be served to a Maven client.
> And any dependency in your application is a potential attack vector.
>
> You may have heard of Certificate Pinning:
> https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning, which adds a
> trust-on-first-use aspect to HTTPS certificates (and was not quite the
> right solution for the problem it was helping to solve; it's now
> deprecated).
>
> What I propose is a similar idea, but for Maven artifacts. When this
> plugin
> is enabled, each Maven build will generate a manifest of all artifacts
> that
> that build depends on, along with the hashes for all of those artifacts.
> This manifest could be committed into source control alongside the POM
> file. From that point on, the artifact is considered "pinned" to that
> hash
> value. If the plugin observes that any of the hashes it has already
> pinned
> have changed, the build will fail until a developer investigates and
> corrects the problem.
>
> Aside from improving trust, using this plugin could also help
> troubleshoot
> "works on my machine" errors with more transparency into the actual
> artifacts used in the build than is present in current tools such as mvn
> help:dependency-tree.
>
> Of course, this wouldn't work for SNAPSHOTs. I'm not sure how much more
> improvement can be made there. This plugin would also be inappropriate
> for
> environments where artifacts are routinely overwritten -- which is really
> not a good idea anyway. With more work the plugin could be configured to
> ignore specific artifacts.
>
> In the future, this plugin could also support publishing the manifest
> alongside your artifact in Central, so that someone else who depends on
> your artifact can determine that all transitive dependencies have been
> retrieved identically to how they were by the original developer.
>
> With a lot more support in the longer-term, this could move in the
> direction that Certificate Transparency has, towards public logs:
> https://en.wikipedia.org/wiki/Certificate_Transparency
>
> These measures, if adopted widely by Maven users, could help detect
> unexpected changes to artifacts in Central early, as well as help expose
> build stability problems. Building trust in computing is an incremental
> problem, and this would help move things a little in the right direction,
> in a backwards-compatible fashion.
>
> I'd like to hear your thoughts and suggestions -- not to mention hearing
> if
> you'd be interested in adopting such a tool. Obviously there's a number
> of
> details to hammer out.
>
>
> Thanks,
> Andrew

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

Re: help on installation issue

[Bernd Eckenfels]

Can you please show the whole input and output, what start directory did you 
use (don’t run it in c:\) and also provide the output of the set command.

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Marco Stocchi 
Gesendet: Dienstag, Oktober 23, 2018 11:20 PM
An: users@maven.apache.org
Betreff: help on installation issue

Hello...
I have donwloaded and copied the files of maven into my pc. I need to use
maven to build a java project.
when typing "mvn" on the cmd prompt, I get the following error

Error: -classpath requires class path specification

The internet suggests to mess up with the environment variables, I tried
all the solutions proposed but nothing worked for me.

Does anyone know what does this message mean?

Thanks

Re: Java 11 and java.xml.bin, etc.

[Bernd Eckenfels]

And in addition to Jörgs Questions, do we also have a canonical representation 
which replacements are actually preferred in ASL land?

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Jörg Schaible 
Gesendet: Freitag, September 14, 2018 1:16 AM
An: users@maven.apache.org
Betreff: Java 11 and java.xml.bin, etc.

Hi,

now with Java 11 not containing several jave.ee modules, what's the best
approach for a library that supports still Java 8? I guess profiles based
on the current Java version declaring the missing stuff as dependency are
a bad idea. Should a library developer add the new dependencies
nevertheless with compile/runtime scope or as provided or optional to move
the responsibility to the library users? What do you recommend?

Cheers,
Jörg



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

Re: Apache Struts 2.3.35 Upgrade - backward incompatibility in s:if

[Bernd Eckenfels]

Hello Miguel,

you Need to ask the Apache Struts Project (https://struts.apache.org/mail.html) 
instead.

Gruss
Bernd

-- 
http://bernd.eckenfels.net

Von: Miguel Almeida
Gesendet: Mittwoch, 29. August 2018 18:58
An: Maven Users List
Betreff: Apache Struts 2.3.35 Upgrade - backward incompatibility in s:if

We upgraded from 2.3.34 to 2.3.35 in one of our applications, but although
the upgrade is described as backwards compatible, we found a problem in the
UI.

The simplified example is as follows.
*Given* a JSP with:


foo


 bar


*And *scopesValues was previously set (, where scopes is a Listscopes in the action)

*When* the List scopes has [Portuguese Things, XXX]
*Then *the JSP will print: bar[Portuguese Things, XXX]


If I revert to 2.3.34:
*Then *the JSP will print: foo[Portuguese Things, XXX]


What could be causing this? Since this breaks one of our pages we are now
hesitant on what other places could break after the upgrade.

Kind regards,

Miguel

Re: maven - using multiple src directories

[Bernd Eckenfels]

Hello,

First of all the normal rule of thumb for Maven is, don’t fight it. If it uses 
by default one folder for main and test code then this is a good best practice 
which you should not divert from. Especially not for „multiple packages“, it is 
quite normal to have them all under a single source.

If there is a good reason to isolate those packages more it might be a strong 
hint to use multiple maven modules or projects.

If you chose to ignore that advice I would go with the build helper approach 
described on your stackoverflow link.

BTW: in case you want to build a multi-(jigsaw)module project I think there is 
not a clear definition for project layout yet, however having one module 
directory under main/java with one maven module per jigsaw module is the most 
classical structure.

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: angelo moreschini 
Gesendet: Mittwoch, August 1, 2018 8:47 AM
An: users@maven.apache.org
Betreff: maven - using multiple src directories

Hi,

I am new to maven.

Actually I am able to compile and run a simple java project (if all the
classes are in the same source directory).

As well this, to progress in my learning (because the java language have
the package structure to group classes inside directories) I need to be
able to write java classes also inside multiple source directories.
*Maven give me error if I write java classes in different directories.*

*How to do because this works ??*

Looking on Internet I found this article :
https://stackoverflow.com/questions/270445/maven-compile-with-multiple-src-
directories

there is the suggestion of modify the pom file in this way:
---


osmwse
src/main/java, src/interfaces,
src/services

---

Because I did it , maven now works (I can get the file.jar). ..

But I am not able to run the file .jar , after I got it..

*(using the command : )*

I get the error :

*Error: Could not find or load main class com.mycompany.app.App*

nothing changed in the manifest.mf file... (only the pom file changed.).

*I think maven have to be able to mange (in a simple way) projects with
source code wrote on multiple directories...*

how to do it ???

Thank you

Regards

Re: mvn deploy is installing localrepo instead of remote repo

[Bernd Eckenfels]

Hello,

can you share the POM and effective POM and the verbose debug Logs of the Maven 
run. Generally you would check what the maven-deploy plugin gets for the deploy 
goal.

Most likely problem is using a packaging which has no deploy phase goal. Also 
check for user properties to skip the deploy (by default maven.deploy.skip).

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Naveen Swamy 
Sent: Wednesday, May 30, 2018 5:23:40 AM
To: Maven Users List
Subject: mvn deploy is installing localrepo instead of remote repo

I am running mvn deploy on the package to send it to the staging repo,
however it seems to install only on the local repo? Any ideas on how to
debug and resolve this?

I have already set the right staging repos in settings.xml and it seems to
reading the settings from what i tell from the debug logs.

Appreciate your help

Re: Functionality allowed in a dependency of type=POM

[Bernd Eckenfels]

Both modules (of type POM) can contain build steps, however when you reference 
a POM it will not execute those steps (the steps are executed before - you 
would deploy the referenced project first).

If you want to distribute or repackage the pulled in dependencies you would use 
the assembly or resource plugin in the including Pom.

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

From: DariusGmail 
Sent: Saturday, April 21, 2018 9:31:11 PM
To: users@maven.apache.org
Subject: Functionality allowed in a dependency of type=POM

If I have a POM that contains a dependency of type=POM, e.g.

 
com.mycompany
mysql-starter
1.0
pom
 

I see that the included POM can contain other dependencies, thus
providing a way to package together a set of related dependencies.

Can the reference POM also contain build steps?
For example: Use the resource plugin to copy certain files that are
needed when using the specific JAR mentioned in its dependencies.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

AW: maven-archetype-plugin default version

[Bernd Eckenfels]

If there is no plugin Management or Defaults it uses the latest Version.
-- 
http://bernd.eckenfels.net

Von: Stefan Helfrich
Gesendet: Mittwoch, 28. März 2018 00:29
An: users@maven.apache.org
Betreff: Re: maven-archetype-plugin default version

Thanks for pointing this out, Anders!

My question was along the lines of how Maven determines which version of
a plugin is used in this case:

$ mvn org.apache.maven.plugins:maven-archetype-plugin:help

and/or

$ mvn archetype:help

Best,
Stefan

On 2018/03/27 05:50:16, Anders Hammar wrote:
> mvn org.apache.maven.plugins:maven-archetype-plugin:3.0.1:help>
>
> /Anders>
>
> On Mon, Mar 26, 2018 at 11:12 AM, Stefan Helfrich <>
> stefan.helfr...@uni-konstanz.de> wrote:>
>
> > Dear everyone,>
> >>
> > I had filed an issue (https://issues.apache.org/jira/browse/MPOM-172)>
> > some time ago about bumping the version of maven-archetype-plugin to>
> > which Maven defaults.>
> >>
> > To my understanding, the fix of the issue should have made the latest>
> > Maven version default to maven-archetype-plugin:3.0.1 instead of 2.4>
> > when executing>
> >>
> > $ mvn archetype:help>
> >>
> > in a non-Maven project folder (ie. no POM available to mess with that>
> > setting). It seems that I was mistaken on that point. Does anyone have>
> > insights on where/how to propose a version bump maven-archetype-plugin>
> > from 2.4 to 3.0.1?>
> >>
> > Best,>
> > Stefan>
> >>
> > -->
> > Dr. Stefan Helfrich>
> > Bioimaging Center (L931)>
> > University of Konstanz>
> >>
> > PO Box 604>
> > 78457 Konstanz>
> > Germany>
> >>
> > Tel +49-7531-884666>
> > Fax +49-7531-884005>
> >>
> >>
> >>
> > ->
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org>
> > For additional commands, e-mail: users-h...@maven.apache.org>
> >>
> >>
>

-- 
Dr. Stefan Helfrich
Bioimaging Center (L931)
University of Konstanz

PO Box 604
78457 Konstanz
Germany

Tel +49-7531-884666
Fax +49-7531-884005

Re: Not able to read jars in repo intermittently

[Bernd Eckenfels]

UIt is correct that maven does not like it when your run install jobs 
concurrently with jobs reading the same artifacts. In order to avoid this you 
can have a workspace specific Repository („Local to workspace“ this might have 
some advantages for isolating different jobs but consumes a lot of disk) or you 
can configure the local maven Repository to be unique for the jenkins built 
executors (“Local to Executor“). This way you have only a fixed multiplier for 
disk space usage.

What you also can do is to reduce the need to install (snapshots) at the end of 
a built job. For example by only using deploy or have Jenkins deploy the 
resulting artifacts After verify.

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Adam Hardy 
Sent: Monday, March 26, 2018 7:44:17 PM
To: users@maven.apache.org
Subject: Not able to read jars in repo intermittently

I use a Jenkins server which is administered by another team. I get the 
following errors intermittently. The team claim the issue is

"the maven repository is not multi write safe. It's possible several jobs are 
updating the jar files at the same time and corrupt them. If that's the case, 
the only option available at the moment is to use a repository local to the 
workspace"

These are reads, and the writes to create these jars will only ever be done 
once - isn't that correct?

I have my own settings.xml to use but I have not configured a local repo for my 
own project because i thought that would not be my responsibility as a jenkins 
client.

Is there an obvious source of this error, and alternatively should I configure 
my own repo in my settings.xml?

Here's the error:


[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] error reading 
/home/jenkins/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar;
 error in opening zip file
[ERROR] error reading 
/home/jenkins/.m2/repository/commons-io/commons-io/2.4/commons-io-2.4.jar; 
error in opening zip file
[ERROR] error reading 
/home/jenkins/.m2/repository/commons-pool/commons-pool/1.6/commons-pool-1.6.jar;
 error in opening zip file
[ERROR] error reading 
/home/jenkins/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar;
 error in opening zip file
[ERROR] error reading 
/home/jenkins/.m2/repository/commons-io/commons-io/2.4/commons-io-2.4.jar; 
error in opening zip file
[ERROR] error reading 
/home/jenkins/.m2/repository/commons-pool/commons-pool/1.6/commons-pool-1.6.jar;
 error in opening zip file
[ERROR] 
/home/jenkins/workspace/rdis_gem-tardis-rest_master-V5NBFAKC4NMCAXWRJ7MGOI5IW5OWL6UESQFP6S4T4AW2CRGDV65A/src/main/java/com/bp/gem/util/servlet/RequestLoggingInnerFilter.java:[6,36]
 package org.apache.commons.io.output does not exist
[ERROR] 
/home/jenkins/workspace/rdis_gem-tardis-rest_master-V5NBFAKC4NMCAXWRJ7MGOI5IW5OWL6UESQFP6S4T4AW2CRGDV65A/src/main/java/com/bp/gem/util/servlet/RequestLoggingInnerFilter.java:[243,23]
 cannot find symbol
  symbol:   class TeeOutputStream
  location: class 
com.bp.gem.util.servlet.RequestLoggingInnerFilter.TeeServletOutputStream
[ERROR] 
/home/jenkins/workspace/rdis_gem-tardis-rest_master-V5NBFAKC4NMCAXWRJ7MGOI5IW5OWL6UESQFP6S4T4AW2CRGDV65A/src/main/java/com/bp/gem/util/servlet/RequestLoggingInnerFilter.java:[246,32]
 cannot find symbol
  symbol:   class TeeOutputStream
  location: class 
com.bp.gem.util.servlet.RequestLoggingInnerFilter.TeeServletOutputStream
[INFO] 9 errors
[INFO] -
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 3.216 s
[INFO] Finished at: 2018-03-23T15:12:08+00:00
[INFO] Final Memory: 32M/366M
[INFO] 


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

Re: Maven build failure - first install

[Bernd Eckenfels]

Hello,

Looks like the tutorial is wrong, I only see a 1.1 version of that archetype. 
Since you normally cannot remove artifacts from Maven Central it looks like 
this never worked. You can see the content here:

https://repo.maven.apache.org/maven2/org/apache/maven/archetypes/maven-archetype-quickstart/

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

From: kobano 
Sent: Wednesday, March 14, 2018 11:12:07 AM
To: users@maven.apache.org
Subject: Maven build failure - first install

Hello, I'm a beginner and follow the course OpenClassroom " Organize and
package a Java application with Apache Maven

"On this first part I have to  create a Maven project qsuelette from the
quickstart archetype

.Following the line :mvn -X archetype:generate
-DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.1I get
a build failure and I can not find the source of the problem.I added -X for
more info, and here are the last lines I can get :I'm working on windows 8,
and have not created a settings.xml file.For info, here is what mvn -v
shows:A line in what is displayed indicates that "quickstart" is not
found:Could not find artifact
org.apache.maven.archetypes:maven-archetype-quickstart:jar:3.0.1 in central
( https://repo.maven.apache.org/maven2
  )Could it be that the OpenClassroom
course uses a skeleton that no longer exists?Or the problem would come from
elsewhere?Thanks in advance for the help !!



--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html

AW: maven-install-plugin: Why it does not install the artifacts

[Bernd Eckenfels]

Hello,

if you start with a empty POM of type JAR the Default LifeCycle bindings (which 
include intall plugin) apply. 
See here: 
http://maven.apache.org/ref/3.2.2/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging

-- 
http://bernd.eckenfels.net

Von: Zos Rothko
Gesendet: Dienstag, 13. März 2018 06:58
An: i...@soebes.de; Maven Users List
Betreff: Re: maven-install-plugin: Why it does not install the artifacts

Hi


Le 12/03/2018 à 17:35, Karl Heinz Marbaise a écrit :
> Hi,
>
> On 12/03/18 14:51, Zos Rothko wrote:
>> Hi
>>
>>
>> http://maven.apache.org/POM/4.0.0; 
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
>> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>>  4.0.0
>>  fr.swisslife.archiev3
>>  maven
>>  1.0.0
>>
>>  
>>
>>
>>
>
> If I take a look at your pom file...just remove the whole 
> configuration for maven-install-plugin...
> and just try to do:
I do not understand your advise: How a "mvn clean install" command can 
install the file/artifact if the configurations specifying those 
file/artifacts are removed???
>
> mvn clean install
>
>
> If you are artifacts installed fine if not ...there is something else 
> wrong..
>
> Please at best a link to a project github/bitbucket etc...
>
> Kind regards
> Karl Heinz Marbaise


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

Re: [m-jlink-p] missing --launcher and other CLI options in alpha1

[Bernd Eckenfels]

See `jlink --list-plugins` for the additional options.

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Karl Heinz Marbaise <khmarba...@gmx.de>
Sent: Friday, March 9, 2018 7:20:42 AM
To: Maven Users List; Bernd Eckenfels
Subject: Re: [m-jlink-p] missing --launcher and other CLI options in alpha1

Hi,

On 09/03/18 01:29, Bernd Eckenfels wrote:
> Hello,
>
> I noticed the m-jlink-p (3.0.0-alpha1) misses e.g. --launcher Option (and 
> some more). I wonder is it planned to add a option.
>
> Or did I miss a method to specify CLI Options which should be passed to 
> jlink.exe transparently?

> I guess that would be good especially for those Options which are provided by 
> plugins. For example:
>
> --strip-native-commands
> --release-info
> --include-locales
> --exclude-files, --dedup-legal-notice,
>
> BTW: should –verbose also print the CLI Options actually used (or at least 
> retain the @jlinkargs file?)
>
> Gruss
> Bernd
>

maybe I miss something but where did you get those options cause If I
call jlink --help: (JDK 9.0.4):

The --launcher option is there and should of course being added to the
plkugin

but --strip-native-commands, --include-locales, --exclude-files,
--debup-legal-notes I can't find a hint about?




Usage: jlink  --module-path  --add-modules
[,...]
Possible options include:
   --add-modules [,...]Root modules to resolve
   --bind-services   Link in service provider
modules and
 their dependences
   -c, --compress=<0|1|2>Enable compression of resources:
   Level 0: No compression
   Level 1: Constant string sharing
   Level 2: ZIP
   --disable-plugin  Disable the plugin mentioned
   --endian <little|big> Byte order of generated jimage
 (default:native)
   -h, --helpPrint this help message
   --ignore-signing-information  Suppress a fatal error when signed
 modular JARs are linked in the
image.
 The signature related files of the
 signed modular JARs are not
copied to
 the runtime image.
   --launcher =[/]
 Add a launcher command of the given
 name for the module and the
main class
 if specified
   --limit-modules [,...]  Limit the universe of observable
 modules
   --list-pluginsList available plugins
   -p, --module-path   Module path
   --no-header-files Exclude include header files
   --no-man-pagesExclude man pages
   --outputLocation of output path
   --save-opts Save jlink options in the given
file
   -G, --strip-debug Strip debug information
   --suggest-providers [,...]  Suggest providers that
implement the
 given service types from the
module path
   -v, --verbose Enable verbose tracing
   --version Version information
   @   Read options from file


Kind regards
Karl Heinz Marbaise

[m-jlink-p] missing --launcher and other CLI options in alpha1

[Bernd Eckenfels]

Hello,

I noticed the m-jlink-p (3.0.0-alpha1) misses e.g. --launcher Option (and some 
more). I wonder is it planned to add a option.

Or did I miss a method to specify CLI Options which should be passed to 
jlink.exe transparently? I guess that would be good especially for those 
Options which are provided by plugins. For example:

--strip-native-commands
--release-info
--include-locales
--exclude-files, --dedup-legal-notice, 

BTW: should –verbose also print the CLI Options actually used (or at least 
retain the @jlinkargs file?)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Re: Error

[Bernd Eckenfels]

Hello,

# org.codehaus.mojo:exec-maven-plugin:@maven-exec-plugin.version@

It looks like the plugin definition in the POM contains not a valid version 
number but a placeholder. Not sure if you are supposed to replace it manually 
with a version number or if the POM you are using is not to be used without a 
search and replace preprocessor.

Gruss
Bernd
--
http://bernd.eckenfels.net
_
From: Dana Zainescu 
Sent: Montag, März 5, 2018 8:42 PM
Subject: Error
To: 


Hello,

I am getting the following errors when I try to run Maven from my Mac:



mvn compile exec:java -X 
-Dexec.mainClass=com.dpdgroup.hubDashboard.StarterPipeline \

>  -Dexec.args="--runner=DirectRunner 
> --project=dpduk-event-processing-design \

>   
> --subscriberTopic=projects/dpduk-event-processing-design/topics/outbound.parcelEvent.hubscan"
>  \

>



Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 
2017-10-18T08:58:13+01:00)

Maven home: /usr/local/Cellar/maven/3.5.2/libexec

Java version: 9.0.4, vendor: Oracle Corporation

Java home: /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home

Default locale: en_GB, platform encoding: UTF-8

OS name: "mac os x", version: "10.13.3", arch: "x86_64", family: "mac"

[DEBUG] Created new class realm maven.api

[DEBUG] Importing foreign packages into class realm maven.api

[DEBUG]  Imported: javax.annotation.* < plexus.core

[DEBUG]  Imported: javax.enterprise.inject.* < plexus.core

[DEBUG]  Imported: javax.enterprise.util.* < plexus.core

[DEBUG]  Imported: javax.inject.* < plexus.core

[DEBUG]  Imported: org.apache.maven.* < plexus.core

[DEBUG]  Imported: org.apache.maven.artifact < plexus.core

[DEBUG]  Imported: org.apache.maven.classrealm < plexus.core

[DEBUG]  Imported: org.apache.maven.cli < plexus.core

[DEBUG]  Imported: org.apache.maven.configuration < plexus.core

[DEBUG]  Imported: org.apache.maven.exception < plexus.core

[DEBUG]  Imported: org.apache.maven.execution < plexus.core

[DEBUG]  Imported: org.apache.maven.execution.scope < plexus.core

[DEBUG]  Imported: org.apache.maven.lifecycle < plexus.core

[DEBUG]  Imported: org.apache.maven.model < plexus.core

[DEBUG]  Imported: org.apache.maven.monitor < plexus.core

[DEBUG]  Imported: org.apache.maven.plugin < plexus.core

[DEBUG]  Imported: org.apache.maven.profiles < plexus.core

[DEBUG]  Imported: org.apache.maven.project < plexus.core

[DEBUG]  Imported: org.apache.maven.reporting < plexus.core

[DEBUG]  Imported: org.apache.maven.repository < plexus.core

[DEBUG]  Imported: org.apache.maven.rtinfo < plexus.core

[DEBUG]  Imported: org.apache.maven.settings < plexus.core

[DEBUG]  Imported: org.apache.maven.toolchain < plexus.core

[DEBUG]  Imported: org.apache.maven.usability < plexus.core

[DEBUG]  Imported: org.apache.maven.wagon.* < plexus.core

[DEBUG]  Imported: org.apache.maven.wagon.authentication < plexus.core

[DEBUG]  Imported: org.apache.maven.wagon.authorization < plexus.core

[DEBUG]  Imported: org.apache.maven.wagon.events < plexus.core

[DEBUG]  Imported: org.apache.maven.wagon.observers < plexus.core

[DEBUG]  Imported: org.apache.maven.wagon.proxy < plexus.core

[DEBUG]  Imported: org.apache.maven.wagon.repository < plexus.core

[DEBUG]  Imported: org.apache.maven.wagon.resource < plexus.core

[DEBUG]  Imported: org.codehaus.classworlds < plexus.core

[DEBUG]  Imported: org.codehaus.plexus.* < plexus.core

[DEBUG]  Imported: org.codehaus.plexus.classworlds < plexus.core

[DEBUG]  Imported: org.codehaus.plexus.component < plexus.core

[DEBUG]  Imported: org.codehaus.plexus.configuration < plexus.core

[DEBUG]  Imported: org.codehaus.plexus.container < plexus.core

[DEBUG]  Imported: org.codehaus.plexus.context < plexus.core

[DEBUG]  Imported: org.codehaus.plexus.lifecycle < plexus.core

[DEBUG]  Imported: org.codehaus.plexus.logging < plexus.core

[DEBUG]  Imported: org.codehaus.plexus.personality < plexus.core

[DEBUG]  Imported: org.codehaus.plexus.util.xml.Xpp3Dom < plexus.core

[DEBUG]  Imported: org.codehaus.plexus.util.xml.pull.XmlPullParser < plexus.core

[DEBUG]  Imported: org.codehaus.plexus.util.xml.pull.XmlPullParserException < 
plexus.core

[DEBUG]  Imported: org.codehaus.plexus.util.xml.pull.XmlSerializer < plexus.core

[DEBUG]  Imported: org.eclipse.aether.* < plexus.core

[DEBUG]  Imported: org.eclipse.aether.artifact < plexus.core

[DEBUG]  Imported: org.eclipse.aether.collection < plexus.core

[DEBUG]  Imported: org.eclipse.aether.deployment < plexus.core

[DEBUG]  Imported: org.eclipse.aether.graph < plexus.core

[DEBUG]  Imported: org.eclipse.aether.impl < plexus.core

[DEBUG]  Imported: org.eclipse.aether.installation < plexus.core

[DEBUG]  Imported: org.eclipse.aether.internal.impl < plexus.core

[DEBUG]  Imported: org.eclipse.aether.metadata < plexus.core

[DEBUG]  Imported: org.eclipse.aether.repository < plexus.core

[DEBUG]  Imported: 

Re: Why I can run plugin:goal in command line even though plugin wasonly defined under pluginManagement?

[Bernd Eckenfels]

My guess is, that as soon as a plug-in is resolved (which includes plugin 
management) it's prefix is registered. For the default groups the Prefix is 
searched in, but that does not apply in this case.

In all cases it can be used, it just has no preferred version or default-cli 
configuration in the POM.

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Sigmond Hola <sigmund@gmail.com>
Sent: Monday, February 26, 2018 8:17:02 AM
To: Maven Users List
Subject: Re: Why I can run plugin:goal in command line even though plugin 
wasonly defined under pluginManagement?

Hi Bernd,

You are right, thanks for illustration.

But why? Im still confused

the  prefix-to-artifactId mappings is defined within  of
effective settings.xml and the default values of it is:

> org.apache.maven.plugins
> org.codehaus.mojo

right? tomcat7's groupId:  org.apache.tomcat.maven is not included.

Why I can using tomcat7 as prefix for  tomcat7-maven-plugin after I add it
in   of my pom.xml...


On Sun, Feb 25, 2018 at 12:36 AM, Bernd Eckenfels <e...@zusammenkunft.net>
wrote:

> It is true: for plugins where the prefix is not found by Default, you can
> still start them with
>
> mvn org.apache.tomcat.maven:tomcat7-maven-plugin:run
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> Von: Sigmond Hola
> Gesendet: Samstag, 24. Februar 2018 11:03
> An: Maven Users List
> Betreff: Re: Why I can run plugin:goal in command line even though plugin
> wasonly defined under pluginManagement?
>
> HI bernd,
>
> thanks for reply, but that's not true.
>
> Take tomcat-maven-plugin as example, if you dont defined it under
>  or , then following
> error will reported if you run  mvn tomcat7:rununder command line:
>
> No plugin found for prefix 'tomcat7' in the current project and in the
> plugin groups [org.apache.maven.plugins, org.codehaus.mojo]
> >
> >
> Best regards.
>
>
> On Sat, Feb 24, 2018 at 4:39 PM, Bernd Eckenfels <e...@zusammenkunft.net>
> wrote:
>
> > Hello,
> >
> > You can always run goals on the command line, even if they are not
> defined
> > in the POM at all. If maven finds the plugin in the POM it knows what
> > version to use and it allows to specify a Prefix instead of
> > group:artifact[:version]:goal.
> > Gruss
> > Bernd
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > 
> > From: Sigmond Hola <sigmund@gmail.com>
> > Sent: Saturday, February 24, 2018 7:01:04 AM
> > To: users@maven.apache.org
> > Subject: Why I can run plugin:goal in command line even though plugin was
> > only defined under pluginManagement?
> >
> > I defined a specific plugin under  ,
> but
> > not under  , but I can still run goals of this plugin
> > with  mvn
> > plugin:goal.
> >
> > As far as I understand is only used to configuring the
> > plugin information, but not actually import them, right? then how can I
> use
> > the goals of this plugin  in the command line?
> >
> > Thanks for reply.
> >
> > Bests.
> > --Sig
> >
>
>

Re: Why I can run plugin:goal in command line even though plugin wasonly defined under pluginManagement?

[Bernd Eckenfels]

It is true: for plugins where the prefix is not found by Default, you can still 
start them with

mvn org.apache.tomcat.maven:tomcat7-maven-plugin:run
Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Sigmond Hola
Gesendet: Samstag, 24. Februar 2018 11:03
An: Maven Users List
Betreff: Re: Why I can run plugin:goal in command line even though plugin 
wasonly defined under pluginManagement?

HI bernd,

thanks for reply, but that's not true.

Take tomcat-maven-plugin as example, if you dont defined it under
 or , then following
error will reported if you run  mvn tomcat7:rununder command line:

No plugin found for prefix 'tomcat7' in the current project and in the
plugin groups [org.apache.maven.plugins, org.codehaus.mojo]
>
>
Best regards.


On Sat, Feb 24, 2018 at 4:39 PM, Bernd Eckenfels <e...@zusammenkunft.net>
wrote:

> Hello,
>
> You can always run goals on the command line, even if they are not defined
> in the POM at all. If maven finds the plugin in the POM it knows what
> version to use and it allows to specify a Prefix instead of
> group:artifact[:version]:goal.
> Gruss
> Bernd
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Sigmond Hola <sigmund@gmail.com>
> Sent: Saturday, February 24, 2018 7:01:04 AM
> To: users@maven.apache.org
> Subject: Why I can run plugin:goal in command line even though plugin was
> only defined under pluginManagement?
>
> I defined a specific plugin under  , but
> not under  , but I can still run goals of this plugin
> with  mvn
> plugin:goal.
>
> As far as I understand is only used to configuring the
> plugin information, but not actually import them, right? then how can I use
> the goals of this plugin  in the command line?
>
> Thanks for reply.
>
> Bests.
> --Sig
>

Re: Why I can run plugin:goal in command line even though plugin was only defined under pluginManagement?

[Bernd Eckenfels]

Hello,

You can always run goals on the command line, even if they are not defined in 
the POM at all. If maven finds the plugin in the POM it knows what version to 
use and it allows to specify a Prefix instead of group:artifact[:version]:goal.
Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Sigmond Hola 
Sent: Saturday, February 24, 2018 7:01:04 AM
To: users@maven.apache.org
Subject: Why I can run plugin:goal in command line even though plugin was only 
defined under pluginManagement?

I defined a specific plugin under  , but
not under  , but I can still run goals of this plugin with  mvn
plugin:goal.

As far as I understand is only used to configuring the
plugin information, but not actually import them, right? then how can I use
the goals of this plugin  in the command line?

Thanks for reply.

Bests.
--Sig

Re: Looking for recommendations how to best use Maven in a muti-stagePipeline build to only deploy at the end

[Bernd Eckenfels]

I am not sure why Nexus does not Support staging repos, I thought this is one 
of its defining Features? Certainly the ASF is using Nexus this way.

Anyway, another solution is to use a Feature of the CI to run a whole Pipeline 
on a single executor and have this executor have a local maven repo instance 
(this is a good idea anyway). Then you can avoid to deploy at all (only 
install) until your last step.

In my cases it Comes up not so often as the last Pipeline steps to release a 
product depend on Long ago released artifact versions with their own lifecylce.

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Robert Patrick
Gesendet: Mittwoch, 14. Februar 2018 16:01
An: Maven Users List
Betreff: RE: Looking for recommendations how to best use Maven in a 
muti-stagePipeline build to only deploy at the end

While Nexus may not support "staging repositories", it certainly supports more 
than one repository so why not just create one or more repositories that serve 
as staging repositories.  For example,

Pipeline Steps:
1.) Trigger a build based on source check-in and push to stage1 repo if build 
"succeeds"
2.) Pull artifacts from stage1 repo, run stage 2 tests, and push to stage2 repo 
if tests succeed.
3.) Pull artifacts from stage2 repo, run stage 3 tests, and push to stage3 repo 
if tests succeed.
4.) Pull artifacts from stage3 repo, run UAT tests, and push to release repo if 
tests succeed.




-Original Message-
From: Eric B [mailto:ebenza...@gmail.com] 
Sent: Wednesday, February 14, 2018 8:30 AM
To: Maven Users List 
Subject: Looking for recommendations how to best use Maven in a muti-stage 
Pipeline build to only deploy at the end

I'm looking for recommendations for the best way to use Maven in a multi-stage 
Jenkins pipeline build to deploy only at the end.  At the moment, I'm using 
Sonatype Nexus 3.x, which means i don't have the benefit
of staging repos.   Consequently, I have to ensure that the only released
versions of my libraries/application are final - they've passed QA.
Additionally, the team wants to ensure that the version numbers are always 
incremental and every version in the repo is a consumable version (ie: I cannot 
deploy a version 1.2.3 which has not passed QA/Acceptance Tests, and 
furthermore, I cannot deploy a 1.2.2 followed by a 1.2.4).

What that requirement translates to is that I have to ensure that the binary 
built is fully tested before promoting it to Nexus. (and that I shouldn't be 
appending build numbers to the maven version number).

In my mind, I would like to do something the following in a Pipeline build:

stage('build') { steps { sh 'mvn clean install'} }

stage('Confirm deploy to QA'){

steps {

checkpoint 'test server deployed'

script {

env.DEPLOY_TO_QA_TEST = input message: 'User input required',

submitter: 'authenticated',

parameters: [choice(name: 'Deploy to acceptance test server', choices:
'no\nyes', description: 'Choose "yes" if you want to deploy the QA test 
server')]

}

}

}

stage('deployQA') {

when {

environment name: 'DEPLOY_TO_QA_TEST', value: 'yes'

}

steps{

/* deploy the build to a QA environment */  }

}


stage('Confirm deploy to UAT'){ // prompt user }

stage {'deployUAT') { /* deploy the build to a PreProd/User Acceptance Testing 
enviornment */}


stage('Confirm publish to Nexus'){ // prompt user }

stage('publish') {

steps {

  // mvn deploy -DskipTests (just deploy - don't rebuild)

}

}


Basically, I want to design my Jenkins pipeline to be my staging process.
The problem I have is I'm not sure how I can only deploy at the end of the 
pipeline.  When maven runs the deploy lifecycle, it will run through all the 
other stages and reassemble my binaries, which technically are not longer the 
same as those that were approved.  So consequently, my binary hashes that were 
approved earlier in the pipeline are not the same hashes that are deployed in 
Nexus.

I realize that i can probably do some work and use the Reproducible Build 
plugin 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__zlika.github.io_reproducible-2Dbuild-2Dmaven-2Dplugin_=DwIBaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=nSxyAsyxa1Izff8ULe7vW8u084madbci-hLPsiLpxeU=Og2S17jc02JRwm-oHae8UQmiIg_ygbBRL0EQoB_Wvuw=zipmYyPLpmFYv1RsnquZtQMf0-HoYoix12SZj6gD2jM=),
 but that too comes with drawbacks (I want build timestamps in my Manifest 
files, and zip entries, etc).

Am I sunk?  Is my only hope to wait until Sonatype releases Staging repos for 
Nexus 3.x sometime in Q2?  Or is there some other way I can work around this?

How is everyone else handling this situation?

Thanks for sharing.

Eric

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

Re: Special parameters - sha1

[Bernd Eckenfels]

Hello,

If you have a POM with dependencies to other modules which are built on each 
change, you typically want to make sure you use those updated dependencies when 
you compile your projects.

With regularly changing version numbers and without using SNAPSHOT dependencies 
you will need to find a solution for this. You could use version ranges, but 
then you are not much different then using SNAPSHOT builds. This is one of the 
main reasons why we are doing manual releases - and managing the dependency 
versions by hand.

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Eric Benzacar <e...@benzacar.ca>
Sent: Thursday, November 16, 2017 5:05:45 AM
To: Maven Users List
Cc: i...@soebes.de
Subject: Re: Special  parameters - sha1

I'm not sure what you mean when you say:

"How are you planning to deal with the changed version numbers of
dependencies?"

At which stage are you referring to?  Which dependencies with changed
version numbers?

Thanks,

Eric

On Wed, Nov 15, 2017 at 1:11 AM, Bernd Eckenfels <e...@zusammenkunft.net>
wrote:

> You have to remember that POMs are also the model to describe artifacts,
> that why you should stay clear of profiles (especially if the influence
> artifact coordinates).
>
> Personally I have good experience with actually releasing things, but if
> you want to keep the build identifier, then I would agree, that handling
> this in the build job is probably the best. You can have even two
> Parameterized jobs.
>
> How are you planning to deal with the changed version numbers of
> dependencies?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Eric B <ebenza...@gmail.com>
> Sent: Wednesday, November 15, 2017 4:30:06 AM
> To: i...@soebes.de; Maven Users List
> Subject: Re: Special  parameters - sha1
>
> Hi,
>
> Thanks for the additional insight.  I think I understand better now how
> this works.   I'll try to explain my use case, and perhaps someone can
> provide some ideas for best practices.
>
> I started a pom refactoring because I wanted to add the enforcer-plugin for
> a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
> dev purposes, we have defined that anything in a release/ branch (Gitflow)
> is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
> Additionally, we use semantic versioning, so our versions read 4.7.0,
> 4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a release
> branch needs to have a unique version.  I don't want to update the version
> number for each build, so each build has to have a build number or sha1
> attached to the version.
>
> My build pipeline is very basic for the moment; it's a simple Jenkins
> freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it as
> simple as possible and always pass the same parameters to the maven build
> process (to make it easier for others to understand).
>
> I'm passing the following parameters to the maven build:
>  -DbranchType=release
>  -DbuildNumber=
>
> maven.config:
> -Drevision=5.0.0
>
>
>
> My thought process is I could do the following - for the normal use case
> (ie: dev branch):
> ${revision}${changelist}
> 
>   -SNAPSHOT
> 
>
>
> For a release:
> 
>   relelase
>   
> 
>branchType
>release
> 
>   
>
>   
>   ${buildNumber}
>
> 
> 
>
>
> But now I see that won't work.  So I need to pass the buildnumber on the
> command line as a SHA1 parameter.  But if I do that in this design, the
> SNAPSHOT will also include the SHA1 which is not what I want.
>
> So from what I can see, the only option is to modify the parameters on the
> command line.  Which means I have to add some additional logic to my
> Jenkins build.  This would be much easier if I had a Pipeline build but I
> don't at the moment.  I was just looking to put the intelligence in the pom
> so that anyone could easily read & understand it.
>
> Any suggestions or recommendations would be greatly appreciated.  Is there
> anyway to do this in the pom itself?
>
> Thanks,
>
> Eric
>
> On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise <khmarba...@gmx.de>
> wrote:
>
> > Hi,
> >
> >
> > I will give some more details cause I have created the docs /
> > implementation and you mentioned my blog ;-)..
> >
> >
> > On 14/11/17 03:12, Eric B wrote:
> >
> >> Following a long thread on this list, and a blog by khmarbaise (
> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> >> t-a-version-in-it/),
> >> I'm still a little confused as to 

Re: Special parameters - sha1

[Bernd Eckenfels]

You have to remember that POMs are also the model to describe artifacts, that 
why you should stay clear of profiles (especially if the influence artifact 
coordinates).

Personally I have good experience with actually releasing things, but if you 
want to keep the build identifier, then I would agree, that handling this in 
the build job is probably the best. You can have even two Parameterized jobs.

How are you planning to deal with the changed version numbers of dependencies?

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Eric B 
Sent: Wednesday, November 15, 2017 4:30:06 AM
To: i...@soebes.de; Maven Users List
Subject: Re: Special  parameters - sha1

Hi,

Thanks for the additional insight.  I think I understand better now how
this works.   I'll try to explain my use case, and perhaps someone can
provide some ideas for best practices.

I started a pom refactoring because I wanted to add the enforcer-plugin for
a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
dev purposes, we have defined that anything in a release/ branch (Gitflow)
is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
Additionally, we use semantic versioning, so our versions read 4.7.0,
4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a release
branch needs to have a unique version.  I don't want to update the version
number for each build, so each build has to have a build number or sha1
attached to the version.

My build pipeline is very basic for the moment; it's a simple Jenkins
freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it as
simple as possible and always pass the same parameters to the maven build
process (to make it easier for others to understand).

I'm passing the following parameters to the maven build:
 -DbranchType=release
 -DbuildNumber=

maven.config:
-Drevision=5.0.0



My thought process is I could do the following - for the normal use case
(ie: dev branch):
${revision}${changelist}

  -SNAPSHOT



For a release:

  relelase
  

   branchType
   release

  
   
  
  ${buildNumber}
   




But now I see that won't work.  So I need to pass the buildnumber on the
command line as a SHA1 parameter.  But if I do that in this design, the
SNAPSHOT will also include the SHA1 which is not what I want.

So from what I can see, the only option is to modify the parameters on the
command line.  Which means I have to add some additional logic to my
Jenkins build.  This would be much easier if I had a Pipeline build but I
don't at the moment.  I was just looking to put the intelligence in the pom
so that anyone could easily read & understand it.

Any suggestions or recommendations would be greatly appreciated.  Is there
anyway to do this in the pom itself?

Thanks,

Eric

On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise 
wrote:

> Hi,
>
>
> I will give some more details cause I have created the docs /
> implementation and you mentioned my blog ;-)..
>
>
> On 14/11/17 03:12, Eric B wrote:
>
>> Following a long thread on this list, and a blog by khmarbaise (
>> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> t-a-version-in-it/),
>> I'm still a little confused as to exactly what is allowed in the special
>> version tags for a maven pom.
>>
>> I know and realize that the 3 allowable tags are:
>>   - ${revision}
>>   - ${sha1}
>>   - ${changelist}
>>
>> However, from the thread and the blog, it seems that these properties
>> cannot be dependent on any other properties.
>>
>
> Correct.
>
>>
>> For example, this is fine:
>> ${revision}-${sha1}
>> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
>>
>>
>> However, based on the further docs at
>> https://maven.apache.org/maven-ci-friendly.html, this design would fail:
>>
>
> which is not mentioned in the docs...
>
>
>> ${revision}-${sha1}
>>
>> 
>>   ${buildNumber}
>> 
>>
>>
>> and call it as -Drevision=1.2.3 -DbuildNumber=9
>>
>
> The problem is simply that buildNumber is not correctly overwritten from
> command and not correctly handled duing the model reading / interpolation
> at the correct time within Maven Core at the moment...
>
> At the moment this is only implemented for those special three
> properties...which already has performance impacts...which is also a reason
> not making that possible for all kind of properties...at the moment...
>
>
>>
>> Is anyone able to shed some light as to why this would be the case?  Why
>> can a property not be used to compute on of the 3 special vars?
>>
>> My use case is that I want to supply the build number to all my builds,
>> but
>> only append it to the version if a specific profile is enabled.  In my
>> mind, it would be simple - make the sha1 property empty by default, and in
>> my specific profile, set it to the buildnumber.   But based on my
>> understanding, this would fail.
>>
>> Is my only option in that case 

Re: Special parameters - sha1

[Bernd Eckenfels]

Hello,

>From maven points of view it needs to construct a complete model before 
>operating on it. That it is why it cannot dynamically calculate the values of 
>nested properties. So the 3 values are picked to be allowed to be specified 
>externally, with the understanding that they don’t need to be calculated by 
>maven.

However nothing stops you from dynamically constructing the values from outside 
(with Shell variables or pgrammatically with expressionism your CI Seever)

  mvn -Drevision="-$DATE-$BUildNumber" -Dchangelist="-nightly" test

1.2.3${revision}${changelist}

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Eric B <ebenza...@gmail.com>
Sent: Tuesday, November 14, 2017 4:16:08 AM
To: Maven Users List
Subject: Re: Special  parameters - sha1

Bernd,

Is my understanding correct though?  These three properties cannot contain
any property values?  They can only contain constants?  Can they contain
other command line values, or not even?

Can you elaborate why it was deemed necessary to restrict the expansion to
a fixed set?  What was the reasoning behind that?

Thanks,

Eric


On Mon, Nov 13, 2017 at 9:21 PM, Bernd Eckenfels <e...@zusammenkunft.net>
wrote:

> You can use the 3 Properties in any way you want it, their name suggest a
> certain content, and it was deemed necessary to restrict the expansion to a
> fixed set. so the 3 have been picked to give some guidance on what are sane
> modifiers.
>
> You will most likely use revision for the Version and changelist or sha
> for the incremental builds, but you can also cram everything into revision,
> Maven does not really care how you use them (as long as you use nothing
> else)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Eric B <ebenza...@gmail.com>
> Sent: Tuesday, November 14, 2017 3:12:21 AM
> To: Maven Users List
> Subject: Special  parameters - sha1
>
> Following a long thread on this list, and a blog by khmarbaise (
> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-
> without-a-version-in-it/),
> I'm still a little confused as to exactly what is allowed in the special
> version tags for a maven pom.
>
> I know and realize that the 3 allowable tags are:
>  - ${revision}
>  - ${sha1}
>  - ${changelist}
>
> However, from the thread and the blog, it seems that these properties
> cannot be dependent on any other properties.
>
> For example, this is fine:
>${revision}-${sha1}
> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
>
>
> However, based on the further docs at
> https://maven.apache.org/maven-ci-friendly.html, this design would fail:
>
> ${revision}-${sha1}
>
> 
>  ${buildNumber}
> 
>
>
> and call it as -Drevision=1.2.3 -DbuildNumber=9
>
>
> Is anyone able to shed some light as to why this would be the case?  Why
> can a property not be used to compute on of the 3 special vars?
>
> My use case is that I want to supply the build number to all my builds, but
> only append it to the version if a specific profile is enabled.  In my
> mind, it would be simple - make the sha1 property empty by default, and in
> my specific profile, set it to the buildnumber.   But based on my
> understanding, this would fail.
>
> Is my only option in that case to design it as:
>
> ${artifactVersion}
> 
>   ${revision}
> 
>
> 
>   buildNumber
>   
>  ${revision}-${sha1}
>   
> 
>
>
> What is the reason for this limitation?  Is there any chance that this
> limitation will be removed in the future?
>
> Thanks,
>
> Eric
>