Releasing a subset of the Reactor

[Andres Almiray]

Hello everyone,

Does anyone know if it's possible to release justa  subset of the Reactor
when using the maven-release-plugin?

The Layrry build includes a set of modules (examples and integration tests)
that should not be part of the release. And added hurdle is that there are
"duplicate" modules, that is same groupId:artifactId but different version
for a couple of modules (I know, weird) which are needed to test Layrry's
capabilities to deal with conflicting module versions.

As it stands right now the release plugin attempts to release the whole
Reactor and croaks when it finds duplicate modules.

I haven't found a *.skip property like other plugins have.

TIA.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.

Re: exclusive execution scheduling

[Tommy Svensson]

I would say this is a windows problem rather than a maven problem. I have had 
similar problems trying to build simpler things where only solution is to reboot
windows to unlock NTFS (NoT a File System). 

I'm very seriously considering getting VMWare and installing a Linux Mint 20 
and 
work in Linux instead. It seems like the only serious way to develop Java on a
Windows 10 machine. Working on Windows directly costs to much time in 
constant reboots to resolve locks. 

I'm having a very good 4K display, which the free virtualbox does not support
full size, thereby VmWare for me. If you don't have my display requirement, test
with VirtualBox.  

Do note however that a virtual machine takes more memory!  Personally I have
32 GB memory in my machine, but if you are at 16 GB or lower it can be 
problematic. 

And no, this wasn't exactly what you were asking. But since I'm having NTFS
locks commonly even without multi threaded builds I don't believe the problem
lies in maven. 

I have to admit that Windows 10 is far better than previous windows 
versions. It however seem to still be using same old, NTFS. 

Cheers,
Tommy 


Från: Delany 
Svara: Maven Users List 
Datum: 4 februari 2021 at 19:01:18
Till: Maven Users List 
Ämne:  exclusive execution scheduling  

We use the exec-maven-plugin (a thread-safe plugin) to call msbuild for  
dotnet builds within Maven.  
We have 8 dotnet projects with 3 of them depending on shared libraries in  
another directory in the repo (a total of 500 projects).  

With multi-threading on (4 threads), these dotnet projects always fail  
because the msbuild instances are all trying to lock the files in the  
shared libraries and can't open them in the other instances. This is on  
Windows 10 with NTFS. With only one thread, they always build successfully.  

Note that I don't use the multi-threading capabilities of msbuild because  
that would be silly.  

To get this reactor working I can either  

