Complex types as properties and/or profile configuration

[Alexander Broekhuis]

Hi All,

I am using a plugin that uses several complex types as configuration. This
all looks nice when having a single plugin config, with properties
grouped together. But now I want to be able to override several of these
properties via the commandline or via a profile.

Afaik, setting complex properties is not possible on the commandline. What
seems to work is to add a set(String) method to my complex type and use
some string formatting to set the property as one string.

Is this correct, or is there a better way to do this? What bothers me most
is that I need to set a list of complex types. For a list the comma is used
as a separator, so for the actual complex type some other character is
needed, which might make the format and parsing overly complicated. Perhaps
there is a cleaner solution..

Likewise, instead of setting properties via the commandline, can I somehow
add complex types to the properties section of the pom? Simply adding an
xml element to it results in errors. That it is not easily possible via the
commandline makes sense to me, but I somehow expected that it would be
possible to set them in the properties section :(.

To continue on this, in my pom I use several profiles to have different
configurations for plugins, and here I have the same issue. Is it possible
to have complex types in profiles? I know I can create a complete new
plugin configuration, but that results in a lot of duplication, which makes
the pom file quite long.

TIA!

-- 
Met vriendelijke groet,

Alexander Broekhuis

Re: How maven repositories are resolved?

[John Patrick]

The answer depends on the following;

1) is it a release version or snapshot version. As if the release
version is in local repo then no remote repo's are checked.
2) order your pom's are executed

I've simplified your profiles with central repo and company repo, and
Aa, Ab and Ac are the same GAV but it's just so in the explanation
it's easier to know what A i'm talking about.

settings
- central repo (contains Aa)
- company repo (contains Ab)

parent-pom
- alpha
-- A
- bravo (has extra R repository like your cloudera, contains Ac)
-- A
- charlie
-- A

For release version assuming empty local repo.
- Build order this time alpha, bravo, charlie
- Alpha needs A, and Aa is downloaded as it's in central repo and that
was 1st repo in the order list
- Bravo needs A, it sees Aa in local repo and uses it
- Charlie needs A, it sees Aa in local repo and uses it

Same as before but maven believe build order is bravo, alpha, charlie,
i.e. you've changed an internal dependency or reorder you modules
section.
- Bravo needs A, and Ac is downloaded as it's in R repo and that was
1st repo in the order list, which i think it's pom repo's then parent
pom's then settings file.
- Alpha needs A, it sees Ac in local repo and uses it
- Charlie needs A, it sees Ac in local repo and uses it

Next is if A is a -SNAPSHOT dependency assuming empty local repo, Aa
is v 1-1, Ab is v1-1 and Ac is v1-1
- Build order this time alpha, bravo, charlie
- Alpha needs A, and Aa is downloaded as it's in central repo and that
was 1st repo in the order list, but it has a cache of Ab existing
- Bravo needs A, it sees it doesn't have a cache of A from R repo, so
looks up A from R repo, and if Ac in R repo is newer it is downloaded
and used. in this case Aa is newer so Aa is used.
- Charlie needs A, it sees all repo's have caches of A, and just uses
the A in the local repo, in this case Aa is used.

Next is if A is a -SNAPSHOT dependency assuming empty local repo, Aa
is v 1-1, Ab is v1-1 and Ac is v1-2
- Build order this time alpha, bravo, charlie
- Alpha needs A, and Aa is downloaded as it's in central repo and that
was 1st repo in the order list, but it has a cache of Ab existing
- Bravo needs A, it sees it doesn't have a cache of A from R repo, so
looks up A from R repo, and if Ac in R repo is newer it is downloaded
and used. in this case Ac is newer so Ac is used.
- Charlie needs A, it sees all repo's have caches of A, and just uses
the A in the local repo, in this case Ac is used.



As you can see it can get very messy when -SNAPSHOT's are being used
and different pom's have repo. This is my hands-on experience of trial
and error, debugging and troubleshooting of build processes.

Hope it was helpful.

John

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

[ANN] Apache Maven Dependency Analyzer Plugin 1.11.2 Released

[Elliotte Rusty Harold]

The Apache Maven team is pleased to announce the release of the Apache
Maven Dependency Analyzer Plugin, version 1.11.2

This plugin analyzes the dependencies of a project for undeclared and
unused artifacts.

https://maven.apache.org/shared/maven-dependency-analyzer/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-dependency-analyzer
  1.11.2


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/shared/maven-dependency-analyzer/download.cgi

Release Notes - Maven Dependency Analyzer Plugin - Version 1.11.2

Bug

[MSHARED-792] - Maven Dependency Analyzer ignores Java 8 type
annotations on local variables

Improvement

[MSHARED-879] - make build Reproducible

Dependency upgrade

[MSHARED-810] - Support Java 12
[MSHARED-868] - Upgrade plexus-component-metadata to 2.1.0
[MSHARED-870] - Upgrade asm to 8.0.1

Enjoy,

-The Apache Maven team

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

How maven repositories are resolved?

[Debraj Manna]

Cross-posting from stackoverflow


Let's say my settings.xml is defined like below

http://maven.apache.org/SETTINGS/1.1.0
http://maven.apache.org/xsd/settings-1.1.0.xsd";
xmlns="http://maven.apache.org/SETTINGS/1.1.0";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
 
   
 
   
 
   false
 
 central
 libs-release
 http://artifactory.ark.local:8080/libs-release
   
   
vmware-repo
VM Nexus Repo
http://build-squid.eng.vm.com/nexus/content/groups/repo

true


false


   
 
 snapshots
 libs-snapshot
 http://artifactory.ark.local:8080/libs-snapshot
   
 
 
   
 
   false
 
 central
 plugins-release
 http://artifactory.ark.local:8080/plugins-release
   
   
 
 snapshots
 plugins-snapshot
 http://artifactory.ark.local:8080/plugins-snapshot
   
 
 artifactory
   
 
 
   artifactory
 

In a multimodule project of the form

main
storage
metrics
config
common

Let's say in metrics pom if a repository is added.


  cloudera
  
https://repository.cloudera.com/artifactory/cloudera-repos/


   1.

   If a dependency is defined in A which is present in both cloudera repo
   and local nexus repo how maven will resolve the repository? Will, it first
   try to download from cloudera repo and if there is some problem then it
   will go in local nexus repo or it will check only in cloudera repo and if
   it is not present it will give error without trying from local nexus repo?
   2.

   Does the answer to the above question change based on if A is defined as
   a dependency in metric or some other pom where the repository is not
   defined?

Maven Version - 3.6.3

Javadoc for fat/uber JAR created by Maven Shade

[Alexander Kriegisch]

I am creating fat/uber JARs in several modules as part of a multi-module
project, which is working nicely. Even aggregate sources JARs are
created via

  true

Even relocation is taken care of in the aggregate source file, very nice
actually.

So far, so good. The next step would be an aggregate Javadoc JAR, but I
cannot find any options for that in Maven Shade. Has anyone ever done
something like this before? Is there a plugin for it or do I need to
manually create an assembly or something like that if I want it? Now the
JAR for the uber JAR is almost empty, only containing the one starter
class actually contained in the module where the shaded JAR is created.
This was to be expected, but I would like to create an "uber Javadoc
JAR".

Regards

-- 
Alexander Kriegisch
https://scrum-master.de

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

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

[Robert Metzger]

Hi Stephen,

Thanks for the offer, I'll try to make sure we return the favor.

Building the current Flink master with a current maven version (3.6.3 on my
machine), leads to the distribution
(in flink/build-target/lib/flink-dist_2.11-1.12-SNAPSHOT.jar) containing
"org/jboss/netty/util" classes.
Building the same code with maven 3.2.5, the distribution will only contain
"org/apache/flink/shaded/akka/org/jboss/netty/util".

The shading is defined here:
https://github.com/apache/flink/blob/master/flink-runtime/pom.xml#L560

We would like to build Flink using current maven versions :)

Regards,
Robert

On Mon, Jul 6, 2020 at 8:43 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> You can make Maven do the right thing if you scope the shades dependencies
> correctly... but it’s a pain.
>
> Can you point me to one pom that’s a good example. I might be able to give
> some pointers in return for a bugfix :rofl:
>
> On Fri 3 Jul 2020 at 09:10, Robert Metzger  wrote:
>
> > Hi all,
> >
> > sorry for bringing up this very old thread again: The Flink project is
> > still using Maven 3.2.5 to have the shading behave as we need it. Using
> > such an old Maven version has some issues in our development workflow, as
> > the http library is quite outdated, and developers are working with much
> > newer maven versions locally, leading to some inconsistent dependency
> > resolutions.
> >
> > I was wondering if there was any progress in the last years, so that we
> can
> > switch to a newer Maven version?
> >
> > On Mon, Nov 7, 2016 at 12:04 AM Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > yes that was the advice I gave on this thread originally. you do have
> to
> > > fight a bit with the shade plugin to get them shaded in though... which
> > is
> > > why I think we may need to rethink how we do shade
> > >
> > > On 6 November 2016 at 22:36, Jörg Schaible 
> > wrote:
> > >
> > > > Stephen Connolly wrote:
> > > >
> > > > > Hmmm I did some digging...
> > > > >
> > > > >
> > > > https://maven.apache.org/ref/3.2.3/apidocs/org/apache/
> > > > maven/artifact/handler/ArtifactHandler.html#isIncludesDependencies()
> > > > > is i think the idea JvZ was hinting at.
> > > > >
> > > > > For the case where a shaded JAR shades *everything* then a custom
> > > > > packaging will work as we could set this flag and it would stop the
> > > > > transitive dependencies being propagated... but most people do not
> > > shade
> > > > > *all* dependencies, rather they shade a subset.
> > > > >
> > > > > I think we may need to re-think how we do this or rethink the model
> > > being
> > > > > read-only
> > > >
> > > > Set the shaded dependencies as optional. This might at least
> > technically
> > > > produce the proper dependency tree for dependent artifacts.
> > > >
> > > > Cheers,
> > > > Jörg
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > >
> > > >
> > >
> >
> --
> Sent from my phone
>