Eval is probably needed,
just look at how open liberty merges those lines [1].
As a user, I would expect spaces and comments to be supported.
[1]:
Markdown is not a "standard" or "standardized".
Even worse, different implementations have different feature sets.
Thus my -1 for md.
But another format might be feasible, really. fml looks verbose.
Asciidoc might be a sane choice here. It was specially designed for
technical documentation and
; > > > > > > > formatter-like api.
> > > > > > > >
> > > > > > > > Guillaume Nodet
> > > > > > > >
> > > > > > > > Le lun. 25 janv. 2021 à 07:41, Mark Struberg
> > > > > > > > > >
; >
> > > > > > > Le lun. 25 janv. 2021 à 07:41, Mark Struberg
> > > > > > > >
> > > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > +1Technically from a
inclusion support [1], feel free to
> have a look.
>
> [1] https://github.com/apache/maven-enforcer/pull/86
>
> ср, 20 янв. 2021 г. в 22:50, Benjamin Marwell :
>
> > Hi,
> >
> > in [1] MENFORCER-338, there is a comment that an exclusion/inclusion
> > list mi
junit.Test;
>
> public class ViolationTest
> {
>
> @Test
> public void testEquals() {
> Violation v1 = new Violation("", null, "", "", "", "", "");
> Violation v2 = new Violation("", n
[X] +1 (non binding)
sha512 is correct for me
Works in a sample project.
Am So., 24. Jan. 2021 um 00:02 Uhr schrieb Sylwester Lachiewicz
:
>
> Hi,
>
> We solved 5 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223=12347024=Text
>
> There are still a couple of
Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le sam. 23 janv. 2021 à 17:58, Benjamin Marwell a
> écrit :
Robert, that's deprecated! What to use instead? Or was it deprecated in
error?
https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/java/org/apache/maven/plugin/logging/Log.java
On Sat, 23 Jan 2021, 12:10 Robert Scholte, wrote:
> See
>
https://maven.apache.org/maven-logging.html needs to be updated,
but also some plugins where changes were already made.
This was from slack: https://issues.apache.org/jira/browse/MNG-6931
And plugins pulling in slf4j directly happen all the time:
Hi,
in [1] MENFORCER-338, there is a comment that an exclusion/inclusion
list might be feasible.
If there is a release soon, such an upcoming PR will break the single
item in -M5.
Should this be altered before release?
[1] https://issues.apache.org/jira/browse/MENFORCER-338
Am Mi., 20. Jan.
The Maven team is pleased to announce the release of the Apache Maven
JLink Plugin, version 3.1.0
The JLink Plugin is intended to create a Modular Java Run-Time Images via jlink.
https://maven.apache.org/plugins/maven-jlink-plugin/
You should specify the version in your project's plugin
; probably there is no need for a fix on Maven
>
> Enrico
>
> Il giorno lun 14 dic 2020 alle ore 22:12 Benjamin Marwell <
> bmarw...@apache.org> ha scritto:
>
> > > I'm pretty sure this can be solved without touching the maven startup
> > scripts.
> &
If this happens again,
Please add it to the ticket as requested by infra. Link below.
Thanks
- Ben
https://issues.apache.org/jira/browse/INFRA-21244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259498#comment-17259498
On Fri, 1 Jan 2021, 16:54 Benjamin Marwell
Hello everyone!
Originally I opened issue INFRA-21061 [1] for Apache Shiro, when I became a
committer and found out that OpenJ9 did not implement non-mandatory aliases
for some cryptographic algorithms (and was right to omit them as per spec).
Anyway, OpenJ9 arrived on the Apache Jenkins
Happy new year everyone!
Maybe you want to add the links to the ticket, so infra has more jobs to
analyse?
- Ben
On Fri, 1 Jan 2021, 16:16 Elliotte Rusty Harold, wrote:
> And the next run everything passed without any code changes:
>
>
>
Here you go: https://issues.apache.org/jira/browse/INFRA-21244
Already opened a week ago when Hervé tried to merge a PR and suddenly the
build failed.
Disabling JDK15 might be a valid solution if they don't react soon.
On Wed, 30 Dec 2020, 14:59 Elliotte Rusty Harold,
wrote:
> The Windows
Hi,
The vote has passed with the following result:
+1: Sylwester Lachiewicz, Romain Manni-Bucau, Karl Heinz Marbaise, Hervé
BOUTEMY, Benjamin Marwell, Robert Scholte
PMC quorum: reached
I will promote the artifacts to the central repo.
Hi,
The vote has passed with the following result:
+1: Sylwester Lachiewicz, Romain Manni-Bucau, Karl Heinz Marbaise, Hervé
BOUTEMY, Benjamin Marwell, Robert Scholte
PMC quorum: reached
I will promote the artifacts to the central repo.
Am So., 27. Dez. 2020 um 14:13 Uhr schrieb Robert Scholte
Hi Sandra,
hi everyone,
here’s another subtopic:
I recently added a comment like this: // [issue-##]: Do call method x
because of side effect x
But I got a review "the comment is redundant because of the git log".
Is there a policy on where and how to put comments in the code?
Reference:
Hi,
I need one more PMC vote please. :-)
Btw, here is my +1 (non-binding).
Am Mo., 21. Dez. 2020 um 16:40 Uhr schrieb Benjamin Marwell <
bmarw...@apache.org>:
> Hi,
>
> We solved 12 issues:
> https://issues.apache.org/jira/projects/MJLINK/versions/12349376
>
> The
Hi Anders,
those are outdated – not everything you need is included, at least for
IntelliJ.
YMMV when using those.
There is a lot which could be done.
E.g. updating those files, some general code guidelines (like: do not use
guard statements, rather use an else), etc., when (not) to use
Hi Andrey,
Robert suggested this list, which is automatically updated:
https://cwiki.apache.org/confluence/display/MAVEN/Maven+JIRA+issues+overview
The following link leads to a list which are marked
with labels like "beginner", "easyfix", etc.
and are maven-related projects:
onfigure
> toolchains on my side and afterwards the IT's can be executed... I doubt
> that toolchains is configured on CI??
>
>
> I think we need to reconsider the usage of toolchains within an invoker
> test or the support for toolchains in invoker... furthermore the
> question
Hi,
We solved 12 issues:
https://issues.apache.org/jira/projects/MJLINK/versions/12349376
There are three issues left in JIRA:
have permissions
Regards,
Hervé
Le mardi 15 décembre 2020, 22:37:21 CET Benjamin Marwell a écrit :
Hello everyone,
looking at the issues already solved and soon-be-solved, the next release
feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1].
If you agree, I would like
: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Tue, Dec 15, 2020 at 10:38 PM Benjamin Marwell
wrote:
Hello everyone,
looking at the issues already solved and soon-be-solved, the next release
feels much more like a 3.1.0 release
Hello everyone,
looking at the issues already solved and soon-be-solved, the next release
feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1].
If you agree, I would like to update the git repository to 3.1.0 and create
a 3.0.x branch from the last release, if needed.
I would
cholte <
rfscho...@apache.org>:
> I'm pretty sure this can be solved without touching the maven startup
> scripts.
> And I don't like the idea to hack the script because one plugin has issues.
> I expect good help on your question on the jigsaw mailinglist.
>
> Robert
> On 14-1
we could solve it in a maven release 3.6.4 if you wished, or the next
compiler plugin as soon as the next plexus javac dependency is available.
I wouldn't mind a 3.6.4 release and cherry picking the change to 4.0.0, as
that would be a quick solution.
On Sun, 13 Dec 2020, 17:12 Benjamin Marw
JIRA issue (please kindly review):
https://issues.apache.org/jira/browse/MCOMPILER-445
Am So., 13. Dez. 2020 um 14:07 Uhr schrieb Benjamin Marwell <
bmarw...@apache.org>:
> > If is has proven itself for jlink, then we know we can do the same for
> all other tools.
>
; know we can do the same for all other tools.
> If we have a good feeling about the implementation, we could use it at
> reference for other plugins as some kind of pattern.
>
> Robert
> On 13-12-2020 11:39:02, Benjamin Marwell wrote:
> Robert already suggested to use ToolProvi
Robert already suggested to use ToolProvider for the JDK9+ builds. I
created such a patch for jlink and I could create s similar one for the
compiler and javadoc plugin. This would solve the underlying problem from
my understanding.
As fork mode and fork count would not apply, I would suggest
Hello everyone,
MJLINK-PR19 [1] removes some plexus imports.
In the PR discussion the idea came up to add an enforcer rule to this
or even other plugins which forbids imports, e.g. to plexus.
There is also a weaker version, the forbidden-api checker [2] can
check for specific method calls, e.g.
Now changing to -1 as this will fail on Java 8 + toolchain, but the site
does not mention this.
This is clearly visible from the integration test I added in PR 16.
On Wed, 18 Nov 2020, 21:59 Robert Scholte, wrote:
> +1
>
> On 11-11-2020 23:14:51, Karl Heinz Marbaise wrote:
> Hi,
>
> We
Hello Karl Heinz,
I am chaning my vote to 0 (neutral / non binding).
Reason: I wrote an integration test which uses JDK8 and a Toolchain.
There seems to be a clash of asm dependencies. As using maven with
JDK/JRE8 and a toolchain is unlikely, I will stand neutral here.
The cause is being
Hi everyone,
In the Apache Shiro project I was able to fix a few issues which only
occured on the OpenJ9 VM.
The OpenJ9 VM is the only big Java VM implementation next to hotspot.
All other VMs (or most other relevant VMs) are hotspot forks.
This is the only VM that actually differs from the
3.0.0? This is the first release, so 1.0.0 feels right.
>
> On Fri, Nov 13, 2020 at 4:45 PM Benjamin Marwell wrote:
> >
> > +1 (non-binding)
> >
> > On 2020/11/11 22:14:35, Karl Heinz Marbaise wrote:
> > > Hi,
> > >
> > > We solved 37 issues:
> &g
+1 (non-binding)
On 2020/11/11 22:14:35, Karl Heinz Marbaise wrote:
> Hi,
>
> We solved 37 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321432=12343851
>
> There are still a couple of issues left in JIRA:
>
Hello,
there are currently two PRs for the maven-jlink-plugin.
One removes support for junit4.
Another one removes support for junit5.
On both PRs are discussions with valid points for one or the other.
The best one (in my opinion as a contributor) would be to "ask the
community first" if a
Hi,
PRs #17 and #28 seem to be ready to be merged. They are also approved
by reviewers.
If they still look good, could they be merged? They are open for a while now.
* https://github.com/apache/maven-checkstyle-plugin/pull/17
* https://github.com/apache/maven-checkstyle-plugin/pull/28
Thanks!
Hi,
to make the story a bit shorter - for most libraries it would be
sufficient to add a way to include a module descriptor at
"META-INF/versions/9/module-info.class" while still staying at java 8.
Most libraries will stick to java 8 or even 7 for quite a time.
Sadly, you cannot just add
Checkstyle builds will fail of there is more than one commit in a PR.
Not saying I like it, but it's an option.
On Sat, 21 Mar 2020, 16:17 Elliotte Rusty Harold,
wrote:
> So it appears that if I do all squashing and merging locally and then
> push directly to master, I get listed as
Hi,
might someone please explain why catching a NoSuchMethodError at runtime
does not work and we did not see this coming?
In my understanding the old 8.29 checkstyle version should only be a
compile dependency, but not a runtime dependency.
And the patch even was approved by two or three of
STYLE-387] emit a warning when using an old version of checkstyle"
New PR to fix task
https://issues.apache.org/jira/projects/MCHECKSTYLE/issues/MCHECKSTYLE-387
Thanks and best regards,
Benjamin Marwell
-
To unsubscribe,
In the hope that the approved PRs get merged soon,
+1 (non-binding).
I'd be happy to contribute more afterwards.
Am Di., 11. Feb. 2020 um 13:47 Uhr schrieb Enrico Olivelli
:
>
> Thank you Hervé
>
> I need two more binding +1 please
>
> Enrico
>
> Il Sab 8 Feb 2020, 21:43 Hervé BOUTEMY ha
For most users this is the line length check.
Other than that, there is an issue on the bug tracker for this. Please
close it after merging.
On Thu, 6 Feb 2020, 16:02 Elliotte Rusty Harold, wrote:
> From that bug it looks like the incompatibilities might be more subtle
> than a complete
Hi,
someone just found out that some former codehaus projects are abandoned
nowadays.
Are there any plans to make them an Apache Project? I guess there probably
must have been a discussion on this list, but I haven't found any.
Recent example:
There are cases where profiles must steer the build output though, although
they are rare.
For example, look at lmdb-native on GitHub. lmdb uses lots of native
methods. As they are building the jars containing the .so files from the
very same sources, they control the ci using profiles (Jenkins
>
> > >
> > > Il dom 12 gen 2020, 08:35 Enrico Olivelli ha
> > > scritto:
> > >
> > >> Ben
> > >> It is a good idea.
> > >>
> > >> Any volunteer?
> > >>
> > >> Enrico
> > >>
>
Hi everyone,
since the classloader issue is resolved in the master branch, I'd like
to suggest a release before merging the violation class PR.
The sooner the better (for the checkstyle team anyway).
Thanks,
Ben
-
To
Hi,
thanks for sharing your idea. While I can see the benefits, I also do see
some drawbacks.
If only one part of the plugin has an invalid state, it will be impossible
to create a release.
Also, the Unix philosophy (make a tool which does one thing well) would be
broken.
If voting is a
Dear list members,
there are currently unmerged PRs for the checkstyle plugin:
https://github.com/apache/maven-checkstyle-plugin/pulls
Some of them seem to be no-brainers (readme-/pom-url-/site-updates),
others have been discussed exhaustively.
How do I/we get them merged? I know that Robert
Can't wait to see it integrated, as I will add another PR based on the
previous one to emit a message and deprecate that new method.
Do I need to do something to have the PR merged?
On Sun, 29 Dec 2019, 17:38 Enrico Olivelli, wrote:
> Il dom 29 dic 2019, 16:02 Benjamin Marwell ha
> s
Romain Manni-Bucau,
wrote:
> Le lun. 23 déc. 2019 à 17:51, Benjamin Marwell a
> écrit :
>
> > Sounds good to me.
> >
> > A new major is not needed for my PR, but needed for future versions of
> > checkstyle. Depends on how fast they actually remove that method.
&
gt;
>
> Le lun. 23 déc. 2019 à 16:44, Benjamin Marwell a
> écrit :
>
> > Furthermore,
> >
> > if we do not drop using that method, maven will throw an exception. Maven
> > will, not checkstyle.
> >
> > I do not think that should be ha
omain Manni-Bucau <
> rmannibu...@gmail.com>:
> >>
> >> Point is it is the only way to not break end user since it gives us the
> >> control of which version to select depending user config and java
> version.
> >> Which we dont ask any change to user im fi
schrieb Romain Manni-Bucau
> > >:
> > >
> > > Point is it is the only way to not break end user since it gives us the
> > > control of which version to select depending user config and java
> > version.
> > > Which we dont ask any change to user im
23 déc. 2019 à 09:27, Benjamin Marwell a
> écrit :
>
> > Hi Enrico,
> >
> > that would mean a lot of incompatibilities which I wanted to avoid.
> > If the checkstyle jar is updated first (8.xx), maven users wouldn't be
> able
> > to use a current versi
would be that you (or anyone from Checkstyle) create a PR when
> you are ready with the new release.
>
> I will be happy to help you move forward with this change and cut a release
>
> Cheers
> Enrico
>
> Il lun 23 dic 2019, 07:21 Benjamin Marwell ha
> scritto:
>
&g
Hi all,
The checkstyle team is waiting for my PR:
https://github.com/apache/maven-checkstyle-plugin/pull/18
The problem is, that they want to remove a method. If they do this too
early, maven users will not be able to update the checkstyle version
anymore.
Also, the maven Checkstyle plugin
,
wrote:
> Hi, Ben,
>
> afaict, the issue *is* closed.
>
> Jochen
>
> On Sat, Dec 14, 2019 at 6:09 PM Benjamin Marwell
> wrote:
> >
> > Hi all,
> >
> > I think issue this can be closed:
> >https://issues.apache.org/jira/browse/MCHECKSTYL
Hi all,
I just tried to implement MENFORCER-288 to see how far I could get.
As it turned out, the task is not trivial, because you'd have to parse and
correctly rewrite a version range. See details in the comments on
MENFORCER-288.
Because of this, I don't think the recommendation to use
Hi all,
I think issue this can be closed:
https://issues.apache.org/jira/browse/MCHECKSTYLE-373
The original author is just asking for how to specify a property via
command line.
Best regards,
Ben
-
To unsubscribe, e-mail:
I do know companies who still use 3.2.3 and they don't dare to update
because of a misconfiguration.
Should we care? Or perhaps they should have bought support contracts
for such use cases?
If we say "support the 3.6 branch fur such amount of time" it also
means reacting to vulnerabilities in
arbaise
> On 14.12.19 12:29, Benjamin Marwell wrote:
> > Dear devs,
> >
> > I am positive that
> > https://issues.apache.org/jira/browse/MCHECKSTYLE-378 can be closed.
> > The user tried to use a configuration for the wrong goal, see comment.
>
Dear devs,
I am positive that
https://issues.apache.org/jira/browse/MCHECKSTYLE-378 can be closed.
The user tried to use a configuration for the wrong goal, see comment.
Proposed resolution: Not a bug.
Thanks,
Ben
-
To
Hello all,
I just checked
https://issues.apache.org/jira/projects/MCHECKSTYLE/issues/MCHECKSTYLE-138.
I am positive that this issue has been resolved for a long time now
and can be closed.
--
Also, I have three open pull requests at the moment (for the
checkstyle plugin). If you'd like me to
Hello,
the issue https://issues.apache.org/jira/browse/MCHECKSTYLE-383 can be
closed if I read it correctly. I think the issue reporter meant to
report this issue over at
https://github.com/checkstyle/checkstyle/issues.
Ben
-
ss there better for such task.
> Feel free to tag me @eolivelli
>
> Cheers
> Enrico
>
> Il mer 11 dic 2019, 17:19 Benjamin Marwell ha scritto:
>
> > Hi all,
> >
> > I'm new to this list and have contributed a single commit to CXF so far and
> > would lik
Hi all,
I'm new to this list and have contributed a single commit to CXF so far and
would like to start committing on other apache maven projects as well.
I'm this case:
https://issues.apache.org/jira/browse/MCHECKSTYLE-356
While I think this issue is really not that important, it seems to be a
101 - 171 of 171 matches
Mail list logo