- package up the shared libraries as part of the build, and unpack them  
into every dotnet project that needs them (using  
https://maven.apache.org/plugins/maven-remote-resources-plugin/ )  

Or ensure that no 2 instances of msbuild ever run at the same time, by  
either  

- chaining the dotnet projects together as one sequence of dependent  
projects (ridiculous)  
- building the dotnet projects separately with their own maven invocation  
- turning off multi-threading for the whole reactor  

Are there other options?  

Would it be feasible to consider adding a further thread-safe check in the  
plugin architecture whereby a configuration could be set to enforce that no  
two executions with the same id will ever run simultaneously?  

Thanks,  
Delany  

Re: Releasing a subset of the Reactor

[Maarten Mulders]

Hi Andres,

If its just about deploying the modules to a remote repo, you could set 
the skip property of the maven-deploy-plugin. I've applied that trick in 
a Maven plug-in I've made [1]; their integration tests don't need to be 
in Central, but all other modules should. In this scenario, the 
integration tests are versioned (tagged in Git) together with the actual 
code, but they don't get uploaded.


HTH,

Maarten


[1] https://github.com/mthmulders/puml-maven-plugin

On 05/02/2021 13:06, Andres Almiray wrote:

Hello everyone,

Does anyone know if it's possible to release justa  subset of the Reactor
when using the maven-release-plugin?

The Layrry build includes a set of modules (examples and integration tests)
that should not be part of the release. And added hurdle is that there are
"duplicate" modules, that is same groupId:artifactId but different version
for a couple of modules (I know, weird) which are needed to test Layrry's
capabilities to deal with conflicting module versions.

As it stands right now the release plugin attempts to release the whole
Reactor and croaks when it finds duplicate modules.

I haven't found a *.skip property like other plugins have.

TIA.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.



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

Re: Releasing a subset of the Reactor

[Andres Almiray]

Hi Maarten,

Yup, this is a matter of fact an attempt to configure the Layrry build to 
publish its artifacts to Maven Central and make it happen with a single release 
commit. 

I’ve got the deploy plugin configured in such a way they it will skip tests and 
examples. That works. However the release plugin complains about duplicate 
reactor modules (rightly so). I know I can change versions and tag manually but 
I’d rather have it automated hence the use of the release plugin. 

Perhaps there’s a different way to do this? What I need is:
- given a subset of the Reactor:
  - attach sources and javadoc jars (done)
  - sign artifacts (done)
  - publish to Maven Central
 - deploy plugin?
 - release plugin?
  - automatic promotion from staging to production at MC. 

Any tips to make this happen would be greatly appreciated. 

Thanks!

Sent from my primitive tricorder

> On 5 Feb 2021, at 13:17, Maarten Mulders  wrote:
> 
> Hi Andres,
> 
> If its just about deploying the modules to a remote repo, you could set the 
> skip property of the maven-deploy-plugin. I've applied that trick in a Maven 
> plug-in I've made [1]; their integration tests don't need to be in Central, 
> but all other modules should. In this scenario, the integration tests are 
> versioned (tagged in Git) together with the actual code, but they don't get 
> uploaded.
> 
> HTH,
> 
> Maarten
> 
> 
> [1] https://github.com/mthmulders/puml-maven-plugin
> 
>> On 05/02/2021 13:06, Andres Almiray wrote:
>> Hello everyone,
>> Does anyone know if it's possible to release justa  subset of the Reactor
>> when using the maven-release-plugin?
>> The Layrry build includes a set of modules (examples and integration tests)
>> that should not be part of the release. And added hurdle is that there are
>> "duplicate" modules, that is same groupId:artifactId but different version
>> for a couple of modules (I know, weird) which are needed to test Layrry's
>> capabilities to deal with conflicting module versions.
>> As it stands right now the release plugin attempts to release the whole
>> Reactor and croaks when it finds duplicate modules.
>> I haven't found a *.skip property like other plugins have.
>> TIA.
>> Cheers,
>> Andres
>> ---
>> Java Champion; Groovy Enthusiast
>> http://andresalmiray.com
>> http://www.linkedin.com/in/aalmiray
>> --
>> What goes up, must come down. Ask any system administrator.
>> There are 10 types of people in the world: Those who understand binary, and
>> those who don't.
>> To understand recursion, we must first understand recursion.
> 
> -
> 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

Resolve root directory in a multi-project build

[Andres Almiray]

Hello everyone,

Is there a way to reliably resolve the value of the root directory for a
given multi-project build?
Unfortunately ${session.executionRootDirectory} does not seem to work for
all cases, it might work when used inside a plugin's 
section but does not when used outside of plugins

TIA

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.

Re: exclusive execution scheduling

[Delany]

I completely get what you're saying, in fact it hasn't been 48hrs since
I've had to reboot an NTFS machine to unlock a file.
But here the problem as it manifests is with msbuild itself (if you're
interested https://github.com/dotnet/sdk/issues/9585)

That might be where we leave it. But I think something else can be done,
and without much effort. The exec-maven-plugin claims to be thread-safe -
whatever that means (internally thread-safe?) But if it's going to call
some ad-hoc binary, it's an empty claim.

Making a simple configuration available to the model could simply and
easily prevent this situation, i.e. maintain a list of active executions in
the session, and delay the start of an execution if it was configured to
run exclusively. Does anyone else think it's worth a ticket?

Thanks,
Delany

On Fri, 5 Feb 2021 at 12:56, Tommy Svensson  wrote:

> I would say this is a windows problem rather than a maven problem. I have
> had
> similar problems trying to build simpler things where only solution is to
> reboot
> windows to unlock NTFS (NoT a File System).
>
> I'm very seriously considering getting VMWare and installing a Linux Mint
> 20 and
> work in Linux instead. It seems like the only serious way to develop Java
> on a
> Windows 10 machine. Working on Windows directly costs to much time in
> constant reboots to resolve locks.
>
> I'm having a very good 4K display, which the free virtualbox does not
> support
> full size, thereby VmWare for me. If you don't have my display
> requirement, test
> with VirtualBox.
>
> Do note however that a virtual machine takes more memory!  Personally I
> have
> 32 GB memory in my machine, but if you are at 16 GB or lower it can be
> problematic.
>
> And no, this wasn't exactly what you were asking. But since I'm having NTFS
> locks commonly even without multi threaded builds I don't believe the
> problem
> lies in maven.
>
> I have to admit that Windows 10 is far better than previous windows
> versions. It however seem to still be using same old, NTFS.
>
> Cheers,
> Tommy
>
>
> Från: Delany  
> Svara: Maven Users List  
> Datum: 4 februari 2021 at 19:01:18
> Till: Maven Users List  
> Ämne:  exclusive execution scheduling
>
> We use the exec-maven-plugin (a thread-safe plugin) to call msbuild for
> dotnet builds within Maven.
> We have 8 dotnet projects with 3 of them depending on shared libraries in
> another directory in the repo (a total of 500 projects).
>
> With multi-threading on (4 threads), these dotnet projects always fail
> because the msbuild instances are all trying to lock the files in the
> shared libraries and can't open them in the other instances. This is on
> Windows 10 with NTFS. With only one thread, they always build
> successfully.
>
> Note that I don't use the multi-threading capabilities of msbuild because
> that would be silly.
>
> To get this reactor working I can either
>
> - package up the shared libraries as part of the build, and unpack them
> into every dotnet project that needs them (using
> https://maven.apache.org/plugins/maven-remote-resources-plugin/ )
>
> Or ensure that no 2 instances of msbuild ever run at the same time, by
> either
>
> - chaining the dotnet projects together as one sequence of dependent
> projects (ridiculous)
> - building the dotnet projects separately with their own maven invocation
> - turning off multi-threading for the whole reactor
>
> Are there other options?
>
> Would it be feasible to consider adding a further thread-safe check in the
> plugin architecture whereby a configuration could be set to enforce that
> no
> two executions with the same id will ever run simultaneously?
>
> Thanks,
> Delany
>
>

Re: exclusive execution scheduling

[Lasse Lindqvist]

Hi. It should already be possible for you to build a dependency graph or
execution order the way you need for multi-threaded builds.
Example: A and B are required executions for C and D can then be executed
after all, A, B and C. So just package every execution into a separate
Maven submodule and declare dependecies from D to C and from C to A and B.
In this case A and B might be executed at the same time, but C waits for A
and B and D waits for C.

pe 5. helmik. 2021 klo 19.18 Delany (delany.middle...@gmail.com) kirjoitti:

> I completely get what you're saying, in fact it hasn't been 48hrs since
> I've had to reboot an NTFS machine to unlock a file.
> But here the problem as it manifests is with msbuild itself (if you're
> interested https://github.com/dotnet/sdk/issues/9585)
>
> That might be where we leave it. But I think something else can be done,
> and without much effort. The exec-maven-plugin claims to be thread-safe -
> whatever that means (internally thread-safe?) But if it's going to call
> some ad-hoc binary, it's an empty claim.
>
> Making a simple configuration available to the model could simply and
> easily prevent this situation, i.e. maintain a list of active executions in
> the session, and delay the start of an execution if it was configured to
> run exclusively. Does anyone else think it's worth a ticket?
>
> Thanks,
> Delany
>
> On Fri, 5 Feb 2021 at 12:56, Tommy Svensson  wrote:
>
> > I would say this is a windows problem rather than a maven problem. I have
> > had
> > similar problems trying to build simpler things where only solution is to
> > reboot
> > windows to unlock NTFS (NoT a File System).
> >
> > I'm very seriously considering getting VMWare and installing a Linux Mint
> > 20 and
> > work in Linux instead. It seems like the only serious way to develop Java
> > on a
> > Windows 10 machine. Working on Windows directly costs to much time in
> > constant reboots to resolve locks.
> >
> > I'm having a very good 4K display, which the free virtualbox does not
> > support
> > full size, thereby VmWare for me. If you don't have my display
> > requirement, test
> > with VirtualBox.
> >
> > Do note however that a virtual machine takes more memory!  Personally I
> > have
> > 32 GB memory in my machine, but if you are at 16 GB or lower it can be
> > problematic.
> >
> > And no, this wasn't exactly what you were asking. But since I'm having
> NTFS
> > locks commonly even without multi threaded builds I don't believe the
> > problem
> > lies in maven.
> >
> > I have to admit that Windows 10 is far better than previous windows
> > versions. It however seem to still be using same old, NTFS.
> >
> > Cheers,
> > Tommy
> >
> >
> > Från: Delany  
> > Svara: Maven Users List   >
> > Datum: 4 februari 2021 at 19:01:18
> > Till: Maven Users List  
> > Ämne:  exclusive execution scheduling
> >
> > We use the exec-maven-plugin (a thread-safe plugin) to call msbuild for
> > dotnet builds within Maven.
> > We have 8 dotnet projects with 3 of them depending on shared libraries in
> > another directory in the repo (a total of 500 projects).
> >
> > With multi-threading on (4 threads), these dotnet projects always fail
> > because the msbuild instances are all trying to lock the files in the
> > shared libraries and can't open them in the other instances. This is on
> > Windows 10 with NTFS. With only one thread, they always build
> > successfully.
> >
> > Note that I don't use the multi-threading capabilities of msbuild because
> > that would be silly.
> >
> > To get this reactor working I can either
> >
> > - package up the shared libraries as part of the build, and unpack them
> > into every dotnet project that needs them (using
> > https://maven.apache.org/plugins/maven-remote-resources-plugin/ )
> >
> > Or ensure that no 2 instances of msbuild ever run at the same time, by
> > either
> >
> > - chaining the dotnet projects together as one sequence of dependent
> > projects (ridiculous)
> > - building the dotnet projects separately with their own maven invocation
> > - turning off multi-threading for the whole reactor
> >
> > Are there other options?
> >
> > Would it be feasible to consider adding a further thread-safe check in
> the
> > plugin architecture whereby a configuration could be set to enforce that
> > no
> > two executions with the same id will ever run simultaneously?
> >
> > Thanks,
> > Delany
> >
> >
>

Re: Resolve root directory in a multi-project build

[Lasse Lindqvist]

Using directory-maven-plugin and highest-basedir goal from it has worked
just fine for me.
https://github.com/jdcasey/directory-maven-plugin#highest-basedir-goal

pe 5. helmik. 2021 klo 18.53 Tamás Cservenák (ta...@cservenak.net)
kirjoitti:

> Howdy,
> Grab somehow (you did not state from where if "outside of plugins")
> MavenSession, it has getExecutionRootDirectory method, BUT it may not be
> what you want, as one may use -f param for example...
>
> So, I'd shoot back: WHY do you need the root of a multi module build and
> FROM WHAT you need it? Extension?
> Are you sure you can expect maven is invoked from root? Could it be simpler
> just to pass in as some parameter maybe, instead of doing all sorts of
> hoops and loops?
>
> T
>
> On Fri, Feb 5, 2021 at 5:04 PM Andres Almiray  wrote:
>
> > Hello everyone,
> >
> > Is there a way to reliably resolve the value of the root directory for a
> > given multi-project build?
> > Unfortunately ${session.executionRootDirectory} does not seem to work for
> > all cases, it might work when used inside a plugin's 
> > section but does not when used outside of plugins
> >
> > TIA
> >
> > Cheers,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
>

Re: Resolve root directory in a multi-project build

[Andres Almiray]

@Tamás: Right, should had explained the use case. I want to deploy all
artifacts to a local directory so that I can inspect everything which will
be deployed given certain conditions.
I managed to do that by forcing a stable, absolute directory as shown at

https://github.com/moditect/layrry/pull/90/commits/93472049fee1b5ffa579929211aac20bef3f5e00

I'd prefer if the target directory be ${rootProject.build.directory} if
there were such things as {$rootProject}, which is why I'm asking for a way
to find out that value.
As you may appreciate in that commit the value is used as part of
 in a profile.

@Lasse: I thought using that plugin would work but not in my case as the
computed property is not available during model interpolation which is my
case for setting the correct value in 

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Fri, Feb 5, 2021 at 6:32 PM Lasse Lindqvist 
wrote:

> Using directory-maven-plugin and highest-basedir goal from it has worked
> just fine for me.
> https://github.com/jdcasey/directory-maven-plugin#highest-basedir-goal
>
> pe 5. helmik. 2021 klo 18.53 Tamás Cservenák (ta...@cservenak.net)
> kirjoitti:
>
> > Howdy,
> > Grab somehow (you did not state from where if "outside of plugins")
> > MavenSession, it has getExecutionRootDirectory method, BUT it may not be
> > what you want, as one may use -f param for example...
> >
> > So, I'd shoot back: WHY do you need the root of a multi module build and
> > FROM WHAT you need it? Extension?
> > Are you sure you can expect maven is invoked from root? Could it be
> simpler
> > just to pass in as some parameter maybe, instead of doing all sorts of
> > hoops and loops?
> >
> > T
> >
> > On Fri, Feb 5, 2021 at 5:04 PM Andres Almiray 
> wrote:
> >
> > > Hello everyone,
> > >
> > > Is there a way to reliably resolve the value of the root directory for
> a
> > > given multi-project build?
> > > Unfortunately ${session.executionRootDirectory} does not seem to work
> for
> > > all cases, it might work when used inside a plugin's 
> > > section but does not when used outside of plugins
> > >
> > > TIA
> > >
> > > Cheers,
> > > Andres
> > >
> > > ---
> > > Java Champion; Groovy Enthusiast
> > > http://andresalmiray.com
> > > http://www.linkedin.com/in/aalmiray
> > > --
> > > What goes up, must come down. Ask any system administrator.
> > > There are 10 types of people in the world: Those who understand binary,
> > and
> > > those who don't.
> > > To understand recursion, we must first understand recursion.
> > >
> >
>

Re: Resolve root directory in a multi-project build

[Tamás Cservenák]

Howdy,
Grab somehow (you did not state from where if "outside of plugins")
MavenSession, it has getExecutionRootDirectory method, BUT it may not be
what you want, as one may use -f param for example...

So, I'd shoot back: WHY do you need the root of a multi module build and
FROM WHAT you need it? Extension?
Are you sure you can expect maven is invoked from root? Could it be simpler
just to pass in as some parameter maybe, instead of doing all sorts of
hoops and loops?

T

On Fri, Feb 5, 2021 at 5:04 PM Andres Almiray  wrote:

> Hello everyone,
>
> Is there a way to reliably resolve the value of the root directory for a
> given multi-project build?
> Unfortunately ${session.executionRootDirectory} does not seem to work for
> all cases, it might work when used inside a plugin's 
> section but does not when used outside of plugins
>
> TIA
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>

Re: Resolve root directory in a multi-project build

[Tamás Cservenák]

Unsure will it help, but your description reminded me of nexus-staging
plugin, there we similarly "deploy locally" (defer actual deploy) to fire
the deployables at the project end:
https://github.com/sonatype/nexus-maven-plugins/blob/master/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/deploy/strategy/DeferredDeployStrategy.java

Is quite messy plugin :)

For example as "location" for the files we use "first module that has THIS
plugin defined" as it is "stable" enough (and we do not quite care where
the files are accumulated):
https://github.com/sonatype/nexus-maven-plugins/blob/master/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/AbstractStagingMojo.java#L423

Hope this helps
T

On Fri, Feb 5, 2021 at 6:52 PM Andres Almiray  wrote:

> @Tamás: Right, should had explained the use case. I want to deploy all
> artifacts to a local directory so that I can inspect everything which will
> be deployed given certain conditions.
> I managed to do that by forcing a stable, absolute directory as shown at
>
>
> https://github.com/moditect/layrry/pull/90/commits/93472049fee1b5ffa579929211aac20bef3f5e00
>
> I'd prefer if the target directory be ${rootProject.build.directory} if
> there were such things as {$rootProject}, which is why I'm asking for a way
> to find out that value.
> As you may appreciate in that commit the value is used as part of
>  in a profile.
>
> @Lasse: I thought using that plugin would work but not in my case as the
> computed property is not available during model interpolation which is my
> case for setting the correct value in 
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Fri, Feb 5, 2021 at 6:32 PM Lasse Lindqvist <
> lasse.k.lindqv...@gmail.com>
> wrote:
>
> > Using directory-maven-plugin and highest-basedir goal from it has worked
> > just fine for me.
> > https://github.com/jdcasey/directory-maven-plugin#highest-basedir-goal
> >
> > pe 5. helmik. 2021 klo 18.53 Tamás Cservenák (ta...@cservenak.net)
> > kirjoitti:
> >
> > > Howdy,
> > > Grab somehow (you did not state from where if "outside of plugins")
> > > MavenSession, it has getExecutionRootDirectory method, BUT it may not
> be
> > > what you want, as one may use -f param for example...
> > >
> > > So, I'd shoot back: WHY do you need the root of a multi module build
> and
> > > FROM WHAT you need it? Extension?
> > > Are you sure you can expect maven is invoked from root? Could it be
> > simpler
> > > just to pass in as some parameter maybe, instead of doing all sorts of
> > > hoops and loops?
> > >
> > > T
> > >
> > > On Fri, Feb 5, 2021 at 5:04 PM Andres Almiray 
> > wrote:
> > >
> > > > Hello everyone,
> > > >
> > > > Is there a way to reliably resolve the value of the root directory
> for
> > a
> > > > given multi-project build?
> > > > Unfortunately ${session.executionRootDirectory} does not seem to work
> > for
> > > > all cases, it might work when used inside a plugin's 
> > > > section but does not when used outside of plugins
> > > >
> > > > TIA
> > > >
> > > > Cheers,
> > > > Andres
> > > >
> > > > ---
> > > > Java Champion; Groovy Enthusiast
> > > > http://andresalmiray.com
> > > > http://www.linkedin.com/in/aalmiray
> > > > --
> > > > What goes up, must come down. Ask any system administrator.
> > > > There are 10 types of people in the world: Those who understand
> binary,
> > > and
> > > > those who don't.
> > > > To understand recursion, we must first understand recursion.
> > > >
> > >
> >
>

Re: Releasing a subset of the Reactor

[Andres Almiray]

@Thomas: I think you just solved my problem. I had to check if profiles let
you modify  and they do!

There's one issue left though, if tests and demos are left out of the
release then their versions won't be updated, which means their POMs will
have to be updated after a release.
I guess I can live with that given the peculiarities of the Layrry build.

I'll give profiles a try.

Thanks!

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Fri, Feb 5, 2021 at 8:27 PM Thomas Broyer  wrote:

> How about (in addition to disabling the deploy plugin, just in case)
> putting those submodules into a profile, enabled by default, but disabled
> during release? (e.g. through a "-P !tests" or "-Dit-tests=false" in
>  and the appropriate activation for the profile)
>
> On Fri, Feb 5, 2021 at 2:16 PM Andres Almiray  wrote:
>
> > Hi Maarten,
> >
> > Yup, this is a matter of fact an attempt to configure the Layrry build to
> > publish its artifacts to Maven Central and make it happen with a single
> > release commit.
> >
> > I’ve got the deploy plugin configured in such a way they it will skip
> > tests and examples. That works. However the release plugin complains
> about
> > duplicate reactor modules (rightly so). I know I can change versions and
> > tag manually but I’d rather have it automated hence the use of the
> release
> > plugin.
> >
> > Perhaps there’s a different way to do this? What I need is:
> > - given a subset of the Reactor:
> >   - attach sources and javadoc jars (done)
> >   - sign artifacts (done)
> >   - publish to Maven Central
> >  - deploy plugin?
> >  - release plugin?
> >   - automatic promotion from staging to production at MC.
> >
> > Any tips to make this happen would be greatly appreciated.
> >
> > Thanks!
> >
> > Sent from my primitive tricorder
> >
> > > On 5 Feb 2021, at 13:17, Maarten Mulders 
> wrote:
> > >
> > > Hi Andres,
> > >
> > > If its just about deploying the modules to a remote repo, you could set
> > the skip property of the maven-deploy-plugin. I've applied that trick in
> a
> > Maven plug-in I've made [1]; their integration tests don't need to be in
> > Central, but all other modules should. In this scenario, the integration
> > tests are versioned (tagged in Git) together with the actual code, but
> they
> > don't get uploaded.
> > >
> > > HTH,
> > >
> > > Maarten
> > >
> > >
> > > [1] https://github.com/mthmulders/puml-maven-plugin
> > >
> > >> On 05/02/2021 13:06, Andres Almiray wrote:
> > >> Hello everyone,
> > >> Does anyone know if it's possible to release justa  subset of the
> > Reactor
> > >> when using the maven-release-plugin?
> > >> The Layrry build includes a set of modules (examples and integration
> > tests)
> > >> that should not be part of the release. And added hurdle is that there
> > are
> > >> "duplicate" modules, that is same groupId:artifactId but different
> > version
> > >> for a couple of modules (I know, weird) which are needed to test
> > Layrry's
> > >> capabilities to deal with conflicting module versions.
> > >> As it stands right now the release plugin attempts to release the
> whole
> > >> Reactor and croaks when it finds duplicate modules.
> > >> I haven't found a *.skip property like other plugins have.
> > >> TIA.
> > >> Cheers,
> > >> Andres
> > >> ---
> > >> Java Champion; Groovy Enthusiast
> > >> http://andresalmiray.com
> > >> http://www.linkedin.com/in/aalmiray
> > >> --
> > >> What goes up, must come down. Ask any system administrator.
> > >> There are 10 types of people in the world: Those who understand
> binary,
> > and
> > >> those who don't.
> > >> To understand recursion, we must first understand recursion.
> > >
> > > -
> > > 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
> >
> >
>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/  <
> http://xn--nna.ma.xn--bwa-xxb.je/>
>

Re: Resolve root directory in a multi-project build

[Falko Modler]

I've been using maven.multiModuleProjectDirectory in various projects
(and have also seen it in others).
You'll need a .mvn directory in your root directory to make it work.

PS: I know that there has been some controvery about this property but
well, it works! ;-)

Cheers,
Falko

Am 05.02.2021 um 17:03 schrieb Andres Almiray:

Hello everyone,

Is there a way to reliably resolve the value of the root directory for a
given multi-project build?
Unfortunately ${session.executionRootDirectory} does not seem to work for
all cases, it might work when used inside a plugin's 
section but does not when used outside of plugins

TIA

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.




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

Re: Resolve root directory in a multi-project build

[Delany]

Maybe for you Falko, but not my Jenkins server with Maven 3.6.3, or these
other users
https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
Delany


On Fri, 5 Feb 2021, 22:25 Falko Modler,  wrote:

> I've been using maven.multiModuleProjectDirectory in various projects
> (and have also seen it in others).
> You'll need a .mvn directory in your root directory to make it work.
>
> PS: I know that there has been some controvery about this property but
> well, it works! ;-)
>
> Cheers,
> Falko
>
> Am 05.02.2021 um 17:03 schrieb Andres Almiray:
> > Hello everyone,
> >
> > Is there a way to reliably resolve the value of the root directory for a
> > given multi-project build?
> > Unfortunately ${session.executionRootDirectory} does not seem to work for
> > all cases, it might work when used inside a plugin's 
> > section but does not when used outside of plugins
> >
> > TIA
> >
> > Cheers,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Releasing a subset of the Reactor

[Thomas Broyer]

How about (in addition to disabling the deploy plugin, just in case)
putting those submodules into a profile, enabled by default, but disabled
during release? (e.g. through a "-P !tests" or "-Dit-tests=false" in
 and the appropriate activation for the profile)

On Fri, Feb 5, 2021 at 2:16 PM Andres Almiray  wrote:

> Hi Maarten,
>
> Yup, this is a matter of fact an attempt to configure the Layrry build to
> publish its artifacts to Maven Central and make it happen with a single
> release commit.
>
> I’ve got the deploy plugin configured in such a way they it will skip
> tests and examples. That works. However the release plugin complains about
> duplicate reactor modules (rightly so). I know I can change versions and
> tag manually but I’d rather have it automated hence the use of the release
> plugin.
>
> Perhaps there’s a different way to do this? What I need is:
> - given a subset of the Reactor:
>   - attach sources and javadoc jars (done)
>   - sign artifacts (done)
>   - publish to Maven Central
>  - deploy plugin?
>  - release plugin?
>   - automatic promotion from staging to production at MC.
>
> Any tips to make this happen would be greatly appreciated.
>
> Thanks!
>
> Sent from my primitive tricorder
>
> > On 5 Feb 2021, at 13:17, Maarten Mulders  wrote:
> >
> > Hi Andres,
> >
> > If its just about deploying the modules to a remote repo, you could set
> the skip property of the maven-deploy-plugin. I've applied that trick in a
> Maven plug-in I've made [1]; their integration tests don't need to be in
> Central, but all other modules should. In this scenario, the integration
> tests are versioned (tagged in Git) together with the actual code, but they
> don't get uploaded.
> >
> > HTH,
> >
> > Maarten
> >
> >
> > [1] https://github.com/mthmulders/puml-maven-plugin
> >
> >> On 05/02/2021 13:06, Andres Almiray wrote:
> >> Hello everyone,
> >> Does anyone know if it's possible to release justa  subset of the
> Reactor
> >> when using the maven-release-plugin?
> >> The Layrry build includes a set of modules (examples and integration
> tests)
> >> that should not be part of the release. And added hurdle is that there
> are
> >> "duplicate" modules, that is same groupId:artifactId but different
> version
> >> for a couple of modules (I know, weird) which are needed to test
> Layrry's
> >> capabilities to deal with conflicting module versions.
> >> As it stands right now the release plugin attempts to release the whole
> >> Reactor and croaks when it finds duplicate modules.
> >> I haven't found a *.skip property like other plugins have.
> >> TIA.
> >> Cheers,
> >> Andres
> >> ---
> >> Java Champion; Groovy Enthusiast
> >> http://andresalmiray.com
> >> http://www.linkedin.com/in/aalmiray
> >> --
> >> What goes up, must come down. Ask any system administrator.
> >> There are 10 types of people in the world: Those who understand binary,
> and
> >> those who don't.
> >> To understand recursion, we must first understand recursion.
> >
> > -
> > 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
>
>

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ 

Re: Resolve root directory in a multi-project build

[Falko Modler]

For me, no problem on Jenkins either (using "withMaven" pipeline step).
There used to be this issue: https://issues.jenkins.io/browse/JENKINS-35335
Which turned out to be a Maven bug which was fixed in 3.5.0:
https://issues.apache.org/jira/browse/MNG-5889

As far as MNG-5830 is concerned, I don't know what (special) setup the
affected people are using.

I can only say/repeat that you need a .mvn directory to have the
property point to your root directory.
But even without .mvn, there should not be such an error message, so IDK
what's going on in those cases.

Am 05.02.2021 um 22:13 schrieb Delany:

Maybe for you Falko, but not my Jenkins server with Maven 3.6.3, or these
other users
https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
Delany


On Fri, 5 Feb 2021, 22:25 Falko Modler,  wrote:


I've been using maven.multiModuleProjectDirectory in various projects
(and have also seen it in others).
You'll need a .mvn directory in your root directory to make it work.

PS: I know that there has been some controvery about this property but
well, it works! ;-)

