Side note: shrinkwrap has a loadSetting (no more 100% sure of the name)
method you can use in the code if -Dmy.setting is set so you can configure
it in surefire and tomee has some too in its Mvn wrapper IIRC so can be a
simpler way to align it all - maybe even using JMX to get JVM arg and
extract
Hello,
I still could not find any solution to this problem
I have cross posted on stackoverflow :
https://stackoverflow.com/questions/66181515/defaultprojectbuildingrequest-org-apache-maven-project-projectbuildingexception
Please let me know if my question is not posted in the right mailing lis
asfgit merged pull request #228:
URL: https://github.com/apache/maven-site/pull/228
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to
hboutemy commented on pull request #228:
URL: https://github.com/apache/maven-site/pull/228#issuecomment-778500519
yes, we can add such an image in a future step
This is an automated message from the Apache Git Service.
To re
Thank you all for the feedback provided so far.
I was not aware of Maven Wrapper coming in 3.7, and also the plain sh
script seems to be right the approach the
https://github.com/sdkman/sdkman-action took.
I just ping Eddú to know his feedback on the sdkman-action since it's not
even listed in the
FWIW there’s an sdkman GHA in case you’d like to explore that option
https://github.com/sdkman/sdkman-action
Cheers
Andres
Sent from my primitive tricorder
> On 12 Feb 2021, at 20:52, Romain Manni-Bucau wrote:
>
> Hi César,
>
> Any interesting feature compared to using a plain sh script wi
Hi César,
Any interesting feature compared to using a plain sh script with sdkman?
Looks like saner since it will enable you to setup java and maven properly
at the same stage which is the actual prerequisite of a maven build vs
using multiple random actions.
Did you investigate this option?
Roma
I'm only aware of MNG-6887.
Robert
[1] https://issues.apache.org/jira/browse/MNG-6887
On 12-2-2021 19:40:24, Gary Gregory wrote:
I've been wanting such an GH action myself!
Gary
On Fri, Feb 12, 2021 at 12:52 PM Cesar Hernandez
wrote:
> Hi,
>
> The problems:
>
> Currently, the official Github
rfscholte commented on pull request #228:
URL: https://github.com/apache/maven-site/pull/228#issuecomment-778408664
Sometimes images say more than words. Looks like this one should have a
picture of a graph to support the logic.
hboutemy commented on pull request #228:
URL: https://github.com/apache/maven-site/pull/228#issuecomment-778379785
yes, the last description is the hard one where we need creativity...
"POMs from dependency path to the artifact"?
-
I've been wanting such an GH action myself!
Gary
On Fri, Feb 12, 2021 at 12:52 PM Cesar Hernandez
wrote:
> Hi,
>
> The problems:
>
> Currently, the official Github actions for building and testing Java with
> Maven [1] don't offer a way to specify the Maven version a workflow can
> use.
> Addin
Hi all,
FWIW, a wrapper also doesn't help if you want to test extensions or
plugins with multiple Maven versions.
E.g.:
-
https://github.com/gitflow-incremental-builder/gitflow-incremental-builder/blob/master/.github/workflows/maven.yml#L105-L136
-
https://github.com/gitflow-incremental-builder/g
Cesar,
Maven 4 will include a wrapper script that should take care of this issue.
For Maven 3.x you may use Takari's Maven Wrapper[1] to get similar behavior.
However for those that can't set a wrapper for several reasons (for example
Apache projects do not allow JARs in their repositories those
Hi,
The problems:
Currently, the official Github actions for building and testing Java with
Maven [1] don't offer a way to specify the Maven version a workflow can use.
Adding this support seems to be out of the scope of the
current actions/checkout@v2. [2].
In the Github actions market are alre
rfscholte commented on pull request #228:
URL: https://github.com/apache/maven-site/pull/228#issuecomment-778141870
The last description is still not clear for me. I think what we're trying to
say: repositories within context, i.e the reposities of the pom that defined
this pom as a depend
hboutemy edited a comment on pull request #228:
URL: https://github.com/apache/maven-site/pull/228#issuecomment-778125511
@rfscholte local POM does not have any resolution: it is locally on disk,
from Git
resolution is always for dependencies
> transitive dependencies are never ef
hboutemy commented on pull request #228:
URL: https://github.com/apache/maven-site/pull/228#issuecomment-778125511
@rfscholte local POM does not have any resolution: it is locally on disk,
from Git
resolution is always for dependencies
> transitive dependencies are never effected
rfscholte commented on pull request #228:
URL: https://github.com/apache/maven-site/pull/228#issuecomment-778089075
I suggest to split this up into two:
- The repository resolution order for a local/reactor pom
- The repository resolution order for a dependency pom
It must be v
18 matches
Mail list logo
