Thanks, Karl. Upgrading to the latest version of Maven and the gpg
plugin did the trick. I am still getting peer authentication errors on
some uploads, but I suspect that is a server problem and not a maven
issue. Much appreciated.
On 6/10/22 10:30 AM, Karl Heinz Marbaise wrote:
On 10.06.22 1
The Apache Maven team is pleased to announce the release of the Apache
Maven Enforcer Plugin, version 3.1.0
This plugin provides goals to control certain environmental constraints
such as Maven version, JDK version and OS family
along with many more built-in rules and user created rules.
https://
On 10.06.22 19:26, Karl Heinz Marbaise wrote:
Hi Rick,
On 10.06.22 17:55, Rick Hillegas wrote:
I am having trouble signing maven artifacts. The details of the problem
are described at https://issues.apache.org/jira/browse/INFRA-23348. The
maven error message is terse. No additional useful infor
Hi Rick,
On 10.06.22 17:55, Rick Hillegas wrote:
I am having trouble signing maven artifacts. The details of the problem
are described at https://issues.apache.org/jira/browse/INFRA-23348. The
maven error message is terse. No additional useful information comes
back when I run the maven command
I am having trouble signing maven artifacts. The details of the problem
are described at https://issues.apache.org/jira/browse/INFRA-23348. The
maven error message is terse. No additional useful information comes
back when I run the maven command with -e and -X switches. I haven't
found any use
Hi,
for some reason I didn't get your initial mail, so I'm replying here.
I had a somewhat comparable challenge in Quarkus (making sure that
-amd/-am are picking up modules that must not contribute anything
relevant to the classpath) and ended up with this workaround:
https://github.com/quarkusi
The third party plugin does not expect anything from the classpath as it is a
non-Java Maven plugin. Imagine this case: The ZIP (hypothetically) contains
SVG, the third party plugin renders into PDF, the PDF goes into the WAR as a
resource. Again, just hypothetically. Just ignore WHY the ZIP is
So let's enumerate what we have so far:
- the ZIP is built in same multi module build, and is "intentionally
incompatible"
- the ZIP should be a dependency of WAR module, needed for Maven to be able
to make proper build ordering decisions
- Java specifically says "JARs and ZIPs are added to classp
It is a dependency because it shall be built with -am if this project is built,
and it is consumed by this project using third party plugins. But it simply is
not consumed by the Java toolchain. This has nothing to do with the plugin. The
WAR produced here is built from Java source compiled to J
Well, shoot in the dark: why is this ZIP a _dependency_ in the first place?
As you say "they solely serve as an input to third party plugins (not
dealing with Java at all)". If so, maybe the plugin needs improvement
itself, and allow it's configuration to pick up the zip that holds
resources needed
Nope, it does not work (order of things is not so simple, addedToClasspath
remains always true), hold on a few...
On Fri, Jun 10, 2022 at 12:12 PM Tamás Cservenák
wrote:
> If you can use Maven4, try out this one:
> https://github.com/apache/maven/pull/752
>
> T
>
> On Fri, Jun 10, 2022 at 12:00
That might work, but my intention is not to play with arbitrary experimental
PRs, but is to find a consensus, what such a future feature should look like to
get it accepted by the Maven team. Is that specific PR agreed to get adopted to
Maven 4? IIUC this PR stops adding ANY zips tot he classpat
If you can use Maven4, try out this one:
https://github.com/apache/maven/pull/752
T
On Fri, Jun 10, 2022 at 12:00 PM Tamás Cservenák
wrote:
> I see.
>
> Well, as long as oracle Java doco says this:
>
> Class paths to the JAR, zip or class files. Each class path should end
> with a file name or
I think the biggest problem actually ist hat Maven once was build with Java in
mind, then developed to a cross-platform tool. Just because a ZIP is a ZIP does
not tell us to put ALL zips on the classpath. Hence what we need is either a
generic exclusion mechanism or a generic inclusion mechanism
I see.
Well, as long as oracle Java doco says this:
Class paths to the JAR, zip or class files. Each class path should end with
a file name or directory depending on what you are setting the class path
to, as follows:
* For a JAR or zip file that contains class files, the class path ends
with t
Thanks for the quick tip.
While it might solve the actual problem I did have this morning, it is neither
a clean nor a general solution for everybody and for always, as it still
implies that all ZIPs shall go in the Java classpath unless custom-packaged.
Which means, possibly repackage rather E
Howdy,
just a quick idea: introduce your own packaging "quipsy-zip"? (yes, you'd
need your extension to be added to build, but it's worth it, trust me).
Look here:
https://github.com/apache/maven/blob/master/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L58
How can I keep a dependency out of all classpaths?
I do have a dependency in my project that produces a ZIP full of resources.
None of those resources is actually of any use for the Java compiler; they
solely serve as an input to third party plugins (not dealing with Java at all).
Unfortunately
On a unix system or Git Bash on Windows, cd to project root and do:
find . -name \*.jar
If you need this automatically as part of the build process then it is a
different thing. If so, consider writing a maven plugin for that. I doubt such
already exists. If on a unix system only!, there mi
That's what he wants.
The surest way is just to build the thing and `find */target -iname "*.jar"`
Need more info why its needed.
On Fri, 10 Jun 2022 at 08:40, Mantas Gridinas wrote:
> Wouldn't the help plugin get executed for every module in the reactor and
> in turn output multiple build direc
20 matches
Mail list logo