Cheers,
Falko

Am 05.02.2021 um 17:03 schrieb Andres Almiray:

Hello everyone,

Is there a way to reliably resolve the value of the root directory for a
given multi-project build?
Unfortunately ${session.executionRootDirectory} does not seem to work for
all cases, it might work when used inside a plugin's 
section but does not when used outside of plugins

TIA

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary,

and

those who don't.
To understand recursion, we must first understand recursion.



-
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: Resolve root directory in a multi-project build

[Alexander Kriegisch]

I had some discussion with Karl Heinz Marbaise about
maven.multiModuleProjectDirectory a while ago (cannot remember where
exactly) and he strongly advised me not to use it as it is for internal
use only. Even so, other tools such as IntelliJ IDEA use it internally,
but not consequently, the situationis a bit messy.

What I ended up doing was to use Build Helper Maven Plugin >= 3.2.0
(because of
https://github.com/mojohaus/build-helper-maven-plugin/issues/48) and
there to use the "rootlocation" goal. I am not sure if that is working
for you here because you said you need it somewhere in a plugin and I
just use it in my project's root POM. For IDEA I still need need
"-DprojectRootDir=..." in /.mvn/jvm.config, but from the
command line it works, even when building from a module subdirectory.
Here is my POM (just search for the string "rootlocation" there, you
should find 4 places):

https://github.com/SarekTest/Sarek/blob/master/pom.xml
-- 
Alexander Kriegisch
https://scrum-master.de


Falko Modler schrieb am 06.02.2021 04:35 (GMT +07:00):

> For me, no problem on Jenkins either (using "withMaven" pipeline step).
> There used to be this issue: https://issues.jenkins.io/browse/JENKINS-35335
> Which turned out to be a Maven bug which was fixed in 3.5.0:
> https://issues.apache.org/jira/browse/MNG-5889
> 
> As far as MNG-5830 is concerned, I don't know what (special) setup the
> affected people are using.
> 
> I can only say/repeat that you need a .mvn directory to have the
> property point to your root directory.
> But even without .mvn, there should not be such an error message, so IDK
> what's going on in those cases.
> 
> Am 05.02.2021 um 22:13 schrieb Delany:
>> Maybe for you Falko, but not my Jenkins server with Maven 3.6.3, or these
>> other users
>> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
>> Delany
>>
>>
>> On Fri, 5 Feb 2021, 22:25 Falko Modler,  wrote:
>>
>>> I've been using maven.multiModuleProjectDirectory in various projects
>>> (and have also seen it in others).
>>> You'll need a .mvn directory in your root directory to make it work.
>>>
>>> PS: I know that there has been some controvery about this property but
>>> well, it works! ;-)
>>>
>>> Cheers,
>>> Falko
>>>
>>> Am 05.02.2021 um 17:03 schrieb Andres Almiray:
 Hello everyone,

 Is there a way to reliably resolve the value of the root directory for a
 given multi-project build?
 Unfortunately ${session.executionRootDirectory} does not seem to work for
 all cases, it might work when used inside a plugin's 
 section but does not when used outside of plugins

 TIA

 Cheers,
 Andres

 ---
 Java Champion; Groovy Enthusiast
 http://andresalmiray.com
 http://www.linkedin.com/in/aalmiray
 --
 What goes up, must come down. Ask any system administrator.
 There are 10 types of people in the world: Those who understand binary,
>>> and
 those who don't.
 To understand recursion, we must first understand recursion.

>>>
>>> -
>>> 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

Maven compiler plugin Unsupported major.minor version

[Andrea Vacondio]

Hi,
I hope this is the right channel.
I have a multi module project that I'm trying to modularize in the JPMS
sense.
It's configured to run maven with java 11 and run the compiler plugin using
java 15 through the toolchain plugin and this is what I get:

[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @
pdfblack-model ---
[INFO] Toolchain in maven-compiler-plugin: JDK[/usr/lib/jvm/jdk-15.0.1+9]
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time:  1.141 s
[INFO] Finished at: 2021-02-05T18:07:26+01:00
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
(default-compile) on project pdfblack-model: Execution default-compile of
goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed:
Unsupported major.minor version 59.65535 -> [Help 1]

I attached the full stacktrace at the bottom.
It seems to me the plugin is using jdk11 to do something where it should
use jdk15 from the toolchain but before digging deeper I wanted to double
check if I'm doing anything wrong or if maybe my expectations are wrong.
This is my configuration, nothing special there:

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

15

--enable-preview




This is the stacktrace:
Execution default-compile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed:
Unsupported major.minor version 59.65535
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-compile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed:
Unsupported major.minor version 59.65535
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke