Re: BOM vs Parent inheritance

[Matthieu Brouillard]

Not sure the behavior in your particular case is exactly documented. but it
is sure that the depth in the dependency tree and order at the same level
plays a role.
You can find some hints inside an Andres Almiray blog post:
http://andresalmiray.com/maven-dependencies-pop-quiz-results/

One solution will always be to either define the version in your pom ; you
can also look at maven-enforcer-plugin to detect the potential differences
(convergence).

Regards,

Matthieu

On Thu, Feb 4, 2021 at 12:56 AM Rupert Madden-Abbott <
rupert.madden.abb...@gmail.com> wrote:

> Hi,
>
> I have the following structure in my pom:
>
> My pom <- import oci-java-sdk-bom <- parent = ocj-java-sdk
> ^
> |
> parent = spring-boot-starter-parent
> ^
> |
> parent = spring-boot-dependencies <- import jackson-bom
>
>
> Both jackson-bom and oci-java-sdk have a dependency management section and
> declare jackson-databind and I am also using this dependency in my pom.xml
> without specifying a version.
>
> I have found that the version from oci-java-sdk is used and not the version
> from jackson-bom (via spring boot). I naively expected that anything pulled
> in from my pom's parent would instead take precedence.
>
> Why is this? Is it because the oci-java-sdk is 2 hops from my pom and the
> jackson-bom is 3 hops? Is there anything I can do to control this such that
> the versions defined in my parent "win"?
>
> Where are these rules documented so I can work this out for myself in the
> future?
>
> Are there any tools/plugins that can help say why a given version has been
> selected?
>

Re: Maven versions plugin check far too many versions

[Matthieu BROUILLARD]

You can filter the dependencies to look at using
https://www.mojohaus.org/versions-maven-plugin/use-latest-releases-mojo.html#includesList
.

Hope it helps.

Matthieu

On Wed, Oct 14, 2020 at 12:47 AM 
wrote:

> When I run "mvn versions:use-latest-releases" it checks for example for
> versions of the following:
>
>
>
> [INFO] artifact io.dropwizard.metrics:metrics-ehcache: checking for updates
> from central
>
> [INFO] artifact io.dropwizard.metrics:metrics-ehcache: checking for updates
> from snapshots
>
> [INFO] artifact io.dropwizard.metrics:metrics-graphite: checking for
> updates
> from central
>
> [INFO] artifact io.dropwizard.metrics:metrics-graphite: checking for
> updates
> from snapshots
>
>
>
> The lists goes on and on and on - but the problems is that my project does
> not use this dependencies - although it does include spring-parent as
> dependency and these packages are declared here. Is there a way to tell the
> plugin not to check for dependencies from some pom? My projects uses five
> dependencies and waiting 20 minutes (!) for these checks to be complete is
> an absolute waste of time.
>
>
>
> JD
>
>
>
>

Re: Maven moving to the next level: the build/consumer pom

[Matthieu BROUILLARD]

Hi Robert,

congrats this looks like a great achievement.

I presume that the consumer pom means the end of the flatten plugin or is
there still some benefit in using flatten plugin?

> dependencies that are part of the reactor don't need a version anymore
What is meant here ? Is it that in a multimodule project a dependency from
a module to another of the same multimodule does not need the version ? For
example when having an api and impl in the same multimodule, the impl will
not require the version of the api?

> These are implemented steps to get from the file model to the raw model,
where the required versions are added.
Are those replacements still part of the pom loading by ModelProcessor?
I'll give it a try especially to see the compliance with my existing core
extensions.

Matthieu Brouillard

On Mon, Jun 22, 2020 at 11:18 PM Robert Scholte 
wrote:

> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the  is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> -  from  will be removed
> -  from  will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM

Re: Launching full Maven programmatically

[Matthieu BROUILLARD]

Sorry but it is fully in the subject of the thread.
Andres wants a way to programatically load a POM object. I guess he wants a
way to load a correctly resolved POM not a partially resolved one.

On Fri, Apr 17, 2020 at 11:02 AM Olivier Lamy  wrote:

