jira-importer commented on PR #185:
URL:
https://github.com/apache/maven-site-plugin/pull/185#issuecomment-2974825385
Resolve #1128
--
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 the specific c
Howdy,
part2: now ITs got full isolation (from user env that runs them). This
means that ITs are running in their own (dedicated and fully
controlled) $HOME.
The flipside: Maven IT suite (the one in Maven repo) can be run ONLY
with Maven 3.9+ (local repo tail support required).
Which is IMO fine
Howdy,
just a heads up, as Maven ITs got quite a change(s). For starters, the
"embedded" profile is gone, as it is the default now. If you want
"forked" execution (slow but most isolated), use the new "forked"
profile.
Second, maven-verifier and maven-shared-utils
gt; Thanks
> T
>
> On Fri, Oct 11, 2024 at 8:33 PM Hervé Boutemy
> wrote:
> >
> > in fact, putting everything in 1 Git repo does not force to run 1 single
> > build: we can continue running in separate executions
> >
> > and with this, nothing prevent
inue running in separate executions
>
> and with this, nothing prevents from running the its HEAD against another
> commit for Maven core build
>
> Le jeudi 10 octobre 2024, 13:47:31 CEST Michael Osipov a écrit :
> > No, it won't, but it will allow you to integrate the IT
in fact, putting everything in 1 Git repo does not force to run 1 single
build: we can continue running in separate executions
and with this, nothing prevents from running the its HEAD against another
commit for Maven core build
Le jeudi 10 octobre 2024, 13:47:31 CEST Michael Osipov a écrit
the resulting history looks reasonable
and we can later split with filter if necessary
I don't know if making one single build is useful, or keeping 2 separate, or
even promoting 3 (Maven core itself, ITs build, ITs run)
But definitively, doing one single Git commit when doing a feature
a now abandoned plan and can be revisited
now if it makes sense.
Way back in the day, some devs who are no longer around had really
ambitious plans for maven that never really materialized. Among other
things, this led to Plexus and Modello and are the cause of much
technical debt in Maven. I suspe
e same time…
>
>
> Guillaume Nodet
>
>
>
> Le jeu. 10 oct. 2024 à 09:41, Michael Osipov a écrit :
>
> > A few notes on this though I am neutral:
> >
> > * Significant growth of repo, thus repo size for those who simply don't
> > need
instead sub module makes them more pain ...
发件人: Guillaume Nodet
发送时间: 星期四, 十月 10, 2024 7:22:45 下午
收件人: Maven Developers List
主题: Re: [DISCUSS] Merge ITs in maven
I don’t see git submodules fixing the pain of having to create two PRs,
keeping them aligned
ral:
>
> * Significant growth of repo, thus repo size for those who simply don't
> need ITs
> * A compat kit (which it is) is usually a separate repo/product/project
> * Though I consider Git submodules as a horrible implementation compared
> to Subversion externals, it could live as an
A few notes on this though I am neutral:
* Significant growth of repo, thus repo size for those who simply don't need ITs
* A compat kit (which it is) is usually a separate repo/product/project
* Though I consider Git submodules as a horrible implementation compared to
Subversion external
; I agree that having to specify version ranges for maven version in each
> > > test looks odd if it is part of the repo itself, I always has seen this
> > > more as some kind of compatibility-test-kit that can be used
> independent
> > > of maven itself.
> > >
ges for maven version in each
> > test looks odd if it is part of the repo itself, I always has seen this
> > more as some kind of compatibility-test-kit that can be used independent
> > of maven itself.
> >
> >
> > Am 09.10.24 um 08:33 schrieb Herve Boutemy:
> >
>
> > AFAIK, the interest of having a separate project of core ITs is to clear
> > state the Maven core version range for each test, to clearly document when
> > things were introduced / broken / fixed and even be able to run HEAD ITs
> > against a past release
> &g
that folder anyway...
>
> Guillaume Nodet 于2024年10月9日周三 15:11写道：
>
> > I just pushed a branch with the results:
> >https://github.com/gnodet/maven/tree/merge-its
> >
> > This is just the raw output of the recipe. The ITs are not integrated
> into
> > the bu
RAT checks has a excluding rule, if we really wanna so we can just exclude
that folder anyway...
Guillaume Nodet 于2024年10月9日周三 15:11写道：
> I just pushed a branch with the results:
>https://github.com/gnodet/maven/tree/merge-its
>
> This is just the raw output of the recipe. The
I just pushed a branch with the results:
https://github.com/gnodet/maven/tree/merge-its
This is just the raw output of the recipe. The ITs are not integrated into
the build, which will even fail due to RAT checks and maybe other reasons.
Le mer. 9 oct. 2024 à 08:35, Herve Boutemy a écrit
gt; >
> > AFAIK, the interest of having a separate project of core ITs is to clear
> state the Maven core version range for each test, to clearly document when
> things were introduced / broken / fixed and even be able to run HEAD ITs
> against a past release
> >
> > is
of compatibility-test-kit that can be used independent
of maven itself.
Am 09.10.24 um 08:33 schrieb Herve Boutemy:
I understand how it adds complexity
AFAIK, the interest of having a separate project of core ITs is to clear state
the Maven core version range for each test, to clearly document
I understand how it adds complexity
AFAIK, the interest of having a separate project of core ITs is to clear state
the Maven core version range for each test, to clearly document when things
were introduced / broken / fixed and even be able to run HEAD ITs against a
past release
is it the
run
while building / developing it.
Matthias
Am 08.10.2024 um 08:36 schrieb Guillaume Nodet:
I'd like to discuss merging ITs into maven core repository.
The ITs have already been splitted some time ago between the 3.x branch and
master for testing Maven master. But I don't really see a goo
I'd like to discuss merging ITs into maven core repository.
The ITs have already been splitted some time ago between the 3.x branch and
master for testing Maven master. But I don't really see a good reason to
keep the repositories separated, this makes things more complicated when
modif
Hi again,
It appears that images are not possible, or I made a mistake, so I will
post the text variant as follow up.
A dependency example with *maven 4.0.0-alpha12*
org.example
mng-7344-dep-w
4
compile
org.example
mng-7344-dep-x
*
Hi all,
Juul Hobert and I took it upon ourselves to see if we can resolve the
following tickets.
- MNG-7344 (https://issues.apache.org/jira/browse/MNG-7344)
- MPH-183 (https://issues.apache.org/jira/browse/MPH-183)
These were originally implemented by Jan-Jelle Kester in a PoC, and later
further b
Am 2021-12-29 um 09:16 schrieb Maarten Mulders:
Hi Michael e.a.,
Can confirm, I'm seeing the same. The first error (URL contains an
expression but should be a constant) is completely unfamiliar to me. I
worked around it in a similar way as part of your patch, but I don't
know what caused it o
Hi Michael e.a.,
Can confirm, I'm seeing the same. The first error (URL contains an
expression but should be a constant) is completely unfamiliar to me. I
worked around it in a similar way as part of your patch, but I don't
know what caused it or what should be the eventual solution.
After h
Folks,
am I the only one suffering from this?
$ mvn -v
Apache Maven 4.0.0-alpha-1-SNAPSHOT (0a8bd727ac6d184512ce513737bb56bb840d10de)
Maven home: /usr/home/mosipov/apache-maven
Java version: 1.8.0_312, vendor: OpenJDK BSD Porting Team, runtime:
/usr/local/openjdk8/jre
Default locale: de_DE, pla
the trick done by other plugins is to write an integration test with a
> toolchains.xm, filtering it with the Java Runtime path.
> Best it to search for ITs by one of the toolchain-aware plugins[1]
>
> thanks,
> Robert
>
> [1] https://maven.apache.org/guides/mini/guide-using-toolc
that's actually a question for builds@a.o
IIRC the trick done by other plugins is to write an integration test with a
toolchains.xm, filtering it with the Java Runtime path.
Best it to search for ITs by one of the toolchain-aware plugins[1]
thanks,
Robert
[1] https://maven.apache.org/g
Hi all,
I'm trying to create a IT that uses toolchain. I've configured it in the
test's pom [1] and in invoker.properties [2]. Locally, the IT executed,
but on ci-builds.a.o the test "MPMD-304-toolchain-support" is skipped
"due to Toolchain" [3]. I was assuming, that the toolchains configured
by p
:57 schreef :
> >
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> michaelo pushed a commit to branch master
> >> in repository
> >> https://gitbox.apache.org/repos/asf/maven-integration-testing.git
/asf/maven-integration-testing.git
The following commit(s) were added to refs/heads/master by this push:
new 59bcf77 Sort ITs in reverse numerical order
59bcf77 is described below
commit 59bcf77d4f43115e3779933e4eeef2676af60300
Author: Michael Osipov
AuthorDate: Wed Aug 5 20:57:33 2020 +0200
ushed a commit to branch master
> in repository
> https://gitbox.apache.org/repos/asf/maven-integration-testing.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 59bcf77 Sort ITs in reverse numerical order
> 59
On Mon, Jul 20, 2020 at 11:32 AM Gary Gregory
wrote:
> Hi All:
>
> What is the best way to add columns to the change report (for example
> https://commons.apache.org/proper/commons-lang/changes-report.html)?
>
> I'd like to add a columns for:
> - "JRE Version" (for example "8")
> - "Javadoc" (for
Hi All:
What is the best way to add columns to the change report (for example
https://commons.apache.org/proper/commons-lang/changes-report.html)?
I'd like to add a columns for:
- "JRE Version" (for example "8")
- "Javadoc" (for example, the text "Javadoc" with a URL)
I do not see allowances for
where can can improve buildtime, and that is actually the surefire
> project. To me it is insane to see 20 different builds that take between
> about 1h and 1.5h on a shared infrastructure, whereas ITs of Maven take
> less than 0.5h. So the biggest gain is not on Maven ITs.
>
> thanks,
Robert, the performance of core-its was mentioned as an additional and not
mandatory side effect but not a target goal.
The target goal is to remove Maven 2 tests at least.
We should do that same for the integration tests with deprecated and
unsupported versions of Maven.
Removing them would
ject
where can can improve buildtime, and that is actually the surefire
project. To me it is insane to see 20 different builds that take between
about 1h and 1.5h on a shared infrastructure, whereas ITs of Maven take
less than 0.5h. So the biggest gain is not on Maven ITs.
thanks,
Robert
On Su
Hi all,
I have noticed several technical issues in core-its:
1. some tests are not listed in the IntegrationTestSuite.java.
I have already added two (MavenITmng5175WagonHttpTest,
MavenIT0146InstallerSnapshotNaming).
Some tests are broken, excluded from the execution and they are listed
Hi devs,
I hope you have spent a nice weekend ;-)
Integrated new Surefire feature [1] in the core-its branch [2] which fixed
the first issue (see point 1.) and the build is successful [3].
After making an analysis, with a help of the logs, we can see that there
are 3 known issues at least:
1
: Robert Scholte
Gesendet: Sonntag, August 4, 2019 8:26 PM
An: Maven Developers List
Betreff: Re: [SUMMARY] 3 ITs permanently fail on Linux / Maven Core
No, there's no need for that and it would over-complicate the scripts.
mavenrc can be handy, but only at INFRA level.
As said, we were able to f
Gesendet: Samstag, August 3, 2019 9:12 PM
An: Maven Developers List
Betreff: [SUMMARY] 3 ITs permanently fail on Linux / Maven Core
Here's a very short summary and conclusion about what happened the last
period.
Half July some integration tests of Maven started to fail, but not always
(it goo
Do we need a Maven Option to turn of processing of implicit configurations,
just like you can turn of shellrc Files?
--
http://bernd.eckenfels.net
Von: Robert Scholte
Gesendet: Samstag, August 3, 2019 9:12 PM
An: Maven Developers List
Betreff: [SUMMARY] 3 ITs
and probably beyond Jenkins. Containers might
play a role.
Using containers will isolate some issues, but I prefer to test Maven as
it is used by its users. Even though I don't have the numbers, I still
think most use it directly on the OS. The usage of Maven inside a
container is pro
nvestigation.
> All changes that were done to change the behavior related to environments
> variables and mavenrc file should and will be reverted.
> Mavens master branch was stable, so to ensure the right things are still
> tested the need to be restored (some of them did indeed test the
&
that were done to change the behavior related to environments
variables and mavenrc file should and will be reverted.
Mavens master branch was stable, so to ensure the right things are still
tested the need to be restored (some of them did indeed test the
MAVEN_OPTS explicitly as issued in its
ble( "MAVEN_SKIP_RC", "1" );
> > +}
>
> requires forked execution of Maven
> this de-facto disables embedder mode
>
> as a consequence, we can see on ASF Jenkins server [1] that build time for
> core ITs has doubled.
>
> Where has this commit
here it is: issue fixed
as you can see by reading the INFRA-18812 Jira issue [1]:
- .mavenrc file polluting Jenkins slaves was created by Shardingshpere project
- Robert proposed a PR to the project
- INFRA removed unwanted .mavenrc files
now the ITs depending on MAVEN_OPTS are back working
doing
> +if ( MAVEN_SKIP_RC )
> +{
> +verifier.setEnvironmentVariable( "MAVEN_SKIP_RC", "1" );
> +}
requires forked execution of Maven
this de-facto disables embedder mode
as a consequence, we can see on ASF Jenkins server [1] t
previous
> value that was set in our IT code
>
> such script should define:
> MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=256m ${MAVEN_OPTS}
>
>
> this will solve issues of Maven core ITs requiring MAVEN_OPTS
>
> I don't know for maven-archetype, I'm not working on i
value that was set in our IT code
such script should define:
MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=256m ${MAVEN_OPTS}
this will solve issues of Maven core ITs requiring MAVEN_OPTS
I don't know for maven-archetype, I'm not working on it, and this thread is
not about it: I don't kn
Jenkins build is in progress and waiting for next available executor.
I think we will have the result today evening.
Shortly I skipped '.mavenrc' merging, see [1] and I expect successful
ITs(0553, 4747, 4590) and I expect newly failed IT (6720) which should be
orthogonal to our curre
see in your email.
So I think all we have to do is to export MAVEN_SKIP_RC to 1 in our ITs and
prevent from merging global and local environment variables.
if [ -z "$MAVEN_SKIP_RC" ] ; then
if [ -f /etc/mavenrc ] ; then
. /etc/mavenrc
fi
if [ -f "$HOME/.mavenrc" ]
enkins/.mavenrc ]
> + . /home/jenkins/.mavenrc
> + MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=256m
>
> there is a .mavenrc script on some Linux nodes that overrides MAVEN_OPTS
> instead of appending: I did not yet report to INFRA, need to check if this
> variable is defined with Puppet and pr
instead of appending: I did not yet report to INFRA, need to check if this
variable is defined with Puppet and provide a PR
FYI, core ITs log files have finally always been accessible: just need to look
inside
org\apache\maven\its\core-it-suite\2.1-SNAPSHOT\core-it-suite-2.1-SNAPSHOT-tests.jar
aven-resolver-1.3.3-reset-head-12` crashed with Linux + JDK 7, 8, 11, 12
> (16 ITs)
> `maven-resolver-1.3.3-reset-head-14` crashed with Linux + JDK 7 and 8 (8
> ITs)
> `maven-resolver-1.3.3-reset-head-29` crashed Linux JDK 8 (4 ITs)
>
> Always the ITs 0553, 4590, 4747 fail on several
from apache/maven-archetype.
> Here you can see how to archive the build result of all ITs from failed
> builds for further analysis:
>
> asfMavenTlpPlgnBuild(tmpWs: true, archives: ['archetype-plugin-its' :
> 'maven-archetype-plugin/target/it/projects'])
>
>
>
> Cheers
> Tibor17
>
Hi devs,
Now we can archive any directories in plugin builds.
This feature was enabled in Jenkins library maven-jenkins-lib.
For instance, this is the Jenkinsfile script from apache/maven-archetype.
Here you can see how to archive the build result of all ITs from failed
builds for further
now if the root cause is identical with the one you described in
> > your email regarding the parameter mavenOpts and shared environment
> > variable but I am sure you can reproduce it too.
> > These are my reprosteps:
> >
> > 1. clone the project apache/maven-resolv
Am 2019-07-20 um 12:25 schrieb Hervé BOUTEMY:
As a side note, I started by doing a lot of cleanup on old merged branches: it
would be nice if everybody did its own cleanup when merging
I have purged all of my merged branches, there are still a lot of open
branches
your email regarding the parameter mavenOpts and shared environment
variable but I am sure you can reproduce it too.
These are my reprosteps:
1. clone the project apache/maven-resolver
2. use JDK 1.8 in JAVA_HOME
3. run the build "mvn install -P run-its"
The build fails with:
[ERROR]
s:
1. clone the project apache/maven-resolver
2. use JDK 1.8 in JAVA_HOME
3. run the build "mvn install -P run-its"
The build fails with:
[ERROR] The following builds failed:
The following builds failed:
* build-and-run-its\pom.xml
* build-archetype\pom.xml
* build-ignore-eol\pom.xml
When
g JDK 7. When building maven-release itself you will have
to
> provide the system property for JDK 7, but not when using UK mirror
;-)
>
> Cheers, Clemens
>
> Am 24.07.2019 um 23:20 schrieb Robert Scholte:
>> Hi Clemens,
>>
>> We need to stay as close as possible
gt; > ...
> >
> > Of course, this only takes care of when you release something with the
> > plugin using JDK 7. When building maven-release itself you will have
> to
> > provide the system property for JDK 7, but not when using UK mirror ;-)
> >
> > Cheers,
)
Cheers, Clemens
Am 24.07.2019 um 23:20 schrieb Robert Scholte:
Hi Clemens,
We need to stay as close as possible to the real world.
With JDK8+ it should work without its being set, so the preferred way
it to execute it without the value being set.
And this way, once we must move TLS 1.3 we don
>>
>>
>>
>> ...
>>
>> Of course, this only takes care of when you release something with the
>> plugin using JDK 7. When building maven-release itself you will have to
>> provide the system property for JDK 7, but not when usin
will have to
> provide the system property for JDK 7, but not when using UK mirror ;-)
>
> Cheers, Clemens
>
> Am 24.07.2019 um 23:20 schrieb Robert Scholte:
> > Hi Clemens,
> >
> > We need to stay as close as possible to the real world.
> > With JDK8+ it should work w
schrieb Robert Scholte:
Hi Clemens,
We need to stay as close as possible to the real world.
With JDK8+ it should work without its being set, so the preferred way
it to execute it without the value being set.
And this way, once we must move TLS 1.3 we don't have to change all
our tests.
H
ovide an IT, too, and had a look
into it:
Running
mvn verify -Prun-its
with Maven 3.6.1 and JDK 7 Update 80 fails:
...
[INFO] Building: projects\perform\MRELEASE-459\pom.xml
[INFO] run post-build script verify.groovy
[INFO] The post-build script did not succeed. assert matcher.find()
Hi Clemens,
We need to stay as close as possible to the real world.
With JDK8+ it should work without its being set, so the preferred way it
to execute it without the value being set.
And this way, once we must move TLS 1.3 we don't have to change all our
tests.
Here's how we do i
me JUnit tests
recently.
Now I was wondering if i should provide an IT, too, and had a look
into it:
Running
mvn verify -Prun-its
with Maven 3.6.1 and JDK 7 Update 80 fails:
...
[INFO] Building: projects\perform\MRELEASE-459\pom.xml
[INFO] run post-build script verify.groovy
[INFO] The post-b
project running with Maven and Java 7, it'll fail very fast,
> > i.e. by the first plugin.
> >
> > thanks,
> > Robert
> >
> > On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss
> > wrote:
> >
> >> Hello everyone,
> >>
> >> I ha
e,
>>
>> I have provided a PR for MRELEASE-229 [1] and added some JUnit tests
>> recently.
>>
>> Now I was wondering if i should provide an IT, too, and had a look
>> into it:
>>
>> Running
>>
>> mvn verify -Prun-its
>>
>> with Mav
Hi Robert,
having put some more thought into it I was thinking: maybe the IT
should prove that the jira issue integrates with the plugin. In that
case the name would be OK and I would also have a path for providing an
IT for MRELEASE-229. As of now there are no ITs for release:rollback
i.e. by the first plugin.
thanks,
Robert
On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss
wrote:
Hello everyone,
I have provided a PR for MRELEASE-229 [1] and added some JUnit tests
recently.
Now I was wondering if i should provide an IT, too, and had a look
into it:
Running
mvn ver
2:15 +0200, Clemens Quoss wrote:
Hello everyone,
I have provided a PR for MRELEASE-229 [1] and added some JUnit tests
recently.
Now I was wondering if i should provide an IT, too, and had a look into
it:
Running
mvn verify -Prun-its
with Maven 3.6.1 and JDK 7 Update 80 fails:
...
[INFO
e more question regarding the name of the ITs in maven-release (or
maybe generally):
Seeing that the tests are named after the jira issues i am wondering if
that would be the right thing to do.
Shouldn't they be named after the functionality they are testing?
I for my part, being ne
H44
to me, Maven core master branch is currently stable: the 4 ITs failing we see
are caused by ASF Jenkins issues
If someone wants to launch a release, I'm fully supportive
Of course, if anybody has an idea on the root cause to the MAVEN_OPTS issue,
I'm all ears open...
Regards,
IP file tells us more, e.g. logs at least.
Definitely something is wrong on Jenkins/Linux or in Jenkinsfile because
the build #22 was successful in
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6294/ one month
ago, but I manually triggered #23 and I have got the same set of failed ITs
I don't get where you want to go: there is no disagreement on reverting
resolver from 1.4.0 to 1.3.3
the question is, once this revert has been done, about the 4 ITs failing [2]:
master #242 linux-jdk7 / Run ITs Linux Jav
build #242 failed
> on
> the 4 ITs on Linux JDK 7: really strange. FYI, I'm personally on Linux
> with
> Java 7 and I can't reproduce the issue. And the fact that Maven 3.6.0
> branch
> fails on the same ITs, but sometimes on other configurations, makes me
> think
little update on master branch runs in ASF Jenkins [1]:
build #240: stupidly failed on a Git issue on a node
then I launched build #241 *which worked fully*!!!
to be sure of the stability, I relaunched the build, and build #242 failed on
the 4 ITs on Linux JDK 7: really strange. FYI, I&#
Clemens, why the issues cannot use Jira ID only?
If somebody wants to know more, she/he can still open Jira and see.
Another position is when you develop a new feature and then human readable
name should be used.
This way we know that we have more ITs for bug than originally TDD
features, or
release:rollback.
In the unit tests maven-scm is mocked away and i think in the ITs of
maven-release maven-scm is out of scope, too.
Then there is not really much left to test there.
Maybe someone out there has a different opinion? And we can discuss
this further in private mail?
TIA
Clemens
Am
oes what the name suggests: it uses maven-scm to remove
> the tag during release:rollback.
> In the unit tests maven-scm is mocked away and i think in the ITs of
> maven-release maven-scm is out of scope, too.
> Then there is not really much left to test there.
> Maybe someone out th
, 8, 11, 12
(16 ITs)
`maven-resolver-1.3.3-reset-head-14` crashed with Linux + JDK 7 and 8 (8
ITs)
`maven-resolver-1.3.3-reset-head-29` crashed Linux JDK 8 (4 ITs)
Always the ITs 0553, 4590, 4747 fail on several nodes.
Always related to Linux.
See the list of errors and branches:
https
https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
[1] https://maven.apache.org/core-its/core-it-suite/
Am 15.07.2019 um 02:59 schrieb Tibor Digana:
Hi Clemens,
Simply I am using JDK 1.7.0_80-b15 and our Jenkins also has this version.
I could not find and download later update of JD
Hi Olivier,
yeah, could do that. Would be a great idea. But i am stuck on what to
put into this IT:
RemoveScmTag does what the name suggests: it uses maven-scm to remove
the tag during release:rollback.
In the unit tests maven-scm is mocked away and i think in the ITs of
maven-release maven
on your side with this system property
> set when using JDK 7? What Update of JDK 7 are you normally using for ITs?
> So this property was already around when IT for MRELEASE-459 was
> written? That would explain it.
> One mor question, please: How would I have been able to avoid all
Hi
I agree the name is a bit confusing...
maybe name the IT: MRELEASE-229-RemoveScmTagPhase?
On Sun, 14 Jul 2019 at 20:06, Clemens Quoss wrote:
> Hello everyone,
>
> one more question regarding the name of the ITs in maven-release (or
> maybe generally):
>
> Seeing that t
JDK 7 are you normally using for ITs?
So this property was already around when IT for MRELEASE-459 was
written? That would explain it.
One mor question, please: How would I have been able to avoid all this
noise in the dev-mail-group? Where could I have read about this system
property? Is it
Did you already run the build like this on J7?
mvn verify -P run-its -Dhttps.protocols=TLSv1.2
and you have got those errors as in previous email?
Cheers
Tibor
On Sun, Jul 14, 2019 at 6:32 PM Clemens Quoss wrote:
> Hi Tibor,
>
> by looking further into it I noticed this:
>
&g
ls=TLSv1.2 in to
CLI when using J7.
The Jenkinsfile does it [1] already but we should investigate the ITs and
add TLS in CLI of the ITs as well unless it's in there.
[1]:
https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpSt
Hi Clemens,
I think you are right, I also have to add -Dhttps.protocols=TLSv1.2 in to
CLI when using J7.
The Jenkinsfile does it [1] already but we should investigate the ITs and
add TLS in CLI of the ITs as well unless it's in there.
[1]:
https://gitbox.apache.org/repos/asf?p=maven-je
Il dom 14 lug 2019, 11:52 Clemens Quoss ha scritto:
> Hello everyone,
>
> I have provided a PR for MRELEASE-229 [1] and added some JUnit tests
> recently.
>
> Now I was wondering if i should provide an IT, too, and had a look into it:
>
> Running
>
> mvn verify -Pru
Hello everyone,
one more question regarding the name of the ITs in maven-release (or
maybe generally):
Seeing that the tests are named after the jira issues i am wondering if
that would be the right thing to do.
Shouldn't they be named after the functionality they are testing?
I f
Hello everyone,
I have provided a PR for MRELEASE-229 [1] and added some JUnit tests
recently.
Now I was wondering if i should provide an IT, too, and had a look into it:
Running
mvn verify -Prun-its
with Maven 3.6.1 and JDK 7 Update 80 fails:
...
[INFO] Building: projects\perform
gitbox.apache.org/repos/asf/maven-scm-publish-plugin.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 471c7de exclude Windows from ITs: require svn and svnadmin executables
> 471c7de is described below
>
> commit 471c7de83b67b50e0fb6f9
This is an automated email from the ASF dual-hosted git repository.
hboutemy pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-scm-publish-plugin.git
The following commit(s) were added to refs/heads/master by this push:
new 471c7de exclude Windows from ITs: requi
1 - 100 of 491 matches
Mail list logo