> yes maybe some stuff to fix (feel free to send a PR :P )
> But it's not the subject of the thread :)
> But did you try without all the Jenkins but only the mentioned library?
> It's not too hard to fix (the code pointed in this thread may have the same
> issue)
>
>
> On Fri, 17 Apr 2020 at 18:49, Matthieu BROUILLARD 
> wrote:
>
> > Olivier,
> >
> > If the project you are pointing is what is behind "Maven Integration" in
> > Jenkins then it does things wrong by not taking into account maven
> > core-extensions.
> >
> > I just retested now:
> > - download Jenkins.war 2.232
> > - launch as java -jar
> > - default installation
> > - add plugin "Maven integration"
> > - in settings add a local JDK 11
> > - in settings add a default maven 3.6.3
> > - create new job "jgitver in jenkins"
> > - set git url : https://github.com/jgitver/jgitver.git
> > - set goal : validate
> > - run the job
> >
> > You will see in the output that the version of the project is 0 whereas
> it
> > should have been computed by a core extension.
> >
> > ...
> > [INFO] -< fr.brouillard.oss:jgitver
> > >--
> > [INFO] Building GIT versioning using jgit 0
> > [INFO] [ jar
> > ]-
> > ...
> >
> >
> > If you do the same in CMD/sh you should see the automatic computation
> >
> > [INFO] Using jgitver configuration file:
> > C:\workspace\projects\oss\jgitver\jgitver-lib\.mvn\jgitver.config.xml
> > [INFO] Using jgitver-maven-plugin [1.5.1] (sha1:
> > e45d1669b39cedb98720dd33cc14d0185b455ca1)
> > [INFO] version '0.12.1-SNAPSHOT' computed in 15595 ms
> > [INFO]
> > [INFO] Scanning for projects...
> > [INFO] jgitver-maven-plugin is about to change project(s) version(s)
> > [INFO] fr.brouillard.oss::jgitver::0 -> 0.12.1-SNAPSHOT
> > [INFO]
> > [INFO] -< fr.brouillard.oss:jgitver
> > >--
> > [INFO] Building GIT versioning using jgit 0.12.1-SNAPSHOT
> > [INFO] [ jar
> > ]-
> > ...
> >
> > This is not particular to jgitver but to any core extension (takari
> > polyglot, tycho pom less, ...).
> > The way this jenkins project loads the Maven Project Object Model is
> > somehow wrong or at least not complete.
> >
> > IMO the POM loading is better done in maven-flatten-plugin.
> >
> > Matthieu
> >
> > On Fri, Apr 17, 2020 at 6:00 AM Olivier Lamy  wrote:
> >
> > > Hi,
> > >
> > > That's the way to do it
> > > There is a library to ease that here
> > > https://github.com/jenkinsci/lib-jenkins-maven-embedder/tree/master
> > >
> > > cheers
> > > Olivier
> > >
> > >
> > > On Fri, 17 Apr 2020 at 13:04, Tomo Suzuki 
> > > wrote:
> > >
> > > > I'm interested in that problem too. In the project below, we use
> > > > PlexusContainer to instantiate MavenProject class from pom file:
> > > >
> > > >
> > >
> >
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/dependencies/src/main/java/com/google/cloud/tools/opensource/dependencies/RepositoryUtility.java#L209
> > > >
> > > > I hope there's a better way to achieve this.
> > > >
> > > > On Thu, Apr 16, 2020 at 6:55 AM Andres Almiray 
> > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I'm looking for a way to launch Maven programmatically in such a
> way
> > > > that I
> > > > > can get access to fully resolved Model and MavenProject instances,
> > and
> > > > not
> > > > > just for a single project but also for all projects that belong to
> a
> > > > > Reactor.
> > > > >
> > > > > At first I used this code
> > > > >
> > > > > try {
> > > > > FileReader reader = new FileReader(pom);
> > > > > MavenXpp3Reader mavenReader = new MavenXpp3Reader();
> > > > > return new MavenProject(mavenReader.read(reader));
&

Re: Launching full Maven programmatically

[Matthieu BROUILLARD]

Olivier,

If the project you are pointing is what is behind "Maven Integration" in
Jenkins then it does things wrong by not taking into account maven
core-extensions.

I just retested now:
- download Jenkins.war 2.232
- launch as java -jar
- default installation
- add plugin "Maven integration"
- in settings add a local JDK 11
- in settings add a default maven 3.6.3
- create new job "jgitver in jenkins"
- set git url : https://github.com/jgitver/jgitver.git
- set goal : validate
- run the job

You will see in the output that the version of the project is 0 whereas it
should have been computed by a core extension.

...
[INFO] -< fr.brouillard.oss:jgitver >--
[INFO] Building GIT versioning using jgit 0
[INFO] [ jar ]-
...


If you do the same in CMD/sh you should see the automatic computation

[INFO] Using jgitver configuration file:
C:\workspace\projects\oss\jgitver\jgitver-lib\.mvn\jgitver.config.xml
[INFO] Using jgitver-maven-plugin [1.5.1] (sha1:
e45d1669b39cedb98720dd33cc14d0185b455ca1)
[INFO] version '0.12.1-SNAPSHOT' computed in 15595 ms
[INFO]
[INFO] Scanning for projects...
[INFO] jgitver-maven-plugin is about to change project(s) version(s)
[INFO] fr.brouillard.oss::jgitver::0 -> 0.12.1-SNAPSHOT
[INFO]
[INFO] -< fr.brouillard.oss:jgitver
>--
[INFO] Building GIT versioning using jgit 0.12.1-SNAPSHOT
[INFO] [ jar
]-
...

This is not particular to jgitver but to any core extension (takari
polyglot, tycho pom less, ...).
The way this jenkins project loads the Maven Project Object Model is
somehow wrong or at least not complete.

IMO the POM loading is better done in maven-flatten-plugin.

Matthieu

On Fri, Apr 17, 2020 at 6:00 AM Olivier Lamy  wrote:

> Hi,
>
> That's the way to do it
> There is a library to ease that here
> https://github.com/jenkinsci/lib-jenkins-maven-embedder/tree/master
>
> cheers
> Olivier
>
>
> On Fri, 17 Apr 2020 at 13:04, Tomo Suzuki 
> wrote:
>
> > I'm interested in that problem too. In the project below, we use
> > PlexusContainer to instantiate MavenProject class from pom file:
> >
> >
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/dependencies/src/main/java/com/google/cloud/tools/opensource/dependencies/RepositoryUtility.java#L209
> >
> > I hope there's a better way to achieve this.
> >
> > On Thu, Apr 16, 2020 at 6:55 AM Andres Almiray 
> wrote:
> >
> > > Hi,
> > >
> > > I'm looking for a way to launch Maven programmatically in such a way
> > that I
> > > can get access to fully resolved Model and MavenProject instances, and
> > not
> > > just for a single project but also for all projects that belong to a
> > > Reactor.
> > >
> > > At first I used this code
> > >
> > > try {
> > > FileReader reader = new FileReader(pom);
> > > MavenXpp3Reader mavenReader = new MavenXpp3Reader();
> > > return new MavenProject(mavenReader.read(reader));
> > > } catch (Exception e) {
> > > throw new IllegalArgumentException(e);
> > > }
> > >
> > > But of course that's not enough. Next I tried using the
> > maven-model-builder
> > > APIs directly but not all references get resolved (such as parent POMs)
> > as
> > > a custom ModelResolver is required and the default one is not intended
> to
> > > be used in standalone fashion.
> > >
> > > Ideally I would call some sort of embeddable Maven API that can give me
> > the
> > > answers I seek, something like this
> > >
> > > MavenProject project =
> > EmbeddableMaven.launch(propsOrFlags).file(pomFile);
> > >
> > > or alternatively something like
> > >
> > > MavenReactor reactor =
> > EmbeddableMaven.launch(propsOrFlags).file(pomFile);
> > > for(MavenProject project : reactor.getProjects()) { /* do stuff */ }
> > >
> > > Of course I'm making up these types and method names as I do not know
> if
> > > something like this exist or not, hence why I'm asking here.
> > >
> > > Thanks in advance.
> > >
> > > Cheers
> > > Andres
> > >
> >
> >
> > --
> > Regards,
> > Tomo
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: Launching full Maven programmatically

[Matthieu BROUILLARD]

I understood your need Andreas. Look at the plugin, if I remember well at
some point it "reloads/recreate" from scratch the Model ; as you would do
in your own code ; to be able to later flatten it.

Regards,

Matthieu

On Thu, Apr 16, 2020 at 4:31 PM Andres Almiray  wrote:

> Thanks Matthieu, I'll have a look.
>
> Though I failed to specify: the embedded API I'm looking for should work
> anywhere and not just within the confinement of a maven plugin where Maven
> components and services exist, that is, this API should work as a blackbox
> and in standalone mode.
>
> Cheers,
> Andres
>
> On Thu, Apr 16, 2020 at 3:13 PM Matthieu BROUILLARD <
> matth...@brouillard.fr>
> wrote:
>
> > Hi,
> >
> > If I remember well I think maven-flatten-plugin loads the model in a way
> > that even core-extensions are used; you should have a look there.
> >
> > Matthieu
> >
>

Re: Launching full Maven programmatically

[Matthieu BROUILLARD]

Hi,

If I remember well I think maven-flatten-plugin loads the model in a way
that even core-extensions are used; you should have a look there.

Matthieu

Re: Best Practice for distributing test utilities?

[Matthieu BROUILLARD]

Hi Andreas,

In your use case I would keep everything in the same foo project but I
would generate a kind of 'testutils' jar.

>From what I understood your project structure is a bit like

foo
   src/main/java
   src/test/java
  com.yourcompany.tests.utils
  com.yourcompany.tests.yourtests


Then using `maven-jar-plugin` (see [1]) I would generate a dedicated jar
with classifier 'testutils' using only tests classes of
com.yourcompany.tests.utils package (filter what you need) resulting in
producing/publishing an additional foo-X.Y.Z-testutils.jar

Then client projects would need to use 2 dependencies


foo
X.Y.Z


foo
X.Y.Z
testutils
jar
test


Hope it can help.

Matthieu

[1] :
https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html


On Fri, Mar 13, 2020 at 1:49 PM Nick Stolwijk 
wrote:

> Put the testutils and the tests in the same project as foo in src/test/java
> and make the tests package private (JUnit Jupiter). Other projects can
> depend on the test artifact of foo and only use the test-utils.
>
> 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 Fri, Mar 13, 2020 at 12:01 PM Zak Mc Kracken  >
> wrote:
>
> > On 12/03/2020 13:55, Andreas Sewe wrote:
> >
> > If the test utilities are simple enough and are somehow specific to foo,
> > I would put them into foo, under src/main/java, in a package like
> > com.foo.testing. If they are more general, so that they could be used to
> > write tests for some other package not related to foo, I would create a
> > test-utils module. For instance, a utility to verify that an SQL string
> > parameter yields a given result parameter would go into such a module.
> >
> > If the test utils so complex that foo would become too big and would
> > drag too many not-often-used dependencies, but they're foo-specific, I
> > would create the module foo-test-utils and both foo and foo-testing
> > would depend on it. This is similar to creating test-utils.
> >
> > Option 3 creates a circular dependency and it's not to clean anyway
> > (even if you had a way to remove the circularity from the technical
> > point of view, it would remain at conceptual level). Attaching tests
> > seems to be less clear and forces a dependant to link all the tests just
> > to be able to include some utility. I happened to do it only for already
> > existing and hard-to-refactor projects, and only for the purpose making
> > the dependant extract some common files inside test/resources.
> >
> > Hope it helps,
> > Marco
> >
> > > Hi,
> > >
> > > I am struggling to figure out what the Maven Way is for distributing
> > > test utils.
> > >
> > > Say I have a project "foo" along with some unit tests for it. Moreover,
> > > I have some utilities that help in testing "foo" (e.g., test data
> > > builders or test fixtures). These utilities are used by the unit tests
> > > for "foo", but may also be useful to projects depending on "foo" (e.g.,
> > > a FooTestDataBuilder that produces Foo instances could also be used in
> > > the tests of a dependent project "bar").
> > >
> > > The question is where to place these test utilities and how to depend
> on
> > > them.
> > >
> > > 1. I could follow the "guide to using attached tests" [1], place the
> > > test utilizes in foo/src/test/java, and attach the test-jar to "foo".
> > > Then, a dependent project "bar" could depend on the test-jar in its
> test
> > > scope. Alas, as the test scope is not transitive, I would need to
> > > declare all test-dependencies of "foo" again in "bar", even though I
> may
> > > not even use them directly (e.g., if the FooTestDataBuilder uses them
> > > only internally).
> > >
> > > 2. I could split "foo" into three projects: "foo", "foo-test-utils",
> and
> > > "foo-tests", with the latter depending on both "foo-test-utils" and
> > > "foo-tests". A project "bar" would then simply depend on "foo" in
> > > compile scope and "foo-test-utils" in test scope. This would make all
> > > dependencies explicit, but would result in some oddities, e.g.,
> > > foo-tests/src/main/java being empty, as all tests need to be placed in
> > > tests/src/test/java to be picked up by Surefire.
> > >
> > > 3. I could split "foo" into just two projects, "foo" and "foo-testing".
> > > foo-testing/src/main/java would the contain the test utilities for
> > > "foo", whereas foo-testing/src/test/java would contain the actual
> tests.
> > > This is again somewhat odd, as the tests in foo-testing/src/test/java
> > > are not testing "foo-testing" but "foo".
> > >
> > > 4. Option 4 is the most natural way, but unfortunately it doesn't work,
> > > because it introduces a cyclic dependency: Have "foo" and
> > > "foo-test-utils" and let the tests of "foo" depend on "foo-test-utils".
> > >
> > > Am I 

Re: Use latest versions vs use latest releases

[Matthieu Brouillard]

Hi Nick,

In several companies I have worked for, including the current one, we:

   - used 'update-properties' & 'update-parent' goals only
   - defined a property for each dependency/plugin version in all our poms
   - provided a global enterprise wide 'rules.xml' see [1] & [2]
   - used restrictions for some properties [3] (search for `If you want to
   restrict updates to within a specific range` in the page)

This was always automated in the CI so that we received on our projects a
PR with the required changes to update.

Hope it helps.

Matthieu

[1] :
https://www.mojohaus.org/versions-maven-plugin/update-properties-mojo.html#rulesUri
[2] : https://www.mojohaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd
[3] :
http://www.mojohaus.org/versions-maven-plugin/examples/update-properties.html

On Wed, Mar 11, 2020 at 10:00 AM Nick Stolwijk 
wrote:

> We are trying to upgrade the dependencies of our projects by using the
> Maven Versions plugin. I read the page at the Maven Versions plugin[1] and
> I am confused. The goal description for use-latest-releases reads:
> `searches
> the pom for all non-SNAPSHOT versions` while the table reads that only
> -SNAPSHOT dependencies are considered. On the other hand there is the
> use-latest-versions goal which says: `searches the pom for all versions
> which have been a newer version` and considers release and snapshot
> versions according to the table. Based on that information I think I need
> use-latest-versions. Am I correct?
>
> There is only a problem with use-latest-versions. It replaces properties
> and instead using the versions itself[2]. Although that issue is closed as
> won't fix.
>
> If I use use-latest-releases I stumble upon issue 346[3], which has a fix
> in a fork, but isn't yet merged.
>
> Which goal is the correct goal, which issues are still open issues and what
> is needed to make this more clear?
>
> [1]
>
> https://www.mojohaus.org/versions-maven-plugin/examples/advancing-dependency-versions.html
> [2] https://github.com/mojohaus/versions-maven-plugin/issues/109
> [3] https://github.com/mojohaus/versions-maven-plugin/issues/346
>
> With regards,
>
> 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
>

MNG-6685, JSR330, & ModelBuilder provided by extensions

[Matthieu BROUILLARD]

Hi,

the issue MNG-6685 & commits associated (
https://github.com/apache/maven/pull/256) seem to have broken extensions
that provide their own ModelProcessor implementation via ` @Component(role
= ModelProcessor.class)`

How should extension declare the ModelProcessor they provide now? Is there
a documentation of the change?

Matthieu

Re: Failures building Eclipse 4.13 with maven-3.6.2

[Matthieu BROUILLARD]

Hello,

it looks like maven-3.6.2 really introduced a non compatible change with
[core?] extensions and not just on polyglot-maven.

In my own core extension project (jgitver-maven-plugin), when using
maven-3.6.2, the ModelProcessor that I provide is not called anymore.
Hope that helps to track down the culprit change.

Matthieu

On Sat, Sep 14, 2019 at 10:53 AM Enrico Olivelli 
wrote:

> Any volunteer to work on a fix?
>
> Enrico
>
> Il sab 14 set 2019, 10:08 Jonathan Chen  ha scritto:
>
> > Hi,
> >
> > I didn't find a matching issue, so I raised MNG-6765 so that it can be
> > tracked.
> > https://issues.apache.org/jira/browse/MNG-6765
> >
> > Cheers.
> > --
> > Jonathan Chen 
> >
> > On Sat, 14 Sep 2019 at 19:47, Jonathan Chen  wrote:
> > >
> > > Hi,
> > >
> > > Thanks for that. Is there a JIRA reference for this bug?
> > >
> > > Cheers.
> > > --
> > > Jonathan Chen 
> > >
> > > On Sat, 14 Sep 2019 at 17:39, Jeff MAURY  wrote:
> > > >
> > > > This is a know case between tycho pomless and maven 3.6.2
> > > >
> > > > Le sam. 14 sept. 2019 à 05:26, Jonathan Chen  a
> > écrit :
> > > >
> > > > > Hi,
> > > > >
> > > > > I'm currently attempting to build Eclipse 4.13 from source using
> > > > > maven-3.6.2, and I'm seeing these current failures:
> > > > > [INFO] Scanning for projects...
> > > > > [ERROR] [ERROR] Some problems were encountered while processing the
> > POMs:
> > > > > [FATAL] Non-readable POM
> > > > >
> > > > >
> >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation10/.polyglot.build.properties:
> > > > > input contained no data @
> > > > > [FATAL] Non-readable POM
> > > > >
> > > > >
> >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation11/.polyglot.build.properties:
> > > > > input contained no data @
> > > > > [FATAL] Non-readable POM
> > > > >
> > > > >
> >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.feature/.polyglot.build.properties:
> > > > > input contained no data @
> > > > > [FATAL] Non-readable POM
> > > > >
> > > > >
> >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se12/.polyglot.build.properties:
> > > > > input contained no data @
> > > > > [FATAL] Non-readable POM
> > > > >
> > > > >
> >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se13/.polyglot.build.properties:
> > > > > input contained no data @
> > > > > [FATAL] Non-readable POM
> > > > >
> > > > >
> >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se14/.polyglot.build.properties:
> > > > > input contained no data @
> > > > > [FATAL] Non-readable POM
> > > > >
> > > > >
> >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se15/.polyglot.build.properties:
> > > > > input contained no data @
> > > > > [FATAL] Non-readable POM
> > > > >
> > > > >
> >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase16/.polyglot.build.properties:
> > > > > input contained no data @
> > > > > [FATAL] Non-readable POM
> > > > >
> > > > >
> >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase17/.polyglot.build.properties:
> > > > > input contained no data @
> > > > > ...
> > > > >
> > > > > It appears that the pom-less builds are failing due to a missing
> > > > > .polyglot.build.properties. These are transient files that are
> > removed
> > > > > once the compiling JVM exits. Something in the 3.6.2 lifecycle has
> > > > > changed such that the files are not staying long enough to be
> > > > > available for dependency-resolution.
> > > > >
> > > > > If I downgrade to maven-3.6.1 or maven-3.6.0, these errors do not
> > arise.
> > > > >
> > > > > Cheers.
> > > > > --
> > > > > Jonathan Chen 
> > > > >
> > > > >
> -
> > > > > 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: Using Git tags to cut releases to Maven Central from TravisCI

[Matthieu BROUILLARD]

Hi Herve,

you're right for the source tarball, if it is a need for you or your
project then your need a not so clever solution.
everything depends on the needs. If a project needs an offline build then
maven will probably fail also.

The thing is that part of maven users would like the build process to be
smarter than it is today and even if you tomorrow you modify only the root
pom then you'll have two commits.
jgitver, like other core extension, tries to bring some new capabilities
which bring value to the users who want those features:
- no commit for version management
- naming in branch
- shared & enforced automatic project policy to compute project version
- ...

We're probably no so aligned in this area of having the version changes in
the source control but that's also good to me ; it reflects different needs
in the community.
And the fact that people try to find workarounds to the 'standard' way of
doing things prove that there is some place for additional workflows/tools
like jgitver.

Regards,

Matthieu

On Fri, Aug 2, 2019 at 8:03 AM Hervé BOUTEMY  wrote:

> thank you Matthieu for sharing
>
> to me, one key interesting part is:
> > An issue with solutions like yours is reproducibility : `git checkout
> X.Y.Z
> > && mvn install`will not build again artifact-X.Y.Z ; but this can be
> > considered minor depending on the use cases & needs.
>
> and with jgitver, there is the equivalent reproducibility issue: if a
> release
> creates a source tarball to be able to download and rebuild independently
> from
> source control (= something that is mandatory at Apache level, and IMHO a
> good
> practice), both Ben solution and jgitver fail at rebuilding
>
> I personally find these version changing commits *a key useful feature*:
> when I
> checkout any point in a projet scm history, whatever the scm (no Git is
> not
> the only scm in the world), I precisely know what precise version I'm
> building
> (be it a SNAPSHOT, where by definition the version is fuzzy, or a release
> where
> the version is strictly defined at a precise state for the whole source
> tree)
>
>
> What Maven could do better to me is avoiding modifying every pom.xml file
> in
> multi-module project: yes, here, modifying only the root pom would be an
> improvement.
> I know there is a MNG Jira issue (even if I can't find it right now)
>
>
> But definitely, trying to remove versions changes at source level seems to
> me
> not not a good objective because these commits are useful: the codebase is
> really switching from PREV-SNAPSHOT to RELEASE to NEXT-SNAPSHOT
> And even the fact that:
> - you can't really predict how RELEASE value will really be related to PREV
> - you'll have to make a guess at choosing NEXT
> proves that these changes at source level are useful.
> What we should do is making them easier
>
> Regards,
>
> Hervé
>
> Le jeudi 1 août 2019, 11:23:33 CEST Matthieu BROUILLARD a écrit :
> > Hi Ben,
> >
> > several years ago I created jgitver <https://jgitver.github.io> to cover
> > such a use case and even more.
> >
> > It uses git information (tags, branches, commits, metadatas, ...) to
> > automatically compute a version based on configurable rules.
> > So like you I can simply do: `git tag X.Y.Z && mvn deploy`
> > jgitver <https://jgitver.github.io> brings more features & configuration
> > capabilities without never modifying the pom files (like `mvn versions
> > -dnewVersion` does).
> >
> > It is a solution among others but it is worthwhile trying it.
> >
> > An issue with solutions like yours is reproducibility : `git checkout
> X.Y.Z
> > && mvn install`will not build again artifact-X.Y.Z ; but this can be
> > considered minor depending on the use cases & needs.
> >
> > FYI here are the projects I maintain related to the topic:
> >
> >- jgitver library: https://github.com/jgitver/jgitver
> >- jgitver maven extension:
> >https://github.com/jgitver/jgitver-maven-plugin
> >- jgitver gradle plugin:
> https://github.com/jgitver/gradle-jgitver-plugin
> >
> > Regards,
> >
> > Matthieu
> >
> > On Wed, Jul 31, 2019 at 5:51 PM Ben Podgursky 
> wrote:
> > > I've been experimenting with setting up Maven Central publishing from a
> > > TravisCI build (since it's free for my OSS GitHub project), and I
> ended up
> > > with a pattern that I think is pretty nice to work with (I've struggled
> > > with the maven-deploy-plugin in the past).
> > >
> > > I've written it up here
> > >
> > >
> https://bpodgursky.com/2019/07/31/using-travisci-to-deploy-to-mave

Re: Using Git tags to cut releases to Maven Central from TravisCI

[Matthieu BROUILLARD]

Hi Ben,

several years ago I created jgitver  to cover
such a use case and even more.

It uses git information (tags, branches, commits, metadatas, ...) to
automatically compute a version based on configurable rules.
So like you I can simply do: `git tag X.Y.Z && mvn deploy`
jgitver  brings more features & configuration
capabilities without never modifying the pom files (like `mvn versions
-dnewVersion` does).

It is a solution among others but it is worthwhile trying it.

An issue with solutions like yours is reproducibility : `git checkout X.Y.Z
&& mvn install`will not build again artifact-X.Y.Z ; but this can be
considered minor depending on the use cases & needs.

FYI here are the projects I maintain related to the topic:

   - jgitver library: https://github.com/jgitver/jgitver
   - jgitver maven extension:
   https://github.com/jgitver/jgitver-maven-plugin
   - jgitver gradle plugin: https://github.com/jgitver/gradle-jgitver-plugin

Regards,

Matthieu

On Wed, Jul 31, 2019 at 5:51 PM Ben Podgursky  wrote:

> I've been experimenting with setting up Maven Central publishing from a
> TravisCI build (since it's free for my OSS GitHub project), and I ended up
> with a pattern that I think is pretty nice to work with (I've struggled
> with the maven-deploy-plugin in the past).
>
> I've written it up here
>
> https://bpodgursky.com/2019/07/31/using-travisci-to-deploy-to-maven-central-via-git-tagging-aka-death-to-commit-clutter/
> but
> tl,dr, the key thing I haven't seen used widely is the use of tags to
> define release versions, eg:
>
> ```
> if [ ! -z "$TRAVIS_TAG" ]
> then
> mvn --settings "${TRAVIS_BUILD_DIR}/.travis/mvn-settings.xml"
> org.codehaus.mojo:versions-maven-plugin:2.1:set -DnewVersion=$TRAVIS_TAG
> 1>/dev/null 2>/dev/null
> else
> echo "No tags, using snapshot version from pom.xml"
> fi
>
> mvn deploy -P publish -DskipTests=true --settings
> "${TRAVIS_BUILD_DIR}/.travis/mvn-settings.xml"
> ```
>
> This lets me cut a central release by just pushing a tag:
>
> ```
> $ git tag 1.23
> $ git push origin 1.23
> ```
>
> I've used Maven a fair amount but I wouldn't consider myself perfectly in
> tune with best practices, so I'm curious what others think of this
> approach, or if there are other streamlined central deploy setups
> (especially from CI/Travis) that I missed.
>
>
> Thanks,
>
> Ben
>

Re: Maven question - how to pull code from bitbucket repository as dependency

[Matthieu BROUILLARD]

If your script is hosted on SVN or git then you can also perhaps do a
simple GET on a well know resources (SHA1 or tag) on the raw file directly.
That way the download is easy and you have a reproducible build because you
target a fixed version of the script.

Matthieu

On Wed, Jun 12, 2019 at 8:11 AM Thorsten Heit  wrote:

> Hi,
>
> > I have a maven project that builds Java jar files. I wan to run a python
> > script as one of the goals in the verify phase. I am planning to use the
> > ant run plugin for running the python script. The python script is
> stored
> > in a separate repository that I would like to copy to my project root
> > folder using maven. Is this possible? What's the best way to approach
> this?
>
> Although I have to admin I never tried it ;-), but two ideas:
>
> 1) Use the JGit Ant task ([1]) to checkout your source code before you
> execute the python script from within the Ant task.
>
> 2) Add a second plugin configuration for maven scm that is being executed
> in the verify phase. Configure the scm plugin and add at least the
> (developer) connection url, and perhaps the destination (checkout)
> directory in which your script is to be stored. See [2].
>
>
>
>
> [1] https://wiki.eclipse.org/JGit/User_Guide#Ant_Tasks
> [2] https://maven.apache.org/scm/maven-scm-plugin/checkout-mojo.html
>
> HTH
>
> Thorsten

Re: Would it make sense to publish a WAR to maven central?

[Matthieu BROUILLARD]

Why couldn't you publish as a war?
AFAIK Central is not restricted to be a jar library.
You can already find wars in central :
https://search.maven.org/search?q=p:war

Regards

Matthieu

On Thu, May 30, 2019 at 2:40 PM Russell Gold 
wrote:

> The open source Weblogic Monitoring Exporter <
> https://github.com/oracle/weblogic-monitoring-exporter> is a set of
> servlets that works as an exporter for Prometheus. Building it involves two
> steps: one build compiles the servlets and the second assembles them into a
> WAR, in which a configuration file is embedded. Currently, users clone the
> repository and run both builds, but that means that they generally work
> with the latest commits. I am thinking that it makes more sense to publish
> it to maven central, but am looking for guidance. Is it customary to
> publish WARs to central? In such a case, I would combine the builds, and a
> simple shell command or script could supply the configuration. Or would it
> be best to publish the JAR containing the servlets and have users run the
> second build to create the WAR?
>
> Thanks,
> Russ

Re: A import B and B should import A where it is included

[Matthieu BROUILLARD]

As Anthony said as you have a chicken-egg problem and you need to break the
cycle somehow.

To cut the loop I would eventually either:

Solution 1: split the projects into:
   1. the library itself without tests
   2. the test library, depending on the lib
   3. the library tests depending on both the lib and the test library

Solution 2: use a previous version of test lib
Here your framework could depend on your test lib in version N-1. The
layout would be:
1. library version N and its tests depending on test-lib version N-1
2. test framework library version N


The first solution is easier I think and allows to develop & use new
features (in both lib & test lib) without having to release to be able to
use them.

Matthieu


On Mon, Mar 25, 2019 at 10:44 PM Anthony Whitford 
wrote:

> You can specify a dependency version using an expression like this:
> ${project.version}
>
> ${project.version} refers to the POM’s project/version value.
>
> Note that you can declare project properties, and use those in expressions
> too.  See this for more details:
>  -
> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html
> <
> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html
> >
>
>
> Having said that…. It sounds like you have a chicken-egg problem and that
> really needs to be fixed.  While Maven certainly supports dynamic
> dependency management, it will highlight and prevent poor software
> engineering practices such as cyclic dependencies.  You will discover that
> even if you can get a cyclic build working, the release process will be
> broken.  And, you will undoubtedly run into build race conditions and other
> bad things.
>
> So, you need to figure out how to isolate the common dependencies into a
> third library to break the cyclic dependency.  Instead of something like
> this:
>  -  A depends on B, B depends on A (BAD!)
> How about:
>  -  A depends on C, B depends on C (OK!)
>
> C may be just Interfaces — maybe no implementation.
> Your Tess can depend on A — but A should not depend on the Tests — it
> defeats the value of isolating the Tests.
>
>
> Hope this helps,
>
> Anthony
>
>
> > On Mar 25, 2019, at 11:28 AM, Philipp Kraus <
> philipp.kr...@tu-clausthal.de> wrote:
> >
> > Hello,
> >
> > I am building an additional testing framework for my framework. I now
> have the following cyclic import of the dependencies "MyFramework imports
> MyTestingFramework" and "MyTestingFramework imports MyFramework".
> > For example, if MyFramework is version 0.2.1-SNAPSHOT, then
> MyTestingFramework should use the version 0.2.1-SNAPSHOT. Is there a way to
> get the dependency dynamically?
> >
> > I hope it was understandable
> > Thanks a lot
> >
> > Phil
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>

Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin

[Matthieu BROUILLARD]

Hi,

I have faced the same problem recently on jgitver maven core dependency (
https://github.com/jgitver/jgitver-maven-plugin/issues/109).
In fact, the problem popped up when a *fork* execution occures after that
the pom file has been relocated.
When this occures the basedir is computed as the directory containing the
pom which is not what is expected and leads to issues.
Unfortunatelly my plugin already calls the 'good' api by calling setPomFile
when it can (
https://github.com/jgitver/jgitver-maven-plugin/blob/master/src/main/java/fr/brouillard/oss/jgitver/JGitverUtils.java#L127
).

So if you have a plugin that fires a fork execution you should be able to
reproduce.

I have not tested yet the above fork scenario with pom relocation outside
of project dir with flatten-maven-plugin.

Regards,

Matthieu



On Sun, Jan 13, 2019 at 3:10 PM Mikael Åsberg 
wrote:

> Hi Hervé, and thanks for your reply! So it sounds like since
> maven-shade-plugin still has not been updated to use the new API, the
> problem should still be there. But did you check my test project? I thought
> it would capture the problem, if it was still there and I understood it
> correctly, but I guess the project is bogus somehow since it doesn't
> capture the issue. I would like to understand how my test project is faulty
> so I understand the issue properly. Is there a Jira for maven-shade-plugin
> which tracks the issue (an issue which could be solved by using the new API
> you mentioned)?
>
> Regards, Mikael
>
> On Sun, Jan 13, 2019, 10:43 Hervé BOUTEMY 
> > Hi
> >
> > Good question: I did not yet find the official answer, but I can share
> > what I
> > know on this.
> >
> > flatten-maven-plugin has the exact same issue, and this was fixed in the
> > past
> > by adding a new API in Maven core (in 3.2.5) to be called by the plugin:
> > see https://github.com/mojohaus/flatten-maven-plugin/pull/30
> >
> > I just had a look at maven-shade-plugin source and found
> "project.setFile(
> > dependencyReducedPomLocation );": this call has not been replaced by
> > setPomFile() API.
> > That means that the limitation on the chosen directory should still be
> here
> >
> > Hope this helps...
> >
> > Regards,
> >
> > Hervé
> >
> > Le mercredi 9 janvier 2019, 15:06:26 CET Mikael Åsberg a écrit :
> > > Hi, the documentation for dependencyReducedPomLocation says:
> > > "Where to put the dependency reduced pom. Note: setting a value for
> > > this parameter with a directory other than ${basedir} will change the
> > > value of ${basedir} for all executions that come after the shade
> > > execution. This is often not what you want. This is considered an open
> > > issue with this plugin."
> > >
> > >
> >
> https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependen
> > > cyReducedPomLocation
> > >
> > > I created a small test project which performs a shade in the package
> > > phase (with the dependencyReducedPomLocation set to the
> > > ${project.build.directory} and then I print the value (using
> > > gmavenplus-plugin) of ${project.basedir} in the verify phase (which
> > > comes after package as you know). I don't see that the value of
> > > basedir has changed (which is good), is this part of the documentation
> > > incorrect or is my test project wrong (i.e., did I misunderstood the
> > > possibly undesirable side-effect to ${basedir} by setting
> > > dependencyReducedPomLocation)?
> > >
> > > You can find my test project here:
> > https://github.com/masberg/mshadeissue
> > >
> > > - Mikael
> > >
> > > -
> > > 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: How to rewrite POMs retaining the XML structure

[Matthieu BROUILLARD]

You say you do modification in the POM to add/remove dependencies &
properties.
Do you really need to modify the pom.xml of your project for that?
You could also do those additions using a plugin/extension and work on the
POM and just deploy a materialized pom.xml from the POM for publication
purposes without having to touch the original pom.xml file.

Matthieu

On Fri, Nov 30, 2018 at 12:13 PM Matthieu BROUILLARD 
wrote:

> @Marc Rohlfs : AFAIK if you do a modification in the POM (as project
> object model) in memory (via a plugin probably) then the pom.xml file is
> already behind you and comments are already lost during the loading phase
> of the POM. Whatever the materialization of the POM you choose, comments
> will be lost.
>
>
> On Fri, Nov 30, 2018 at 9:57 AM Oliver B. Fischer <
> o.b.fisc...@swe-blog.net> wrote:
>
>> I do it with the release tools for jQAssitant with XSLT like this
>>
>> https://github.com/buschmais/jqa-release-tool/blob/master/core/src/main/resources/xsl/update-version-property.xsl
>>
>> The Versions plugin does it via Stax.
>>
>> Best,
>>
>> Oliver
>>
>> Am 29.11.18 um 17:11 schrieb Marc Rohlfs:
>> > 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
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Re: How to rewrite POMs retaining the XML structure

[Matthieu BROUILLARD]

@Marc Rohlfs : AFAIK if you do a modification in the POM (as project object
model) in memory (via a plugin probably) then the pom.xml file is already
behind you and comments are already lost during the loading phase of the
POM. Whatever the materialization of the POM you choose, comments will be
lost.


On Fri, Nov 30, 2018 at 9:57 AM Oliver B. Fischer 
wrote:

> I do it with the release tools for jQAssitant with XSLT like this
>
> https://github.com/buschmais/jqa-release-tool/blob/master/core/src/main/resources/xsl/update-version-property.xsl
>
> The Versions plugin does it via Stax.
>
> Best,
>
> Oliver
>
> Am 29.11.18 um 17:11 schrieb Marc Rohlfs:
> > 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
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: invoker tests using multiple maven versions

[Matthieu BROUILLARD]

Thank you, I will go for the CI solution for now.

Matthieu

invoker tests using multiple maven versions

[Matthieu BROUILLARD]

Hi all,

I would like to know the best ways to test a plugin against different maven
versions?
Especially is there a way to run maven-invoker-plugin using different maven
versions?

I can think of some scripting for CI and usage of wrapper but I wanted to
know how people do currently.

Thanks.

Matthieu Brouillard

Re: Applying Jenkins build number

[Matthieu BROUILLARD]

Fine that you found your way.
The only issue with the technics relying on injection of some external
value is that they make your build not reproducible.
It might not be an issue if those injections are only for intermediate
builds and that you tag your build at some point in time with real X.Y.Z
version.
By jgitver and purely the git information (tags, commits, branches) your
intermediate buillds can be reproducible even later if you checkout later
on.

On Fri, Nov 23, 2018 at 10:08 PM Jochen Wiedmann 
wrote:

> I believe I came up with a simple solution: My POM now looks like
>
> my.group.id
> ${revision}
> my-artifact-id
> 
> 
> 1.2${build.number}
> 
>
> So, ${build.number} is empty by default, unless in Jenkins, where I
> define it as ".${env.BUILD_NUMBER}".
>
> Jochen
>
> On Thu, Nov 22, 2018 at 12:19 PM Anders Hammar  wrote:
> >
> > Why not just update the pom (but not commit to scm) with a step like
> > mvn versions:set -DnewVersion=$newVersion
> > ?
> >
> > And newVersion you would parse from the pom file and add ${build.number}
> to
> > it.
> >
> > /Anders
> >
> > On Thu, Nov 22, 2018 at 12:14 PM Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > when running Maven outside of Jenkins, I have the version number (for
> > > example) 1.2, which is just fine. However, within Jenkins I'd like
> > > that to be 1.2.${build.number}. Is that possible without overwriting
> > > the version number in the pom with every build? For example, by using
> > > a "jenkins" profile, which overwrites the project version somehow?
> > >
> > > Thanks,
> > >
> > > Jochen
> > >
> > > -
> > > 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: Applying Jenkins build number

[Matthieu BROUILLARD]

You can also use jgitver (https://jgitver.github.io/) that was demoed at
Devoxx this year to compute automatically the project version, even for
each commit.

Using a jgitver configuration of


false
true
true


You can get the versions computed for each commit, for example 1.2.0-1,
1.2.0-2, 1.2.0-3

Matthieu


On Fri, Nov 23, 2018 at 6:54 AM Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 22/11/18 22:24, Francois MAROT wrote:
> > The new way to deal with such situation is described here:
> > https://maven.apache.org/maven-ci-friendly.html
> >
> > 
> >  0-SNAPSHOT
> > 
> >
> > 1.2.${revision}
> >
> > and let Jenkins run Maven like this mvn deploy
> > -Drevision=${env.BUILD_NUMBER} (or maybe just $BUILD_NUMBER depending on
> the
> > way you run Jenkins)
>
> Please add the configuration for flatten-maven-plugin to your
> configuration as described on the mentioned page...
>
> 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: Extension works from lib/ext and CLI but not extensions.xml

[Matthieu BROUILLARD]

Not sure but I think the mechanism extension does not work for SNAPSHOT
versions.
Try to install a non SNAPSHOT version in your local maven repository.
I think I have already faced the same in the past while producing with my
own extension https://github.com/jgitver/jgitver-maven-plugin

Hope it helps.

Matthieu

On Fri, Oct 26, 2018 at 7:39 AM J. Lewis Muir  wrote:

> Hello, all!
>
> I'm trying to use the EL Profile Activation Maven Extension
>
>   https://github.com/kpiwko/el-profile-activator-extension
>
> to activate a profile when the foo_env system property is either not
> set, or set to "development".  I'm using the "help:active-profiles" goal
> of the Maven Help plugin and the "validate" phase to test whether or not
> a profile is active.
>
> The extension works when I install it in
>
>   /lib/ext
>
> and it works when I specify it on the command line with
>
>   -Dmaven.ext.class.path=
>
> but it does *not* work when I put it in the project's
>
>   .mvn/extensions.xml
>
> Does anyone know why?!
>
> This is Maven 3.5.4, the latest Git snapshot of EL Profile Activation
> Maven Extension, and MVEL 2.4.2.Final.
>
> The el-profile-activator-extension artifact is not published in the
> Central Repository, but I installed it into my local repository (i.e.,
> ~/.m2/repository) with
>
>   git clone https://github.com/kpiwko/el-profile-activator-extension.git
>   cd el-profile-activator-extension
>   : JAVA_HOME has been set to a Java 8 SDK to compile
>   mvn install
>
> That should be fine, right?  My local repository will be searched first
> for any artifacts listed in extensions.xml, and I don't get a warning
> nor error about it not being found, so my understanding is that this is
> OK.
>
> For the case where the extension does not work, I have a test-01 project
> directory containing the following pom.xml file
>
>   
>   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
> org.example.foo
> foo
> 1.0.0
> pom
> 
>   
> foo_env-development
> 
>   
> mvel
> (!isdef foo_env) || (isdef foo_env  foo_env
> == "development")
>   
> 
>   
> 
>   
>
> and the following .mvn/extensions.xml file
>
>   http://maven.apache.org/EXTENSIONS/1.0.0;
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
>   http://maven.apache.org/xsd/core-extensions-1.0.0.xsd;>
> 
>   com.redhat.jboss.maven
>   el-profile-activator-extension
>   1.0.0-SNAPSHOT
> 
>   
>
> I invoke Maven like this
>
>   mvn help:active-profiles validate
>
> and it shows that the foo_env-development profile is not active (i.e.,
> it lists no active profiles)
>
>   The following profiles are active:
>
> but it should be!
>
> A transcript of this and with the "-X" option is attached as
>
>   test-01-extensions-dot-xml.txt
>
> Removing the .mvn directory and adding
>
>   el-profile-activator-extension-1.0.0-SNAPSHOT.jar
>
> and
>
>   mvel2-2.4.2.Final.jar
>
> to
>
>   /lib/ext
>
> works; i.e., it shows that the foo_env-development profile is active
>
>   The following profiles are active:
>
>- foo_env-development (source: org.example.foo:foo:1.0.0)
>
> A transcript of this and with the "-X" option is attached as
>
>   test-01-maven-home-lib-ext.txt
>
> Removing those JARs from
>
>   /lib/ext
>
> and instead specifying them on the command line by setting the
>
>   maven.ext.class.path
>
> system property works; i.e., it shows that the foo_env-development
> profile is active
>
>   The following profiles are active:
>
>- foo_env-development (source: org.example.foo:foo:1.0.0)
>
> A transcript of this and with the "-X" option is attached as
>
>   test-01-maven-ext-class-path.txt
>
> Any help getting the extensions.xml case to work would be greatly
> appreciated!  Thank you!
>
> Lewis
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org

Re: Using POJO Tests: setUp() and tearDown() methods

[Matthieu BROUILLARD]

I wasn't even aware that surefire had such a functionnality. I even do not
understand why it does.
If you want to do unit tests I would suggest you to use a real unit test
framework like junit, testng, ...
IMHO surefire should just be an orcherstrator and should not provide
functionnalities to replace a unit test framework.

Unfortunately it does not help you that much on this POJO test topic.

Matthieu


On Fri, Sep 28, 2018 at 6:04 AM Bruce Alspaugh 
wrote:

> I was using Surefire's ability to run POJO tests as described here:
>
>
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/pojo-test.html
>
> I noticed my setUp() and tearDown() methods were not being called.
> However, when I make those methods static they are called. I didn't see
> a requirement that the methods have to be static in the documentation.
> Is that a bug in the software or the documentation?
>
> Bruce
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Announcing OSSIndex plugins for Apache Maven: Scan your dependencies for known vulnerabilities

[Matthieu BROUILLARD]

Excellent enhancement ; thank you Brian & Sonatype.

>  Report issues or ideas here:
> https://github.com/sonatype/ossindex-maven/issues

As requested I submitted my feedback as an RFE (
https://github.com/sonatype/ossindex-maven/issues/10) to report possible
fixes on the vulnerabilities.

Regards,
Matthieu

On Thu, Jul 26, 2018 at 2:55 AM Brian Fox  wrote:

> You probably know Sonatype for our work in the Maven community, Nexus
> Repository Manager, and for hosting Central. You may not know that for
> the last 7 years we've also been leading the way in solutions that
> allow developers to innovate faster and be able to improve security,
> license compliance and architecture at the same time.
>
> For years the primary domain for these concerns have been large
> enterprises and/or governance teams. We're seeing a new trend along
> with the #devsecops movement that brings concerns like the security
> posture of a 3rd party component into the forefront of concerns for
> developers. To further empower that trend, we've updated and
> relaunched OSS Index with the mission to provide information and APIs
> to the community -for free- to use in raising the security bar for
> everyone.
>
> Out of the box you can find a plugin to assess and optionally fail
> your build if components contain known vulnerabilities. If you're a
> fan of the Maven Enforcer Plugin, there's a rule for you too. I
> encourage you to check it out and if you're so inclined, grab the REST
> API and integrate it into your favorite tool.
>
> https://ossindex.sonatype.org
>
> Find the Maven Plugin docs here:
> https://sonatype.github.io/ossindex-maven/maven-plugin/
>
> Find the Enforcer Plugin usage here:
> https://sonatype.github.io/ossindex-maven/enforcer-rules/
>
> Report issues or ideas here:
> https://github.com/sonatype/ossindex-maven/issues
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Distribution management

[Matthieu BROUILLARD]

Hi Adam,

'distributionManagement' is part of the pom not part of settings : maven is
like that.

If you do not want to expose some company repositories or if those ones are
often changing then you can:
- either use placeholders in some predefined `distributionManagement` tags
(in project or in parent)
- use `altDeploymentRepository` of maven deploy plugin
- write a maven core extension that updates dynamically & in memory the POM
of your projects

Matthieu


On Tue, Jul 10, 2018 at 11:09 AM ahardy42 
wrote:

> Hi maven-users,
>
> it seems this issue was last discussed almost 10 years ago but despite
> reading the docs and the email lists there is still an issue with
> distribution management that I don't understand.
>
> I do not wish to declare our company's internal release and snapshot
> repositories in pom files which are versioned, and I can't put the xml in
> the settings.xml.
>
> I only see two alternatives:
>
>  - I declare the distributionManagement xml for my team in a parent pom
> which I deploy on an updateable repository where we do not have to
> increment
> the version
>
>  - I provide everybody with the command line script snippet to do the
> deploy
> manually
>
> Both of these alternatives have drawbacks.
>
> If there is another way of keeping the distributionManagement out of the
> versioned poms?
>
> If not, why don't I understand the paradigm? It makes little sense to me
> that a change in the environment (the repository URLs) should force a
> version change in all projects under development.
>
> Regards
> Adam
>
>
>
> --
> Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Re: Release a snapshot version

[Matthieu BROUILLARD]

Moreover if you are using git and want just to do `git tag && mvn deploy`
then you can have a look at https://github.com/jgitver/jgitver-maven-plugin
to understand how jgitver maven core extension can compute your project
version automatically without never modifying your pom.xml.
If you want to avoid unnecessary commits coming from the update of the pom
version then it is worth looking at it.

When it is activated you can work like below:

$ mvn validate
   ... myproject-1.0.0-SNAPSHOT
$ git tag -m "june release" 1.0
$ mvn deploy
   ... myproject-1.0.0  <-- version computed from tag without any
pom modfication
$ git add . && git commit -m "new feature blabla"
$ mvn validate
   ... myproject-1.0.1-SNAPSHOT  <-- version automatically followed
maven conventions again without any pom modfication
$ git branch featureX
$ mvn validate
   ... myproject-1.0.1-featureX-SNAPSHOT  <-- avoids automatically
version collision in branch still without any pom modfication

This way you never have to pollute your git history with commits containing
only pom version changes ; this also avoids a lot of merge problems because
there is no more unnecessary pom modifications.

-
Matthieu Brouillard




On Thu, Jun 28, 2018 at 6:23 AM Ravindranatha Panikar, Renjith <
rr...@allstate.com> wrote:

> Thanks Thomas, that did the job.
>
> regards,
>
>
> -Original Message-
> From: Thomas Broyer [mailto:t.bro...@gmail.com]
> Sent: Thursday, June 28, 2018 1:47 AM
> To: Maven Users List 
> Subject: [External] Re: Release a snapshot version
>
> It looks like you just want to deploy your snapshot to a repository; in
> that case you'll want to simply "mvn deploy", without even using the
> maven-release-plugin (for the reasons Karl Heinz gave)
>
> Le mer. 27 juin 2018 18:30, Ravindranatha Panikar, Renjith <
> rr...@allstate.com> a écrit :
>
> > I am planning to use maven release plugin for automating the release
> > of our application.
> > There can be two types of releases.
> >
> >Normal Release:
> >  Current code should be
> tagged.
> >  Pom.xml should get
> > updated to 'next-version-SNAPSHOT'.
> >  Artifacts should be
> > public to remote repository.
> >
> >SNAPSHOT Release: it can contain one or more hot fixes
> > which we would like to release on an immediate basis.
> >  Tagging is not
> > required here.
> >   Pom.xml should
> > not be updated.
> >  Artifacts should
> > be published to remote repository with name 'ProjectName-
> > next-version-SNAPSHOT'.jar'
> >
> > I know maven-release-plugin can perform the 'Normal Release'. But is
> > there any way I can handle the 'SNAPSHOT release'?
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: where to specify pluginRepositories for a custom maven core extension

[Matthieu BROUILLARD]

Hi Nicolas,

If you want perhaps you can also contribute to
https://github.com/jgitver/jgitver-maven-plugin which computes project
version automatically for maven (there is also a gradle project).

Concerning your question, I never had such a problem. My core extensions
are downloaded from the repositories I push them to (in my case central).

Regards,

Matthieu Brouillard

On Wed, Jun 27, 2018 at 10:59 AM Nicolas Brasey 
wrote:

> Hi,
>
> I developed a maven core extension which controls the project version and
> the distribution managment repository depending on the git branch before
> the build starts.
>
> I specify the coordinates of my extension by providing a file which is
> located in the project git repo, inside .mvn/extension.xml, as described
> here:
>
> https://maven.apache.org/docs/3.3.1/release-notes.html
>
> My problem is that Maven is not able to download this artifacts from a
> remote repository. I would like that it is getting fetched from my private
> maven repo.
>
> So the question is, where can I specify my private repository which
> contains this extension ? Ideally, it should be inside my git repo (in .mvn
> directory)
>
> Thanks
> Nicolas
>

Matthieu Brouillard est absent(e).

[matthieu . brouillard]

Je serai absent(e) du  20/07/2009 au 10/08/2009.

Je répondrai à votre message dès mon retour.

I am actually out of office.
I will answer you once I am back.

Matthieu Brouillard est absent(e).

[matthieu . brouillard]

Je serai absent(e) du  20/02/2009 au 22/02/2009.

Je répondrai à votre message dès mon retour.

I am actually out of office.
I will answer you once I am back.