[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[ https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800119#comment-17800119 ] ASF GitHub Bot commented on DOXIA-711: -- michael-o commented on code in PR #184: URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435721892 ## doxia-core/src/main/java/org/apache/maven/doxia/parser/SinkWrapper.java: ## Review Comment: > Should we move this to another package? Maybe `o.a.m.doxia.sink.impl` is better, but this is clearly no impl details but rather class to be reused among doxia modules and potentially other consumers. Usually `impl` packages are used for packages which should not be reused outside the current JAR. So maybe `o.a.m.doxia.sink` is better, OTOH all other classes in `o.a.m.doxia.sink.impl` are probably not belonging to an impl package either, as all of them are reused. WDYT @michael-o? I agree with you completely. Only interfaced and package private stuff belongs here. Abstract ones and reusables don't. Though, since the rest is here and we cannot move them, I'd go with the compromise and put in into `impl` to make it consistently weird > Introduce SinkWrapper with factory > -- > > Key: DOXIA-711 > URL: https://issues.apache.org/jira/browse/DOXIA-711 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M9 > > > Similar to HttpServletRequestWrapper in Servlet API one should have a > SinkWrapper helper for Doxia. That allows to easily implement some > post/preprocessing and even modifying or skipping the underlying sink. All > Sink wrappers and the original sink should form a pipeline. > Registering a SinkWrapper should optionally be done automatically (via JSR330 > annotations) or manually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
michael-o commented on code in PR #184: URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435721892 ## doxia-core/src/main/java/org/apache/maven/doxia/parser/SinkWrapper.java: ## Review Comment: > Should we move this to another package? Maybe `o.a.m.doxia.sink.impl` is better, but this is clearly no impl details but rather class to be reused among doxia modules and potentially other consumers. Usually `impl` packages are used for packages which should not be reused outside the current JAR. So maybe `o.a.m.doxia.sink` is better, OTOH all other classes in `o.a.m.doxia.sink.impl` are probably not belonging to an impl package either, as all of them are reused. WDYT @michael-o? I agree with you completely. Only interfaced and package private stuff belongs here. Abstract ones and reusables don't. Though, since the rest is here and we cannot move them, I'd go with the compromise and put in into `impl` to make it consistently weird -- at least. -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[
https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800117#comment-17800117
]
ASF GitHub Bot commented on DOXIA-711:
--
kwin commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435720203
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/BufferingSinkProxyFactory.java:
##
@@ -0,0 +1,112 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.lang.reflect.Proxy;
+import java.util.LinkedList;
+import java.util.Queue;
+
+import org.apache.maven.doxia.sink.Sink;
+
+/**
+ * Buffers all method calls on the wrapped Sink until the proxy sink's method
{@link Sink#flush()} is called.
Review Comment:
Rewritten in
https://github.com/apache/maven-doxia/pull/184/commits/2695cb63c7b638f5a01c961f320c5a785eb192b3
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/RandomAccessSink.java:
##
@@ -27,19 +27,21 @@
import java.util.List;
import org.apache.maven.doxia.sink.Sink;
-import org.apache.maven.doxia.sink.SinkEventAttributes;
import org.apache.maven.doxia.sink.SinkFactory;
/**
* The RandomAccessSink provides the ability to create a {@link Sink} with
hooks.
* A page can be prepared by first creating its structure and specifying the
positions of these hooks.
* After specifying the structure, the page can be filled with content from
one or more models.
* These hooks can prevent you to have to loop over the model multiple times
to build the page as desired.
- *
+ * Consider using the {@link BufferingSinkProxyFactory} instead which allows
to buffer on the (higher) Sink API level
Review Comment:
Ok, deprecated it in
https://github.com/apache/maven-doxia/pull/184/commits/2695cb63c7b638f5a01c961f320c5a785eb192b3.
> Introduce SinkWrapper with factory
> --
>
> Key: DOXIA-711
> URL: https://issues.apache.org/jira/browse/DOXIA-711
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0-M9
>
>
> Similar to HttpServletRequestWrapper in Servlet API one should have a
> SinkWrapper helper for Doxia. That allows to easily implement some
> post/preprocessing and even modifying or skipping the underlying sink. All
> Sink wrappers and the original sink should form a pipeline.
> Registering a SinkWrapper should optionally be done automatically (via JSR330
> annotations) or manually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[
https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800118#comment-17800118
]
ASF GitHub Bot commented on DOXIA-711:
--
kwin commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435720272
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/PipelineSink.java:
##
@@ -28,8 +28,10 @@
/**
* May be used to invoke the same method on a List of Sinks.
+ * Consider using the more flexible {@link SinkWrapper} approach which doesn't
require the use of dynamic proxies.
Review Comment:
Deprecated in
https://github.com/apache/maven-doxia/pull/184/commits/2695cb63c7b638f5a01c961f320c5a785eb192b3.
> Introduce SinkWrapper with factory
> --
>
> Key: DOXIA-711
> URL: https://issues.apache.org/jira/browse/DOXIA-711
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0-M9
>
>
> Similar to HttpServletRequestWrapper in Servlet API one should have a
> SinkWrapper helper for Doxia. That allows to easily implement some
> post/preprocessing and even modifying or skipping the underlying sink. All
> Sink wrappers and the original sink should form a pipeline.
> Registering a SinkWrapper should optionally be done automatically (via JSR330
> annotations) or manually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
kwin commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435720272
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/PipelineSink.java:
##
@@ -28,8 +28,10 @@
/**
* May be used to invoke the same method on a List of Sinks.
+ * Consider using the more flexible {@link SinkWrapper} approach which doesn't
require the use of dynamic proxies.
Review Comment:
Deprecated in
https://github.com/apache/maven-doxia/pull/184/commits/2695cb63c7b638f5a01c961f320c5a785eb192b3.
--
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 comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
kwin commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435720203
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/BufferingSinkProxyFactory.java:
##
@@ -0,0 +1,112 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.lang.reflect.Proxy;
+import java.util.LinkedList;
+import java.util.Queue;
+
+import org.apache.maven.doxia.sink.Sink;
+
+/**
+ * Buffers all method calls on the wrapped Sink until the proxy sink's method
{@link Sink#flush()} is called.
Review Comment:
Rewritten in
https://github.com/apache/maven-doxia/pull/184/commits/2695cb63c7b638f5a01c961f320c5a785eb192b3
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/RandomAccessSink.java:
##
@@ -27,19 +27,21 @@
import java.util.List;
import org.apache.maven.doxia.sink.Sink;
-import org.apache.maven.doxia.sink.SinkEventAttributes;
import org.apache.maven.doxia.sink.SinkFactory;
/**
* The RandomAccessSink provides the ability to create a {@link Sink} with
hooks.
* A page can be prepared by first creating its structure and specifying the
positions of these hooks.
* After specifying the structure, the page can be filled with content from
one or more models.
* These hooks can prevent you to have to loop over the model multiple times
to build the page as desired.
- *
+ * Consider using the {@link BufferingSinkProxyFactory} instead which allows
to buffer on the (higher) Sink API level
Review Comment:
Ok, deprecated it in
https://github.com/apache/maven-doxia/pull/184/commits/2695cb63c7b638f5a01c961f320c5a785eb192b3.
--
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 comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[
https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800116#comment-17800116
]
ASF GitHub Bot commented on DOXIA-711:
--
kwin commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435720047
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/BufferingSinkProxyFactory.java:
##
@@ -0,0 +1,112 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.lang.reflect.Proxy;
+import java.util.LinkedList;
+import java.util.Queue;
+
+import org.apache.maven.doxia.sink.Sink;
+
+/**
+ * Buffers all method calls on the wrapped Sink until the proxy sink's method
{@link Sink#flush()} is called.
+ */
+public class BufferingSinkProxyFactory implements SinkWrapperFactory {
+
+private static final class MethodWithArguments {
+private final Method method;
+private final Object[] args;
+
+MethodWithArguments(Method method, Object[] args) {
+super();
+this.method = method;
+this.args = args;
+}
+
+void invoke(Object object) {
+try {
+method.invoke(object, args);
+} catch (IllegalAccessException | IllegalArgumentException |
InvocationTargetException e) {
+throw new IllegalStateException("Could not call buffered
method " + method, e);
+}
+}
+}
+
+public interface BufferingSink extends Sink {
+// just a marker interface
+Sink getBufferedSink();
+}
+
+private static final class BufferingSinkProxy implements InvocationHandler
{
+private final Queue bufferedInvocations;
+private final Sink delegate;
+private static final Method FLUSH_METHOD;
+private static final Method GET_BUFFERED_SINK_METHOD;
+
+static {
+try {
+FLUSH_METHOD = Sink.class.getMethod("flush");
+GET_BUFFERED_SINK_METHOD =
BufferingSink.class.getMethod("getBufferedSink");
+} catch (NoSuchMethodException | SecurityException e) {
+throw new IllegalStateException("Could not find flush method
in Sink!", e);
+}
+}
+
+BufferingSinkProxy(Sink delegate) {
+bufferedInvocations = new LinkedList<>();
+this.delegate = delegate;
+}
+
+@Override
+public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
+if (method.equals(FLUSH_METHOD)) {
+bufferedInvocations.forEach(i -> i.invoke(delegate));
+bufferedInvocations.clear();
+} else if (method.equals(GET_BUFFERED_SINK_METHOD)) {
+return delegate;
+} else {
+bufferedInvocations.add(new MethodWithArguments(method, args));
+}
+return null;
+}
+}
+
+@Override
+public Sink createWrapper(Sink delegate) {
+BufferingSinkProxy proxy = new BufferingSinkProxy(delegate);
+return (Sink) Proxy.newProxyInstance(
+delegate.getClass().getClassLoader(), new Class[]
{BufferingSink.class}, proxy);
+}
+
+public static BufferingSink castAsBufferingSink(Sink sink) {
+if (sink instanceof BufferingSink) {
+return (BufferingSink) sink;
+} else {
+throw new IllegalArgumentException("The given sink is no
BufferingSink but a " + sink.getClass());
Review Comment:
Done
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/SinkWrapperFactoryComparator.java:
##
@@ -0,0 +1,31 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ *
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
kwin commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435720047
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/BufferingSinkProxyFactory.java:
##
@@ -0,0 +1,112 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.lang.reflect.Proxy;
+import java.util.LinkedList;
+import java.util.Queue;
+
+import org.apache.maven.doxia.sink.Sink;
+
+/**
+ * Buffers all method calls on the wrapped Sink until the proxy sink's method
{@link Sink#flush()} is called.
+ */
+public class BufferingSinkProxyFactory implements SinkWrapperFactory {
+
+private static final class MethodWithArguments {
+private final Method method;
+private final Object[] args;
+
+MethodWithArguments(Method method, Object[] args) {
+super();
+this.method = method;
+this.args = args;
+}
+
+void invoke(Object object) {
+try {
+method.invoke(object, args);
+} catch (IllegalAccessException | IllegalArgumentException |
InvocationTargetException e) {
+throw new IllegalStateException("Could not call buffered
method " + method, e);
+}
+}
+}
+
+public interface BufferingSink extends Sink {
+// just a marker interface
+Sink getBufferedSink();
+}
+
+private static final class BufferingSinkProxy implements InvocationHandler
{
+private final Queue bufferedInvocations;
+private final Sink delegate;
+private static final Method FLUSH_METHOD;
+private static final Method GET_BUFFERED_SINK_METHOD;
+
+static {
+try {
+FLUSH_METHOD = Sink.class.getMethod("flush");
+GET_BUFFERED_SINK_METHOD =
BufferingSink.class.getMethod("getBufferedSink");
+} catch (NoSuchMethodException | SecurityException e) {
+throw new IllegalStateException("Could not find flush method
in Sink!", e);
+}
+}
+
+BufferingSinkProxy(Sink delegate) {
+bufferedInvocations = new LinkedList<>();
+this.delegate = delegate;
+}
+
+@Override
+public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
+if (method.equals(FLUSH_METHOD)) {
+bufferedInvocations.forEach(i -> i.invoke(delegate));
+bufferedInvocations.clear();
+} else if (method.equals(GET_BUFFERED_SINK_METHOD)) {
+return delegate;
+} else {
+bufferedInvocations.add(new MethodWithArguments(method, args));
+}
+return null;
+}
+}
+
+@Override
+public Sink createWrapper(Sink delegate) {
+BufferingSinkProxy proxy = new BufferingSinkProxy(delegate);
+return (Sink) Proxy.newProxyInstance(
+delegate.getClass().getClassLoader(), new Class[]
{BufferingSink.class}, proxy);
+}
+
+public static BufferingSink castAsBufferingSink(Sink sink) {
+if (sink instanceof BufferingSink) {
+return (BufferingSink) sink;
+} else {
+throw new IllegalArgumentException("The given sink is no
BufferingSink but a " + sink.getClass());
Review Comment:
Done
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/SinkWrapperFactoryComparator.java:
##
@@ -0,0 +1,31 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[
https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800115#comment-17800115
]
ASF GitHub Bot commented on DOXIA-711:
--
michael-o commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435719871
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/BufferingSinkProxyFactory.java:
##
@@ -0,0 +1,112 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.lang.reflect.Proxy;
+import java.util.LinkedList;
+import java.util.Queue;
+
+import org.apache.maven.doxia.sink.Sink;
+
+/**
+ * Buffers all method calls on the wrapped Sink until the proxy sink's method
{@link Sink#flush()} is called.
+ */
+public class BufferingSinkProxyFactory implements SinkWrapperFactory {
+
+private static final class MethodWithArguments {
+private final Method method;
+private final Object[] args;
+
+MethodWithArguments(Method method, Object[] args) {
+super();
+this.method = method;
+this.args = args;
+}
+
+void invoke(Object object) {
+try {
+method.invoke(object, args);
+} catch (IllegalAccessException | IllegalArgumentException |
InvocationTargetException e) {
+throw new IllegalStateException("Could not call buffered
method " + method, e);
+}
Review Comment:
Right, thanks.
> Introduce SinkWrapper with factory
> --
>
> Key: DOXIA-711
> URL: https://issues.apache.org/jira/browse/DOXIA-711
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0-M9
>
>
> Similar to HttpServletRequestWrapper in Servlet API one should have a
> SinkWrapper helper for Doxia. That allows to easily implement some
> post/preprocessing and even modifying or skipping the underlying sink. All
> Sink wrappers and the original sink should form a pipeline.
> Registering a SinkWrapper should optionally be done automatically (via JSR330
> annotations) or manually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
michael-o commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435719871
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/BufferingSinkProxyFactory.java:
##
@@ -0,0 +1,112 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.lang.reflect.Proxy;
+import java.util.LinkedList;
+import java.util.Queue;
+
+import org.apache.maven.doxia.sink.Sink;
+
+/**
+ * Buffers all method calls on the wrapped Sink until the proxy sink's method
{@link Sink#flush()} is called.
+ */
+public class BufferingSinkProxyFactory implements SinkWrapperFactory {
+
+private static final class MethodWithArguments {
+private final Method method;
+private final Object[] args;
+
+MethodWithArguments(Method method, Object[] args) {
+super();
+this.method = method;
+this.args = args;
+}
+
+void invoke(Object object) {
+try {
+method.invoke(object, args);
+} catch (IllegalAccessException | IllegalArgumentException |
InvocationTargetException e) {
+throw new IllegalStateException("Could not call buffered
method " + method, e);
+}
Review Comment:
Right, thanks.
--
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 comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[
https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800114#comment-17800114
]
ASF GitHub Bot commented on DOXIA-711:
--
kwin commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435718876
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/BufferingSinkProxyFactory.java:
##
@@ -0,0 +1,112 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.lang.reflect.Proxy;
+import java.util.LinkedList;
+import java.util.Queue;
+
+import org.apache.maven.doxia.sink.Sink;
+
+/**
+ * Buffers all method calls on the wrapped Sink until the proxy sink's method
{@link Sink#flush()} is called.
+ */
+public class BufferingSinkProxyFactory implements SinkWrapperFactory {
+
+private static final class MethodWithArguments {
+private final Method method;
+private final Object[] args;
+
+MethodWithArguments(Method method, Object[] args) {
+super();
+this.method = method;
+this.args = args;
+}
+
+void invoke(Object object) {
+try {
+method.invoke(object, args);
+} catch (IllegalAccessException | IllegalArgumentException |
InvocationTargetException e) {
+throw new IllegalStateException("Could not call buffered
method " + method, e);
+}
Review Comment:
According to https://stackoverflow.com/a/1856285/5155923 it should be
neglectable in this case.
> Introduce SinkWrapper with factory
> --
>
> Key: DOXIA-711
> URL: https://issues.apache.org/jira/browse/DOXIA-711
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0-M9
>
>
> Similar to HttpServletRequestWrapper in Servlet API one should have a
> SinkWrapper helper for Doxia. That allows to easily implement some
> post/preprocessing and even modifying or skipping the underlying sink. All
> Sink wrappers and the original sink should form a pipeline.
> Registering a SinkWrapper should optionally be done automatically (via JSR330
> annotations) or manually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
kwin commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435718876
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/BufferingSinkProxyFactory.java:
##
@@ -0,0 +1,112 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.lang.reflect.Proxy;
+import java.util.LinkedList;
+import java.util.Queue;
+
+import org.apache.maven.doxia.sink.Sink;
+
+/**
+ * Buffers all method calls on the wrapped Sink until the proxy sink's method
{@link Sink#flush()} is called.
+ */
+public class BufferingSinkProxyFactory implements SinkWrapperFactory {
+
+private static final class MethodWithArguments {
+private final Method method;
+private final Object[] args;
+
+MethodWithArguments(Method method, Object[] args) {
+super();
+this.method = method;
+this.args = args;
+}
+
+void invoke(Object object) {
+try {
+method.invoke(object, args);
+} catch (IllegalAccessException | IllegalArgumentException |
InvocationTargetException e) {
+throw new IllegalStateException("Could not call buffered
method " + method, e);
+}
Review Comment:
According to https://stackoverflow.com/a/1856285/5155923 it should be
neglectable in this case.
--
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 comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1744) Enable system-out for successfuly passed tests as well
[
https://issues.apache.org/jira/browse/SUREFIRE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800113#comment-17800113
]
Michael Osipov commented on SUREFIRE-1744:
--
For all those who suffer, please follow and comment on
https://github.com/apache/maven-surefire/pull/670.
> Enable system-out for successfuly passed tests as well
> --
>
> Key: SUREFIRE-1744
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1744
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Reporter: Klevis Ramo
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
> Attachments: image-2020-01-09-16-03-07-261.png,
> image-2020-01-09-16-04-11-142.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Situation*
> Currently logs during tests execution are exported to *.xml report only for
> failed tests.
> The xsd schema also implies the
> same(surefire-test-report-3.0.xsd,legacy-surefire-test-report.xsd) ,
> *system-out* elment is always a child of
> failure,rerunFailure,flakyFailure,rerunError or flakyError element.
> Some part of the code(*createOutErrElements adds the system-out*) :
> {code:java}
> StatelessXmlReporter
>
> private void serializeTestClassWithoutRerun( OutputStream outputStream,
> OutputStreamWriter fw, XMLWriter ppw,
> List
> methodEntries )
> {
> for ( WrappedReportEntry methodEntry : methodEntries )
> {
> startTestElement( ppw, methodEntry );
> if ( methodEntry.getReportEntryType() != SUCCESS )
> {
> getTestProblems( fw, ppw, methodEntry, trimStackTrace,
> outputStream,
> methodEntry.getReportEntryType().getXmlTag(), false );
> createOutErrElements( fw, ppw, methodEntry, outputStream );
> }
> ppw.endElement();
> }
> }{code}
> *Problem*
> Because logs are not exported for successfully tests there is no way(outside
> IDE or complete log) one could nicely explore what a particular test is
> doing. This is hurting also the documentation part of a test.Imagine those
> tests are used as end to end tests and business analysts would like to review
> through CI tools like jenkins.
>
> *Possible Solution*
> Enable maven sure fire plugin to export logs to system-out also for
> succefully passed tests through an optional parameter leaving the default
> behaviour as it is right now(only failed tests have outputs exported). This
> means of course also enchancing the xsd to support system-out to different
> parent rather then only failed ones.
>
> Since it happens I am also a developer I can of course help with the feature
> implementation if you find this something that makes sense.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1934) Ability to disable system-out/system-err for successfuly passed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800112#comment-17800112 ] ASF GitHub Bot commented on SUREFIRE-1934: -- michael-o commented on PR #670: URL: https://github.com/apache/maven-surefire/pull/670#issuecomment-1868376997 I have now re-read the code and your change. I fail to see how this change only applies to successful tests. It applies to *all* type of results: `SUCCESS` and non-`SUCCESS` otherwise you wouldn't modify `#getTestProblems()`, no? This is no not necessarily wrong, but inconsistent with your description. See the original change: https://github.com/apache/maven-surefire/commit/b80325616daa323eb71a04a61d7485a1d303230c#diff-c634b539151b4b76bde50d93d5a6cd2b0f51aa411281398cc295cc721bdfa1d5 > Ability to disable system-out/system-err for successfuly passed tests > - > > Key: SUREFIRE-1934 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1934 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M5 >Reporter: Andrey Turbanov >Priority: Major > > After SUREFIRE-1744 surefire-plugin always reports system-out/system-err even > for successfully passed test. A lot of old projects with big amount of tests > now have to deal with huge output. > I think there should be option to disable new behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-1934] Ability to disable system-out/system-err for successfuly passed tests. [maven-surefire]
michael-o commented on PR #670: URL: https://github.com/apache/maven-surefire/pull/670#issuecomment-1868376997 I have now re-read the code and your change. I fail to see how this change only applies to successful tests. It applies to *all* type of results: `SUCCESS` and non-`SUCCESS` otherwise you wouldn't modify `#getTestProblems()`, no? This is no not necessarily wrong, but inconsistent with your description. See the original change: https://github.com/apache/maven-surefire/commit/b80325616daa323eb71a04a61d7485a1d303230c#diff-c634b539151b4b76bde50d93d5a6cd2b0f51aa411281398cc295cc721bdfa1d5 -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] User uppercase convention for enum member names [maven-surefire]
michael-o commented on PR #704: URL: https://github.com/apache/maven-surefire/pull/704#issuecomment-1868376091 No functional change here... -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] User uppercase convention for enum member names [maven-surefire]
michael-o opened a new pull request, #704: URL: https://github.com/apache/maven-surefire/pull/704 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (SUREFIRE-2223) Surefire evaluates parameter jvm before skip
[
https://issues.apache.org/jira/browse/SUREFIRE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SUREFIRE-2223.
Resolution: Fixed
Fixed with
[c006d8eea6cc77df511abdd6508e732485688de8|https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=c006d8eea6cc77df511abdd6508e732485688de8].
> Surefire evaluates parameter jvm before skip
>
>
> Key: SUREFIRE-2223
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2223
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Reporter: shpelda
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.4
>
>
> Surefire 3.2.3 execution configured like the one bellow will fail if
> JAVA_11_HOME is not set.
> It is a regression, 2.17 version did correctly resolved skip(Tests) and
> later, if enabled, it evaluated jvm.
> {code:java}
>
> h2-java11
>
> test
>
>
> ${JAVA_11_HOME}/bin/java
> true
>
>
> fails with
> {code}
> Caused by: org.apache.maven.plugin.MojoFailureException: Given path to java
> executor does not exist "c:\XXX\${JAVA_11_HOME}\bin\java".
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveJvm
> (AbstractSurefireMojo.java:2374)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
> (AbstractSurefireMojo.java:882)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> 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)
> {code:java}
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2223) Surefire evaluates parameter jvm before skip
[
https://issues.apache.org/jira/browse/SUREFIRE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800110#comment-17800110
]
ASF GitHub Bot commented on SUREFIRE-2223:
--
asfgit merged PR #703:
URL: https://github.com/apache/maven-surefire/pull/703
> Surefire evaluates parameter jvm before skip
>
>
> Key: SUREFIRE-2223
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2223
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Reporter: shpelda
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.4
>
>
> Surefire 3.2.3 execution configured like the one bellow will fail if
> JAVA_11_HOME is not set.
> It is a regression, 2.17 version did correctly resolved skip(Tests) and
> later, if enabled, it evaluated jvm.
> {code:java}
>
> h2-java11
>
> test
>
>
> ${JAVA_11_HOME}/bin/java
> true
>
>
> fails with
> {code}
> Caused by: org.apache.maven.plugin.MojoFailureException: Given path to java
> executor does not exist "c:\XXX\${JAVA_11_HOME}\bin\java".
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveJvm
> (AbstractSurefireMojo.java:2374)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
> (AbstractSurefireMojo.java:882)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> 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)
> {code:java}
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-2223] Surefire evaluates parameter jvm before skip [maven-surefire]
asfgit merged PR #703: URL: https://github.com/apache/maven-surefire/pull/703 -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Switch to JLine to provide line editing [maven]
gnodet commented on PR #1279: URL: https://github.com/apache/maven/pull/1279#issuecomment-1868371504 > > eg. > > ``` > > mvn buildplan:list-phase > > ``` > > It works when using a terminal. However, when the output is redirected to a file, the ansi sequences are not stripped correctly when using the `org.apache.maven.shared.logging.MessageUtils`. The reason is that the ansi sequences are currently stripped inside the `System.out` and `System.err` streams. So I'll postpone this change until [jline/jline3#871](https://github.com/jline/jline3/pull/871) is done and released. I've upgrade to latest JLine, which now includes Jansi. The integration with maven-shared-utils works correctly now. -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[ https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800107#comment-17800107 ] ASF GitHub Bot commented on DOXIA-711: -- michael-o commented on code in PR #184: URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435695159 ## doxia-core/src/main/java/org/apache/maven/doxia/parser/SinkWrapper.java: ## Review Comment: I need to think about this... > Introduce SinkWrapper with factory > -- > > Key: DOXIA-711 > URL: https://issues.apache.org/jira/browse/DOXIA-711 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M9 > > > Similar to HttpServletRequestWrapper in Servlet API one should have a > SinkWrapper helper for Doxia. That allows to easily implement some > post/preprocessing and even modifying or skipping the underlying sink. All > Sink wrappers and the original sink should form a pipeline. > Registering a SinkWrapper should optionally be done automatically (via JSR330 > annotations) or manually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[
https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800106#comment-17800106
]
ASF GitHub Bot commented on DOXIA-711:
--
michael-o commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435694330
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/BufferingSinkProxyFactory.java:
##
@@ -0,0 +1,112 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.lang.reflect.Proxy;
+import java.util.LinkedList;
+import java.util.Queue;
+
+import org.apache.maven.doxia.sink.Sink;
+
+/**
+ * Buffers all method calls on the wrapped Sink until the proxy sink's method
{@link Sink#flush()} is called.
+ */
+public class BufferingSinkProxyFactory implements SinkWrapperFactory {
+
+private static final class MethodWithArguments {
+private final Method method;
+private final Object[] args;
+
+MethodWithArguments(Method method, Object[] args) {
+super();
+this.method = method;
+this.args = args;
+}
+
+void invoke(Object object) {
+try {
+method.invoke(object, args);
+} catch (IllegalAccessException | IllegalArgumentException |
InvocationTargetException e) {
+throw new IllegalStateException("Could not call buffered
method " + method, e);
+}
Review Comment:
What is the computational overhead by using reflection? Ignorable?
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/SinkWrapperFactoryComparator.java:
##
@@ -0,0 +1,31 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.util.Comparator;
+
+/** Sorts the given {@link SinkWrapperFactory}s so that the one with the
highest rank comes first (i.e. order by descending ranking) */
Review Comment:
Didn't we agree on the term 'priority'?
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/PipelineSink.java:
##
@@ -28,8 +28,10 @@
/**
* May be used to invoke the same method on a List of Sinks.
+ * Consider using the more flexible {@link SinkWrapper} approach which doesn't
require the use of dynamic proxies.
Review Comment:
If you consider it better suited, I would trust your judgement here.
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/BufferingSinkProxyFactory.java:
##
@@ -0,0 +1,112 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
michael-o commented on code in PR #184: URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435695159 ## doxia-core/src/main/java/org/apache/maven/doxia/parser/SinkWrapper.java: ## Review Comment: I need to think about this... -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
michael-o commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435694330
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/BufferingSinkProxyFactory.java:
##
@@ -0,0 +1,112 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.lang.reflect.Proxy;
+import java.util.LinkedList;
+import java.util.Queue;
+
+import org.apache.maven.doxia.sink.Sink;
+
+/**
+ * Buffers all method calls on the wrapped Sink until the proxy sink's method
{@link Sink#flush()} is called.
+ */
+public class BufferingSinkProxyFactory implements SinkWrapperFactory {
+
+private static final class MethodWithArguments {
+private final Method method;
+private final Object[] args;
+
+MethodWithArguments(Method method, Object[] args) {
+super();
+this.method = method;
+this.args = args;
+}
+
+void invoke(Object object) {
+try {
+method.invoke(object, args);
+} catch (IllegalAccessException | IllegalArgumentException |
InvocationTargetException e) {
+throw new IllegalStateException("Could not call buffered
method " + method, e);
+}
Review Comment:
What is the computational overhead by using reflection? Ignorable?
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/SinkWrapperFactoryComparator.java:
##
@@ -0,0 +1,31 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.util.Comparator;
+
+/** Sorts the given {@link SinkWrapperFactory}s so that the one with the
highest rank comes first (i.e. order by descending ranking) */
Review Comment:
Didn't we agree on the term 'priority'?
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/PipelineSink.java:
##
@@ -28,8 +28,10 @@
/**
* May be used to invoke the same method on a List of Sinks.
+ * Consider using the more flexible {@link SinkWrapper} approach which doesn't
require the use of dynamic proxies.
Review Comment:
If you consider it better suited, I would trust your judgement here.
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/BufferingSinkProxyFactory.java:
##
@@ -0,0 +1,112 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import java.lang.reflect.InvocationHandler;
+import
[jira] [Commented] (MPOM-399) Upgrade minimalMavenBuildVersion from 3.2.5 to 3.6.3 - the minimum used by plugins
[
https://issues.apache.org/jira/browse/MPOM-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800100#comment-17800100
]
Michael Osipov commented on MPOM-399:
-
I am not happy as well...
> Upgrade minimalMavenBuildVersion from 3.2.5 to 3.6.3 - the minimum used by
> plugins
> --
>
> Key: MPOM-399
> URL: https://issues.apache.org/jira/browse/MPOM-399
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: ASF-31
>
>
> Current is {{3.2.5}}
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html
> {{maven-help-plugin}} - {{3.4.0}} requires {{3.6.3}}
>
> Rationale:
> - early build fail with proper message - not when newer plugin used
> - 3.6.3 minimum version widly used on Mavne CI and in other ASF project
> - other than Maven plugins - all ASF project should use one of the newest
> version of Maven
> - in special case property {{minimalMavenBuildVersion}} can be overridden
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-710) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/DOXIA-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800099#comment-17800099
]
ASF GitHub Bot commented on DOXIA-710:
--
michael-o commented on code in PR #180:
URL: https://github.com/apache/maven-doxia/pull/180#discussion_r1435692207
##
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexEntry.java:
##
@@ -53,10 +56,41 @@ public class IndexEntry {
*/
private List childEntries = new ArrayList<>();
+public enum Type {
+/**
+ * Used for unknown types but also for the root entry
+ */
+UNKNOWN,
+SECTION_1,
+SECTION_2,
+SECTION_3,
+SECTION_4,
+SECTION_5,
+SECTION_6,
+DEFINED_TERM,
+FIGURE,
+TABLE;
+
+static Type fromSectionLevel(int level) {
+if (level < SECTION_1.ordinal() || level > SECTION_6.ordinal()) {
+throw new IllegalArgumentException("Level must be between " +
SECTION_1.ordinal() + " and "
++ SECTION_6.ordinal() + " but is " + level);
+}
+return Arrays.stream(Type.values())
+.filter(t -> level == t.ordinal())
+.findAny()
+.orElseThrow(() -> new IllegalStateException("Could not
find enum with ordinal " + level));
+}
+};
/**
* The type of the entry, one of the types defined by {@link IndexingSink}
*/
-private final int type;
+private final Type type;
+
+/**
+ * System-dependent EOL.
+ */
+private static final String EOL = System.getProperty("line.separator");
Review Comment:
Why not `Markup.EOL`?
##
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexEntry.java:
##
@@ -53,10 +56,41 @@ public class IndexEntry {
*/
private List childEntries = new ArrayList<>();
+public enum Type {
+/**
+ * Used for unknown types but also for the root entry
+ */
+UNKNOWN,
+SECTION_1,
+SECTION_2,
+SECTION_3,
+SECTION_4,
+SECTION_5,
+SECTION_6,
+DEFINED_TERM,
+FIGURE,
+TABLE;
+
+static Type fromSectionLevel(int level) {
+if (level < SECTION_1.ordinal() || level > SECTION_6.ordinal()) {
Review Comment:
In general, it is a bad practice to the use ordinal for this. The ordinal is
rather an internal value. See Effective Java from Joshua Bloch. Better to
introduce a constructor value for this.
> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIA-710
> URL: https://issues.apache.org/jira/browse/DOXIA-710
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Critical
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-710] Auto-generate anchor for TOC entries [maven-doxia]
michael-o commented on code in PR #180:
URL: https://github.com/apache/maven-doxia/pull/180#discussion_r1435692207
##
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexEntry.java:
##
@@ -53,10 +56,41 @@ public class IndexEntry {
*/
private List childEntries = new ArrayList<>();
+public enum Type {
+/**
+ * Used for unknown types but also for the root entry
+ */
+UNKNOWN,
+SECTION_1,
+SECTION_2,
+SECTION_3,
+SECTION_4,
+SECTION_5,
+SECTION_6,
+DEFINED_TERM,
+FIGURE,
+TABLE;
+
+static Type fromSectionLevel(int level) {
+if (level < SECTION_1.ordinal() || level > SECTION_6.ordinal()) {
+throw new IllegalArgumentException("Level must be between " +
SECTION_1.ordinal() + " and "
++ SECTION_6.ordinal() + " but is " + level);
+}
+return Arrays.stream(Type.values())
+.filter(t -> level == t.ordinal())
+.findAny()
+.orElseThrow(() -> new IllegalStateException("Could not
find enum with ordinal " + level));
+}
+};
/**
* The type of the entry, one of the types defined by {@link IndexingSink}
*/
-private final int type;
+private final Type type;
+
+/**
+ * System-dependent EOL.
+ */
+private static final String EOL = System.getProperty("line.separator");
Review Comment:
Why not `Markup.EOL`?
##
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexEntry.java:
##
@@ -53,10 +56,41 @@ public class IndexEntry {
*/
private List childEntries = new ArrayList<>();
+public enum Type {
+/**
+ * Used for unknown types but also for the root entry
+ */
+UNKNOWN,
+SECTION_1,
+SECTION_2,
+SECTION_3,
+SECTION_4,
+SECTION_5,
+SECTION_6,
+DEFINED_TERM,
+FIGURE,
+TABLE;
+
+static Type fromSectionLevel(int level) {
+if (level < SECTION_1.ordinal() || level > SECTION_6.ordinal()) {
Review Comment:
In general, it is a bad practice to the use ordinal for this. The ordinal is
rather an internal value. See Effective Java from Joshua Bloch. Better to
introduce a constructor value for this.
--
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 comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (DOXIA-710) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/DOXIA-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800097#comment-17800097
]
ASF GitHub Bot commented on DOXIA-710:
--
michael-o commented on code in PR #180:
URL: https://github.com/apache/maven-doxia/pull/180#discussion_r1428911493
##
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexEntry.java:
##
@@ -304,7 +310,7 @@ public String toString(int depth) {
message.append(", title: ").append(title);
}
-message.append(EOL);
+message.append(System.lineSeparator());
Review Comment:
Attention, this is a semantical change. All others use the idiom above and
there are tests which change the separator with try/finally. This one is cached
upon first call. I wouldn't change it.
> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIA-710
> URL: https://issues.apache.org/jira/browse/DOXIA-710
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Critical
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-710] Auto-generate anchor for TOC entries [maven-doxia]
michael-o commented on code in PR #180:
URL: https://github.com/apache/maven-doxia/pull/180#discussion_r1428911493
##
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexEntry.java:
##
@@ -304,7 +310,7 @@ public String toString(int depth) {
message.append(", title: ").append(title);
}
-message.append(EOL);
+message.append(System.lineSeparator());
Review Comment:
Attention, this is a semantical change. All others use the idiom above and
there are tests which change the separator with try/finally. This one is cached
upon first call. I wouldn't change it.
--
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 comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (DOXIA-712) Add validation capability to Sink API
[
https://issues.apache.org/jira/browse/DOXIA-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIA-712:
--
Description:
The Sink API comes with several limitations with regards to valid order of
events/method calls and valid parametrization. Those are documented in the
javadoc of the Sink interface but are complex to follow. This includes
- certain start events need to be followed by an according end event
- {{sectionTitle(int,SinkEventAttributes)}} needs to be directly preceded by
{{section(int,SinkEventAttributes)}} with the same first argument.
- certain rules for sequence of events for {{table}}, {{list}} (numbered,
non-numbered and definition) and {{figure}}
- validation of certain common parameters like {{level}} or
{{SinkEventAttributes}} for valid values
As we encourage the direct usage of the Sink API for report mojos there should
be a way for mojo authors to quickly crosscheck whether they used the Sink API
in a correct way.
was:
The Sink API comes with several limitations with regards to valid order of
events/method calls and valid parametrization. Those are documented in the
javadoc of the Sink interface but are complex to follow. This includes
- certain start event need to be followed by an according end event
- {{sectionTitle(int,SinkEventAttributes)}} needs to be directly preceded by
{{section(int,SinkEventAttributes)}} with the same first argument.
- certain rules for sequence of events for {{table}}, {{list}} (numbered,
non-numbered and definition) and {{figure}}
- validation of certain common parameters like {{level}} or
{{SinkEventAttributes}} for valid values
As we encourage the direct usage of the Sink API for report mojos there should
be a way for mojo authors to quickly crosscheck whether they used the Sink API
in a correct way.
> Add validation capability to Sink API
> -
>
> Key: DOXIA-712
> URL: https://issues.apache.org/jira/browse/DOXIA-712
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Priority: Major
>
> The Sink API comes with several limitations with regards to valid order of
> events/method calls and valid parametrization. Those are documented in the
> javadoc of the Sink interface but are complex to follow. This includes
> - certain start events need to be followed by an according end event
> - {{sectionTitle(int,SinkEventAttributes)}} needs to be directly preceded by
> {{section(int,SinkEventAttributes)}} with the same first argument.
> - certain rules for sequence of events for {{table}}, {{list}} (numbered,
> non-numbered and definition) and {{figure}}
> - validation of certain common parameters like {{level}} or
> {{SinkEventAttributes}} for valid values
> As we encourage the direct usage of the Sink API for report mojos there
> should be a way for mojo authors to quickly crosscheck whether they used the
> Sink API in a correct way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIA-712) Add validation capability to Sink API
[
https://issues.apache.org/jira/browse/DOXIA-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIA-712:
--
Description:
The Sink API comes with several limitations with regards to valid order of
events/method calls and valid parametrization. Those are documented in the
javadoc of the Sink interface but are complex to follow. This includes
- certain start event need to be followed by an according end event
- {{sectionTitle(int,SinkEventAttributes)}} needs to be directly preceded by
{{section(int,SinkEventAttributes)}} with the same first argument.
- certain rules for sequence of events for {{table}}, {{list}} (numbered,
non-numbered and definition) and {{figure}}
- validation of certain common parameters like {{level}} or
{{SinkEventAttributes}} for valid values
As we encourage the direct usage of the Sink API for report mojos there should
be a way for mojo authors to quickly crosscheck whether they used the Sink API
in a correct way.
was:
The Sink API comes with several limitations with regards to valid order of
events/method calls and valid parametrization. Those are documented in the
javadoc of the Sink interface but are complex to follow. This includes
- certain start event need to be followed by an according end event
- {{sectionTitle(int,SinkEventAttributes)}} needs to be directly preceded by
{{section(int,SinkEventAttributes)}} with the same first argument.
- certain rules for sequence of events for {{table}}, {{list}} (numbered,
non-numbered and definition) and {{figure}}
- validation of certain common parameters like {{level}} or
{{SinkEventAttributes}} for valid values
> Add validation capability to Sink API
> -
>
> Key: DOXIA-712
> URL: https://issues.apache.org/jira/browse/DOXIA-712
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Priority: Major
>
> The Sink API comes with several limitations with regards to valid order of
> events/method calls and valid parametrization. Those are documented in the
> javadoc of the Sink interface but are complex to follow. This includes
> - certain start event need to be followed by an according end event
> - {{sectionTitle(int,SinkEventAttributes)}} needs to be directly preceded by
> {{section(int,SinkEventAttributes)}} with the same first argument.
> - certain rules for sequence of events for {{table}}, {{list}} (numbered,
> non-numbered and definition) and {{figure}}
> - validation of certain common parameters like {{level}} or
> {{SinkEventAttributes}} for valid values
> As we encourage the direct usage of the Sink API for report mojos there
> should be a way for mojo authors to quickly crosscheck whether they used the
> Sink API in a correct way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIA-712) Add validation capability to Sink API
[
https://issues.apache.org/jira/browse/DOXIA-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIA-712:
--
Description:
The Sink API comes with several limitations with regards to valid order of
events/method calls and valid parametrization. Those are documented in the
javadoc of the Sink interface but are complex to follow. This includes
- certain start event need to be followed by an according end event
- {{sectionTitle(int,SinkEventAttributes)}} needs to be directly preceded by
{{section(int,SinkEventAttributes)}} with the same first argument.
- certain rules for sequence of events for {{table}}, {{list}} (numbered,
non-numbered and definition) and {{figure}}
- validation of certain common parameters like {{level}} or
{{SinkEventAttributes}} for valid values
was:
The Sink API comes with several limitations with regards to valid order of
events/method calls. Those are documented in the javadoc of the Sink interface
but are complex to follow. This includes
- certain start event need to be followed by an according end event
- {{sectionTitle(int,SinkEventAttributes)}} needs to be directly preceded by
{{section(int,SinkEventAttributes)}} with the same first argument.
- certain rules for sequence of events for {{table}}, {{list}} (numbered,
non-numbered and definition) and {{figure}}
- validation of certain common parameters like {{level}} or
{{SinkEventAttributes}} for valid values
> Add validation capability to Sink API
> -
>
> Key: DOXIA-712
> URL: https://issues.apache.org/jira/browse/DOXIA-712
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Priority: Major
>
> The Sink API comes with several limitations with regards to valid order of
> events/method calls and valid parametrization. Those are documented in the
> javadoc of the Sink interface but are complex to follow. This includes
> - certain start event need to be followed by an according end event
> - {{sectionTitle(int,SinkEventAttributes)}} needs to be directly preceded by
> {{section(int,SinkEventAttributes)}} with the same first argument.
> - certain rules for sequence of events for {{table}}, {{list}} (numbered,
> non-numbered and definition) and {{figure}}
> - validation of certain common parameters like {{level}} or
> {{SinkEventAttributes}} for valid values
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIA-712) Add validation capability to Sink API
Konrad Windszus created DOXIA-712:
-
Summary: Add validation capability to Sink API
Key: DOXIA-712
URL: https://issues.apache.org/jira/browse/DOXIA-712
Project: Maven Doxia
Issue Type: Improvement
Components: Core
Reporter: Konrad Windszus
The Sink API comes with several limitations with regards to valid order of
events/method calls. Those are documented in the javadoc of the Sink interface
but are complex to follow. This includes
- certain start event need to be followed by an according end event
- {{sectionTitle(int,SinkEventAttributes)}} needs to be directly preceded by
{{section(int,SinkEventAttributes)}} with the same first argument.
- certain rules for sequence of events for {{table}}, {{list}} (numbered,
non-numbered and definition) and {{figure}}
- validation of certain common parameters like {{level}} or
{{SinkEventAttributes}} for valid values
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[
https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800095#comment-17800095
]
ASF GitHub Bot commented on DOXIA-711:
--
kwin commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435685833
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/RandomAccessSink.java:
##
@@ -27,19 +27,21 @@
import java.util.List;
import org.apache.maven.doxia.sink.Sink;
-import org.apache.maven.doxia.sink.SinkEventAttributes;
import org.apache.maven.doxia.sink.SinkFactory;
/**
* The RandomAccessSink provides the ability to create a {@link Sink} with
hooks.
* A page can be prepared by first creating its structure and specifying the
positions of these hooks.
* After specifying the structure, the page can be filled with content from
one or more models.
* These hooks can prevent you to have to loop over the model multiple times
to build the page as desired.
- *
+ * Consider using the {@link BufferingSinkProxyFactory} instead which allows
to buffer on the (higher) Sink API level
Review Comment:
Should we deprecate in favour of `SinkWrapper`?
> Introduce SinkWrapper with factory
> --
>
> Key: DOXIA-711
> URL: https://issues.apache.org/jira/browse/DOXIA-711
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0-M9
>
>
> Similar to HttpServletRequestWrapper in Servlet API one should have a
> SinkWrapper helper for Doxia. That allows to easily implement some
> post/preprocessing and even modifying or skipping the underlying sink. All
> Sink wrappers and the original sink should form a pipeline.
> Registering a SinkWrapper should optionally be done automatically (via JSR330
> annotations) or manually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
kwin commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435685833
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/RandomAccessSink.java:
##
@@ -27,19 +27,21 @@
import java.util.List;
import org.apache.maven.doxia.sink.Sink;
-import org.apache.maven.doxia.sink.SinkEventAttributes;
import org.apache.maven.doxia.sink.SinkFactory;
/**
* The RandomAccessSink provides the ability to create a {@link Sink} with
hooks.
* A page can be prepared by first creating its structure and specifying the
positions of these hooks.
* After specifying the structure, the page can be filled with content from
one or more models.
* These hooks can prevent you to have to loop over the model multiple times
to build the page as desired.
- *
+ * Consider using the {@link BufferingSinkProxyFactory} instead which allows
to buffer on the (higher) Sink API level
Review Comment:
Should we deprecate in favour of `SinkWrapper`?
--
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 comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
kwin commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435685799
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/PipelineSink.java:
##
@@ -28,8 +28,10 @@
/**
* May be used to invoke the same method on a List of Sinks.
+ * Consider using the more flexible {@link SinkWrapper} approach which doesn't
require the use of dynamic proxies.
Review Comment:
Should we deprecate in favour of `SinkWrapper`?
--
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 comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[
https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800094#comment-17800094
]
ASF GitHub Bot commented on DOXIA-711:
--
kwin commented on code in PR #184:
URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435685799
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/PipelineSink.java:
##
@@ -28,8 +28,10 @@
/**
* May be used to invoke the same method on a List of Sinks.
+ * Consider using the more flexible {@link SinkWrapper} approach which doesn't
require the use of dynamic proxies.
Review Comment:
Should we deprecate in favour of `SinkWrapper`?
> Introduce SinkWrapper with factory
> --
>
> Key: DOXIA-711
> URL: https://issues.apache.org/jira/browse/DOXIA-711
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0-M9
>
>
> Similar to HttpServletRequestWrapper in Servlet API one should have a
> SinkWrapper helper for Doxia. That allows to easily implement some
> post/preprocessing and even modifying or skipping the underlying sink. All
> Sink wrappers and the original sink should form a pipeline.
> Registering a SinkWrapper should optionally be done automatically (via JSR330
> annotations) or manually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[ https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800093#comment-17800093 ] ASF GitHub Bot commented on DOXIA-711: -- kwin commented on code in PR #184: URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435685688 ## doxia-core/src/main/java/org/apache/maven/doxia/parser/SinkWrapper.java: ## Review Comment: I moved now to the existing `o.a.m.doxia.sink.impl` although I find the `impl` package name part confusing... > Introduce SinkWrapper with factory > -- > > Key: DOXIA-711 > URL: https://issues.apache.org/jira/browse/DOXIA-711 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M9 > > > Similar to HttpServletRequestWrapper in Servlet API one should have a > SinkWrapper helper for Doxia. That allows to easily implement some > post/preprocessing and even modifying or skipping the underlying sink. All > Sink wrappers and the original sink should form a pipeline. > Registering a SinkWrapper should optionally be done automatically (via JSR330 > annotations) or manually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
kwin commented on code in PR #184: URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435685688 ## doxia-core/src/main/java/org/apache/maven/doxia/parser/SinkWrapper.java: ## Review Comment: I moved now to the existing `o.a.m.doxia.sink.impl` although I find the `impl` package name part confusing... -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
kwin commented on code in PR #184: URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435679435 ## doxia-core/src/main/java/org/apache/maven/doxia/parser/SinkWrapper.java: ## Review Comment: Should we move this to another package? Maybe `o.a.m.doxia.sink.impl` is better, but this is clearly no impl details but rather class to be reused among doxia modules and potentially other consumers. Usually `impl` packages are used for packages which should not be reused outside the current JAR. So maybe `o.a.m.doxia.sink` is better, OTOH all other classes in `o.a.m.doxia.sink.impl` are probably not belonging to an impl package either, as all of them are reused. WDYT @michael-o -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[ https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800090#comment-17800090 ] ASF GitHub Bot commented on DOXIA-711: -- kwin commented on code in PR #184: URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435679435 ## doxia-core/src/main/java/org/apache/maven/doxia/parser/SinkWrapper.java: ## Review Comment: Should we move this to another package? Maybe `o.a.m.doxia.sink.impl` is better, but this is clearly no impl details but rather class to be reused among doxia modules and potentially other consumers. Usually `impl` packages are used for packages which should not be reused outside the current JAR. So maybe `o.a.m.doxia.sink` is better, OTOH all other classes in `o.a.m.doxia.sink.impl` are probably not belonging to an impl package either, as all of them are reused. WDYT @michael-o? > Introduce SinkWrapper with factory > -- > > Key: DOXIA-711 > URL: https://issues.apache.org/jira/browse/DOXIA-711 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M9 > > > Similar to HttpServletRequestWrapper in Servlet API one should have a > SinkWrapper helper for Doxia. That allows to easily implement some > post/preprocessing and even modifying or skipping the underlying sink. All > Sink wrappers and the original sink should form a pipeline. > Registering a SinkWrapper should optionally be done automatically (via JSR330 > annotations) or manually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[ https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800089#comment-17800089 ] ASF GitHub Bot commented on DOXIA-711: -- kwin commented on code in PR #184: URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435679435 ## doxia-core/src/main/java/org/apache/maven/doxia/parser/SinkWrapper.java: ## Review Comment: Should we move this to another package? Maybe `o.a.m.doxia.sink.impl` is better, but this is clearly no impl details but rather class to be reused among doxia modules and potentially other consumers. Usually `impl` packages are used for packages which should not be reused outside the current JAR. So maybe `o.a.m.doxia.sink` is better, OTOH all other classes in `o.a.m.doxia.sink.impl` are probably not belonging to an impl package either, as all of them are reused. WDYT @michael-o > Introduce SinkWrapper with factory > -- > > Key: DOXIA-711 > URL: https://issues.apache.org/jira/browse/DOXIA-711 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M9 > > > Similar to HttpServletRequestWrapper in Servlet API one should have a > SinkWrapper helper for Doxia. That allows to easily implement some > post/preprocessing and even modifying or skipping the underlying sink. All > Sink wrappers and the original sink should form a pipeline. > Registering a SinkWrapper should optionally be done automatically (via JSR330 > annotations) or manually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
kwin commented on code in PR #184: URL: https://github.com/apache/maven-doxia/pull/184#discussion_r1435679435 ## doxia-core/src/main/java/org/apache/maven/doxia/parser/SinkWrapper.java: ## Review Comment: Should we move this to another package? Maybe `o.a.m.doxia.sink.impl` is better, but this is clearly no impl details but rather class to be reused among doxia modules and potentially other consumers. Usually `impl` packages are used for packages which should not be reused outside the current JAR. So maybe `o.a.m.doxia.sink` is better, OTOH all other classes in `o.a.m.doxia.sink.impl` are probably not belonging to an impl package either, as all of them are reused. WDYT @michael-o? -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (DOXIA-699) Xhtml5Parser may emit sectionX() without sectionX_()
[
https://issues.apache.org/jira/browse/DOXIA-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned DOXIA-699:
-
Assignee: Konrad Windszus
> Xhtml5Parser may emit sectionX() without sectionX_()
>
>
> Key: DOXIA-699
> URL: https://issues.apache.org/jira/browse/DOXIA-699
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-M5
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: test.xhtml5
>
>
> Due to the logic in
> https://github.com/apache/maven-doxia/blob/37173794270ee68894aac0e252dcb87545770952/doxia-core/src/main/java/org/apache/maven/doxia/parser/Xhtml5BaseParser.java#L631
> there may calls of {{Sink.sectionX()}} without the according call of
> {{Sink.sectionX_()}}.
> The attached XHTML5 being parsed and then converted back through the Sink to
> XHTML5 is invalid (lacks one closing section tag).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-711) Introduce SinkWrapper with factory
[ https://issues.apache.org/jira/browse/DOXIA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800087#comment-17800087 ] ASF GitHub Bot commented on DOXIA-711: -- kwin opened a new pull request, #184: URL: https://github.com/apache/maven-doxia/pull/184 Add a BufferingSinkProxyWrapper which buffers all calls on the underlying sink until it is flushed. > Introduce SinkWrapper with factory > -- > > Key: DOXIA-711 > URL: https://issues.apache.org/jira/browse/DOXIA-711 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M9 > > > Similar to HttpServletRequestWrapper in Servlet API one should have a > SinkWrapper helper for Doxia. That allows to easily implement some > post/preprocessing and even modifying or skipping the underlying sink. All > Sink wrappers and the original sink should form a pipeline. > Registering a SinkWrapper should optionally be done automatically (via JSR330 > annotations) or manually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [DOXIA-711] Introduce SinkWrapper and according SinkWrapperFactory [maven-doxia]
kwin opened a new pull request, #184: URL: https://github.com/apache/maven-doxia/pull/184 Add a BufferingSinkProxyWrapper which buffers all calls on the underlying sink until it is flushed. -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (DOXIA-711) Introduce SinkWrapper with factory
Konrad Windszus created DOXIA-711: - Summary: Introduce SinkWrapper with factory Key: DOXIA-711 URL: https://issues.apache.org/jira/browse/DOXIA-711 Project: Maven Doxia Issue Type: Improvement Components: Core Reporter: Konrad Windszus Assignee: Konrad Windszus Fix For: 2.0.0-M9 Similar to HttpServletRequestWrapper in Servlet API one should have a SinkWrapper helper for Doxia. That allows to easily implement some post/preprocessing and even modifying or skipping the underlying sink. All Sink wrappers and the original sink should form a pipeline. Registering a SinkWrapper should optionally be done automatically (via JSR330 annotations) or manually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJARSIGNER-74) Allow usage of multiple Time Stamping Authority (TSA) servers
[
https://issues.apache.org/jira/browse/MJARSIGNER-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800080#comment-17800080
]
ASF GitHub Bot commented on MJARSIGNER-74:
--
schedin opened a new pull request, #19:
URL: https://github.com/apache/maven-jarsigner-plugin/pull/19
Implementation of support for multiple TSA servers. A new server will be
tried if the jarsigner command fails. The failure could be with communication
with the TSA server, or could be something unrelated to TSA (for example access
to a network based PKSC11 keystore).
I have also implemented support for:
1. Specifying multiple TSA keystore aliases as an alternative to specifying
TSA URLs directly
2. Specify `tsapolicyid` OID(s) to send to the TSA server(s)
3. Specify the message digest algorithm (`tsadigestalg`) to use in
communication with the TSA server (no multi-support, only one value for all TSA
servers).
The hardest thing working with this ticket was to figure out what should be
possible to configure from an end user perspective. This is what I came up with
(and would like feedback on):
1. I did not see any need to throw an exception (abort the Mojo) if the end
user configured something that I consider "wrong". Instead I have logged
warnings when this happens
2. Setting both `tsa` and `tsacert` seems wrong. At least jarsigner will
ignore `-tsacert` if `-tsa` is set. However from a bigger perspective it might
be possible for the end user to want to configure 1 TSA url and 2 keystore
alias as to try 3 TSA servers in total? But this scenario felt too complicated
to document and specify, so I skipped it.
3. As I tested this feature against public TSA servers it became clear that
they will typically have a dedicated, vendor specific OID. For example
http://timestamp.digicert.com will only accept the DigiCert created [OID
2.16.840.1.114412.7.1](http://www.oid-info.com/cgi-bin/display?oid=2.16.840.1.114412.7=Display=display).
I therefore tried to document that the number of OIDs specified by the end
user should be the same as the number of TSA servers the user wants to try.
4. For `tsadigestalg` on the other hand I did not see any need to specify
multiple. All TSA servers will handle the most common message digest algorithms.
5. The usage of `tsacert`, `tsapolicyid` and `tsadigestalg` is probably
obscure. I'm not sure anybody is interested in using these features. It took me
many hours before I could create a testing keystore that contained a valid
certificate to use. And it took me some additions hours to figure out what OIDs
to use. It was only after using Wireshark to sniff the traffic that I
understood how the protocol in RFC 3161 worked.
**Note:** this pull request can not be merged until a new release build of
https://github.com/apache/maven-jarsigner has been made.
> Allow usage of multiple Time Stamping Authority (TSA) servers
> -
>
> Key: MJARSIGNER-74
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-74
> Project: Maven Jar Signer Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Lennart Schedin
>Priority: Minor
>
> h3. Background
> A Timestamping Authority (TSA) server is used to add a timestamp to the
> digital signature. This timestamp indicates when the code was signed and
> helps prevent issues that may arise if a certificate used for code signing
> expires.
> The jarsigner command has 4 parameters relating to TSA (see
> [https://docs.oracle.com/en/java/javase/17/docs/specs/man/jarsigner.html):]
> 1. {{-tsa url}}
> 2. {{-tsacert alias}}
> 3. {{-tsapolicyid policyid}}
> 4. {{-tsadigestalg algorithm}}
> The maven-jarsigner-plugin currently has support to set {{-tsa}} and
> {{-tsacert}} (the same goes for the library JarSignerSignRequest in the
> [https://github.com/apache/maven-jarsigner] project).
> h3. Feature requested
> Allow usage of multiple TSA servers when signing. This could be useful for:
> 1. Better stability if one TSA server is down.
> 2. Better stability if a TSA server has imposed a rate-limit when signing
> many jar files at the same time.
> This feature has both been suggested by Thorsten Meinl as a patch to
> [https://issues.apache.org/jira/projects/MJARSIGNER/issues/MJARSIGNER-59] and
> also by @jcompagner in
> [https://github.com/apache/maven-jarsigner-plugin/pull/1#issuecomment-1412344998].
> But since those suggestions were not tied to a direct ticket, I felt it
> would be good to collect their feature requests as a separate dedicated
> ticket.
> h3. Implementation suggestions
> I don’t plan to implement this feature myself. But since I have analyzed the
> issue, I can give my suggestions on how to implement it:
> # The {{-tsapolicyid}} parameter is currently
[PR] [MJARSIGNER-74] Allow usage of multiple Time Stamping Authority (TSA) servers [maven-jarsigner-plugin]
schedin opened a new pull request, #19: URL: https://github.com/apache/maven-jarsigner-plugin/pull/19 Implementation of support for multiple TSA servers. A new server will be tried if the jarsigner command fails. The failure could be with communication with the TSA server, or could be something unrelated to TSA (for example access to a network based PKSC11 keystore). I have also implemented support for: 1. Specifying multiple TSA keystore aliases as an alternative to specifying TSA URLs directly 2. Specify `tsapolicyid` OID(s) to send to the TSA server(s) 3. Specify the message digest algorithm (`tsadigestalg`) to use in communication with the TSA server (no multi-support, only one value for all TSA servers). The hardest thing working with this ticket was to figure out what should be possible to configure from an end user perspective. This is what I came up with (and would like feedback on): 1. I did not see any need to throw an exception (abort the Mojo) if the end user configured something that I consider "wrong". Instead I have logged warnings when this happens 2. Setting both `tsa` and `tsacert` seems wrong. At least jarsigner will ignore `-tsacert` if `-tsa` is set. However from a bigger perspective it might be possible for the end user to want to configure 1 TSA url and 2 keystore alias as to try 3 TSA servers in total? But this scenario felt too complicated to document and specify, so I skipped it. 3. As I tested this feature against public TSA servers it became clear that they will typically have a dedicated, vendor specific OID. For example http://timestamp.digicert.com will only accept the DigiCert created [OID 2.16.840.1.114412.7.1](http://www.oid-info.com/cgi-bin/display?oid=2.16.840.1.114412.7=Display=display). I therefore tried to document that the number of OIDs specified by the end user should be the same as the number of TSA servers the user wants to try. 4. For `tsadigestalg` on the other hand I did not see any need to specify multiple. All TSA servers will handle the most common message digest algorithms. 5. The usage of `tsacert`, `tsapolicyid` and `tsadigestalg` is probably obscure. I'm not sure anybody is interested in using these features. It took me many hours before I could create a testing keystore that contained a valid certificate to use. And it took me some additions hours to figure out what OIDs to use. It was only after using Wireshark to sniff the traffic that I understood how the protocol in RFC 3161 worked. **Note:** this pull request can not be merged until a new release build of https://github.com/apache/maven-jarsigner has been made. -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPLUGINTESTING-72) release 3.4.0
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800054#comment-17800054 ] Slawomir Jaranowski commented on MPLUGINTESTING-72: --- [~singingbush] You can try version 4.0.0-alpha-2 - should be also ok with Maven 3 - MPLUGINTESTING-91 > release 3.4.0 > - > > Key: MPLUGINTESTING-72 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-72 > Project: Maven Plugin Testing > Issue Type: Wish >Reporter: Samael Bate >Priority: Major > > the master branch is passing all builds. There hasn't been a release since > 2014. What's the reasoning for not publishing a new release? There are > numerous dependency updates as well as documentation fixes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGINTESTING-72) release 3.4.0
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800052#comment-17800052 ] Sylwester Lachiewicz commented on MPLUGINTESTING-72: Sorry, I had no time to push it forward and master branch now targets Maven ,4 > release 3.4.0 > - > > Key: MPLUGINTESTING-72 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-72 > Project: Maven Plugin Testing > Issue Type: Wish >Reporter: Samael Bate >Priority: Major > > the master branch is passing all builds. There hasn't been a release since > 2014. What's the reasoning for not publishing a new release? There are > numerous dependency updates as well as documentation fixes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (MPLUGINTESTING-72) release 3.4.0
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reopened MPLUGINTESTING-72: > release 3.4.0 > - > > Key: MPLUGINTESTING-72 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-72 > Project: Maven Plugin Testing > Issue Type: Wish >Reporter: Samael Bate >Priority: Major > > the master branch is passing all builds. There hasn't been a release since > 2014. What's the reasoning for not publishing a new release? There are > numerous dependency updates as well as documentation fixes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGINTESTING-62) use maven API 3.6.0 and Plexus 2.0.0
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800051#comment-17800051 ] ASF GitHub Bot commented on MPLUGINTESTING-62: -- SingingBush opened a new pull request, #8: URL: https://github.com/apache/maven-plugin-testing/pull/8 pretty frustrating that in 2019 people are still targeting ancient Java versions. In this pull request I've set JDK 8 as the target and also updated to a more recent maven api level and updated junit to the newer `org.junit.vintage:junit-vintage-engine` equivelant. Any change of a new release? 3.3.0 was released years ago > use maven API 3.6.0 and Plexus 2.0.0 > > > Key: MPLUGINTESTING-62 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-62 > Project: Maven Plugin Testing > Issue Type: Dependency upgrade >Reporter: Samael Bate >Priority: Major > Labels: close-pending > > Along with updating to use Java 7 (MPLUGINTESTING-61) the plugin should use a > recent maven API. > As there is no 3.6.0 for maven-aether-provider it will need be set to 3.3.9 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MPLUGINTESTING-62] target maven 3.6.0 and Plexus 2.0.0 [maven-plugin-testing]
SingingBush opened a new pull request, #8: URL: https://github.com/apache/maven-plugin-testing/pull/8 pretty frustrating that in 2019 people are still targeting ancient Java versions. In this pull request I've set JDK 8 as the target and also updated to a more recent maven api level and updated junit to the newer `org.junit.vintage:junit-vintage-engine` equivelant. Any change of a new release? 3.3.0 was released years ago -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MPLUGINTESTING-72) release 3.4.0
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800050#comment-17800050 ] Samael Bate edited comment on MPLUGINTESTING-72 at 12/23/23 1:03 PM: - How come this is closed, there's still no release that is targeting a maven 3.* release published in the last few years. After the 3.3.0 release in 2014, there's nothing until this year targeting alpha builds of Maven 4. Before focusing on supporting unreleased maven versions can't we get a release that's suitable for Maven 3.6.* I've been trying to get this since 2019 [https://github.com/apache/maven-plugin-testing/pull/8] MPLUGINTESTING-62 was (Author: singingbush): How come this is closed, there's still no release that is targeting a maven 3.* release published in the last few years. After the 3.3.0 release in 2014, there's nothing until this year targeting alpha builds of Maven 4. Before focusing on supporting unreleased maven versions can't we get a release that's suitable for Maven 3.6.* I've been trying to get this since 2019 https://github.com/apache/maven-plugin-testing/pull/8 > release 3.4.0 > - > > Key: MPLUGINTESTING-72 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-72 > Project: Maven Plugin Testing > Issue Type: Wish >Reporter: Samael Bate >Priority: Major > > the master branch is passing all builds. There hasn't been a release since > 2014. What's the reasoning for not publishing a new release? There are > numerous dependency updates as well as documentation fixes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGINTESTING-72) release 3.4.0
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800050#comment-17800050 ] Samael Bate commented on MPLUGINTESTING-72: --- How come this is closed, there's still no release that is targeting a maven 3.* release published in the last few years. After the 3.3.0 release in 2014, there's nothing until this year targeting alpha builds of Maven 4. Before focusing on supporting unreleased maven versions can't we get a release that's suitable for Maven 3.6.* I've been trying to get this since 2019 https://github.com/apache/maven-plugin-testing/pull/8 > release 3.4.0 > - > > Key: MPLUGINTESTING-72 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-72 > Project: Maven Plugin Testing > Issue Type: Wish >Reporter: Samael Bate >Priority: Major > > the master branch is passing all builds. There hasn't been a release since > 2014. What's the reasoning for not publishing a new release? There are > numerous dependency updates as well as documentation fixes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJLINK-77) Update description and parameters of --compress to reflect JDK21 changes
[
https://issues.apache.org/jira/browse/MJLINK-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800049#comment-17800049
]
ASF GitHub Bot commented on MJLINK-77:
--
bmarwell commented on PR #181:
URL:
https://github.com/apache/maven-jlink-plugin/pull/181#issuecomment-1868289842
> I'm for simplify code and pass parameter as it to external tools
Yes, see #183. Closing this one, we all agree on it.
> Update description and parameters of --compress to reflect JDK21 changes
>
>
> Key: MJLINK-77
> URL: https://issues.apache.org/jira/browse/MJLINK-77
> Project: Maven JLink Plugin
> Issue Type: Task
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.2.0
>
>
> Starting from Java 21, the allowed parameters for {{compress}} have changed,
> and the old ones are suspect to removal:
> {code:java}
> $ jlink --help
> […]
> --compress Compression to use in compressing
> resources:
> Accepted values are:
> zip-[0-9], where zip-0 provides no
> compression,
> and zip-9 provides the best
> compression.
> Default is zip-6.
> Deprecated values to be removed in a
> future release:
> 0: No compression. Equivalent to
> zip-0.
> 1: Constant String Sharing
> 2: Equivalent to zip-6.
> {code}
> Thus, the current jlink-plugin is incompatible with Java 21:
> {code:java}
> /**
> * Here you can define the compression of the resources being used. The
> command line equivalent is:
> * -c, --compress=level. The valid values for the level
> are: 0, 1, 2.
> */
> @Parameter
> private Integer compress;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJLINK-77) Update description and parameters of --compress to reflect JDK21 changes
[
https://issues.apache.org/jira/browse/MJLINK-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800048#comment-17800048
]
ASF GitHub Bot commented on MJLINK-77:
--
bmarwell closed pull request #181: [MJLINK-77] accept JDK21+ compress parameters
URL: https://github.com/apache/maven-jlink-plugin/pull/181
> Update description and parameters of --compress to reflect JDK21 changes
>
>
> Key: MJLINK-77
> URL: https://issues.apache.org/jira/browse/MJLINK-77
> Project: Maven JLink Plugin
> Issue Type: Task
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.2.0
>
>
> Starting from Java 21, the allowed parameters for {{compress}} have changed,
> and the old ones are suspect to removal:
> {code:java}
> $ jlink --help
> […]
> --compress Compression to use in compressing
> resources:
> Accepted values are:
> zip-[0-9], where zip-0 provides no
> compression,
> and zip-9 provides the best
> compression.
> Default is zip-6.
> Deprecated values to be removed in a
> future release:
> 0: No compression. Equivalent to
> zip-0.
> 1: Constant String Sharing
> 2: Equivalent to zip-6.
> {code}
> Thus, the current jlink-plugin is incompatible with Java 21:
> {code:java}
> /**
> * Here you can define the compression of the resources being used. The
> command line equivalent is:
> * -c, --compress=level. The valid values for the level
> are: 0, 1, 2.
> */
> @Parameter
> private Integer compress;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJLINK-77] accept JDK21+ compress parameters [maven-jlink-plugin]
bmarwell closed pull request #181: [MJLINK-77] accept JDK21+ compress parameters URL: https://github.com/apache/maven-jlink-plugin/pull/181 -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MJLINK-77] accept JDK21+ compress parameters [maven-jlink-plugin]
bmarwell commented on PR #181: URL: https://github.com/apache/maven-jlink-plugin/pull/181#issuecomment-1868289842 > I'm for simplify code and pass parameter as it to external tools Yes, see #183. Closing this one, we all agree on it. -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJLINK-77) Update description and parameters of --compress to reflect JDK21 changes
[
https://issues.apache.org/jira/browse/MJLINK-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800047#comment-17800047
]
ASF GitHub Bot commented on MJLINK-77:
--
bmarwell opened a new pull request, #183:
URL: https://github.com/apache/maven-jlink-plugin/pull/183
Similar to #181, but no validation. This is a breaking behaviour change as
the user now could add any parameter.
But it is not breaking in terms of project compilation.
---
Following this checklist to help us incorporate your
contribution quickly and easily:
- [X] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MJLINK) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [X] Each commit in the pull request should have a meaningful subject line
and body.
- [X] Format the pull request title like `[MJLINK-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MJLINK-XXX` with the appropriate JIRA issue. Best
practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [X] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [X] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [X] You have run the integration tests successfully (`mvn -Prun-its clean
verify`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [X] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [X] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> Update description and parameters of --compress to reflect JDK21 changes
>
>
> Key: MJLINK-77
> URL: https://issues.apache.org/jira/browse/MJLINK-77
> Project: Maven JLink Plugin
> Issue Type: Task
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.2.0
>
>
> Starting from Java 21, the allowed parameters for {{compress}} have changed,
> and the old ones are suspect to removal:
> {code:java}
> $ jlink --help
> […]
> --compress Compression to use in compressing
> resources:
> Accepted values are:
> zip-[0-9], where zip-0 provides no
> compression,
> and zip-9 provides the best
> compression.
> Default is zip-6.
> Deprecated values to be removed in a
> future release:
> 0: No compression. Equivalent to
> zip-0.
> 1: Constant String Sharing
> 2: Equivalent to zip-6.
> {code}
> Thus, the current jlink-plugin is incompatible with Java 21:
> {code:java}
> /**
> * Here you can define the compression of the resources being used. The
> command line equivalent is:
> * -c, --compress=level. The valid values for the level
> are: 0, 1, 2.
> */
> @Parameter
> private Integer compress;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MJLINK-77] compress parameters jdk21 no validation [maven-jlink-plugin]
bmarwell opened a new pull request, #183: URL: https://github.com/apache/maven-jlink-plugin/pull/183 Similar to #181, but no validation. This is a breaking behaviour change as the user now could add any parameter. But it is not breaking in terms of project compilation. --- Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJLINK) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MJLINK-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJLINK-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DOXIA-710) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/DOXIA-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800043#comment-17800043
]
ASF GitHub Bot commented on DOXIA-710:
--
kwin commented on code in PR #180:
URL: https://github.com/apache/maven-doxia/pull/180#discussion_r1435592379
##
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexEntry.java:
##
@@ -304,7 +310,7 @@ public String toString(int depth) {
message.append(", title: ").append(title);
}
-message.append(EOL);
+message.append(System.lineSeparator());
Review Comment:
I reverted that change now @michael-o
> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIA-710
> URL: https://issues.apache.org/jira/browse/DOXIA-710
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Critical
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-710] Auto-generate anchor for TOC entries [maven-doxia]
kwin commented on code in PR #180:
URL: https://github.com/apache/maven-doxia/pull/180#discussion_r1435592379
##
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexEntry.java:
##
@@ -304,7 +310,7 @@ public String toString(int depth) {
message.append(", title: ").append(title);
}
-message.append(EOL);
+message.append(System.lineSeparator());
Review Comment:
I reverted that change now @michael-o
--
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 comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Bump org.codehaus.plexus:plexus-utils from 3.5.1 to 4.0.0 [maven-build-cache-extension]
olamy commented on PR #122: URL: https://github.com/apache/maven-build-cache-extension/pull/122#issuecomment-1868251746 @dependabot recreate -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800027#comment-17800027
]
Olivier Lamy commented on MBUILDCACHE-73:
-
the PR of the linked issue has been merged.
this doesn't fix exactly the title of this issue but could be closed as well.
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Bump commons-io:commons-io from 2.11.0 to 2.15.1 [maven-build-cache-extension]
dependabot[bot] merged PR #118: URL: https://github.com/apache/maven-build-cache-extension/pull/118 -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.commons:commons-lang3 from 3.12.0 to 3.14.0 [maven-build-cache-extension]
olamy merged PR #119: URL: https://github.com/apache/maven-build-cache-extension/pull/119 -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-76:
Fix Version/s: 1.2.0
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Assignee: Olivier Lamy
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.2.0
>
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-76.
---
Resolution: Fixed
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Assignee: Olivier Lamy
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.2.0
>
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MBUILDCACHE-76:
---
Assignee: Olivier Lamy
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Assignee: Olivier Lamy
>Priority: Minor
> Labels: pull-request-available
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800026#comment-17800026
]
ASF GitHub Bot commented on MBUILDCACHE-76:
---
olamy merged PR #117:
URL: https://github.com/apache/maven-build-cache-extension/pull/117
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
> Labels: pull-request-available
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MBUILDCACHE-76] add project version as part of hash key [maven-build-cache-extension]
olamy merged PR #117: URL: https://github.com/apache/maven-build-cache-extension/pull/117 -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJLINK-77) Update description and parameters of --compress to reflect JDK21 changes
[
https://issues.apache.org/jira/browse/MJLINK-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800019#comment-17800019
]
ASF GitHub Bot commented on MJLINK-77:
--
slawekjaranowski commented on code in PR #181:
URL:
https://github.com/apache/maven-jlink-plugin/pull/181#discussion_r1435534795
##
src/it/projects/MJLINK-77_compress-parameters/verify.groovy:
##
@@ -0,0 +1,62 @@
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.*;
+import java.util.*;
+import java.util.jar.*;
+import org.codehaus.plexus.util.*;
+
+boolean result = true;
+
+try
+{
+File target = new File( basedir, "target" );
+if ( !target.exists() || !target.isDirectory() )
+{
Review Comment:
groovy has a `assert` statement, code can look better with it
> Update description and parameters of --compress to reflect JDK21 changes
>
>
> Key: MJLINK-77
> URL: https://issues.apache.org/jira/browse/MJLINK-77
> Project: Maven JLink Plugin
> Issue Type: Task
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.2.0
>
>
> Starting from Java 21, the allowed parameters for {{compress}} have changed,
> and the old ones are suspect to removal:
> {code:java}
> $ jlink --help
> […]
> --compress Compression to use in compressing
> resources:
> Accepted values are:
> zip-[0-9], where zip-0 provides no
> compression,
> and zip-9 provides the best
> compression.
> Default is zip-6.
> Deprecated values to be removed in a
> future release:
> 0: No compression. Equivalent to
> zip-0.
> 1: Constant String Sharing
> 2: Equivalent to zip-6.
> {code}
> Thus, the current jlink-plugin is incompatible with Java 21:
> {code:java}
> /**
> * Here you can define the compression of the resources being used. The
> command line equivalent is:
> * -c, --compress=level. The valid values for the level
> are: 0, 1, 2.
> */
> @Parameter
> private Integer compress;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJLINK-77] accept JDK21+ compress parameters [maven-jlink-plugin]
slawekjaranowski commented on code in PR #181:
URL:
https://github.com/apache/maven-jlink-plugin/pull/181#discussion_r1435534795
##
src/it/projects/MJLINK-77_compress-parameters/verify.groovy:
##
@@ -0,0 +1,62 @@
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.*;
+import java.util.*;
+import java.util.jar.*;
+import org.codehaus.plexus.util.*;
+
+boolean result = true;
+
+try
+{
+File target = new File( basedir, "target" );
+if ( !target.exists() || !target.isDirectory() )
+{
Review Comment:
groovy has a `assert` statement, code can look better with it
--
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 comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MJLINK-77) Update description and parameters of --compress to reflect JDK21 changes
[
https://issues.apache.org/jira/browse/MJLINK-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800017#comment-17800017
]
ASF GitHub Bot commented on MJLINK-77:
--
rmannibucau commented on PR #181:
URL:
https://github.com/apache/maven-jlink-plugin/pull/181#issuecomment-1868239770
@bmarwell if you dont passthru you know so you validate and forbid future
usage until the plugin is upgraded IMHO otherwise it does not make sense to
make it specific.
> Update description and parameters of --compress to reflect JDK21 changes
>
>
> Key: MJLINK-77
> URL: https://issues.apache.org/jira/browse/MJLINK-77
> Project: Maven JLink Plugin
> Issue Type: Task
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.2.0
>
>
> Starting from Java 21, the allowed parameters for {{compress}} have changed,
> and the old ones are suspect to removal:
> {code:java}
> $ jlink --help
> […]
> --compress Compression to use in compressing
> resources:
> Accepted values are:
> zip-[0-9], where zip-0 provides no
> compression,
> and zip-9 provides the best
> compression.
> Default is zip-6.
> Deprecated values to be removed in a
> future release:
> 0: No compression. Equivalent to
> zip-0.
> 1: Constant String Sharing
> 2: Equivalent to zip-6.
> {code}
> Thus, the current jlink-plugin is incompatible with Java 21:
> {code:java}
> /**
> * Here you can define the compression of the resources being used. The
> command line equivalent is:
> * -c, --compress=level. The valid values for the level
> are: 0, 1, 2.
> */
> @Parameter
> private Integer compress;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJLINK-77] accept JDK21+ compress parameters [maven-jlink-plugin]
rmannibucau commented on PR #181: URL: https://github.com/apache/maven-jlink-plugin/pull/181#issuecomment-1868239770 @bmarwell if you dont passthru you know so you validate and forbid future usage until the plugin is upgraded IMHO otherwise it does not make sense to make it specific. -- 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 comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MCOMPILER-424) Annotation processor fails with AnnotationTypeMismatchException on Java 11 which targets Java 8
[
https://issues.apache.org/jira/browse/MCOMPILER-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800016#comment-17800016
]
Alexander Kriegisch edited comment on MCOMPILER-424 at 12/23/23 8:17 AM:
-
The bug was accepted as
[JDK-8322706|https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8322706]
into the Oracle Java bug tracker and under the same ID
[JDK-8322706|https://bugs.openjdk.org/browse/JDK-8322706] in the actual OpenJDK
bug tracker. The latter is where you can watch the progress.
was (Author: kriegaex):
The bug was accepted as
[JDK-8322706|https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8322706]
into the Oracle Java tracker and under the same ID
[JDK-8322706|https://bugs.openjdk.org/browse/JDK-8322706] in the actual OpenJDK
bug tracker. The latter is where you can watch the progress.
> Annotation processor fails with AnnotationTypeMismatchException on Java 11
> which targets Java 8
> ---
>
> Key: MCOMPILER-424
> URL: https://issues.apache.org/jira/browse/MCOMPILER-424
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Apache Maven 3.6.3
> Java 11.0.7
>Reporter: Marian Macik
>Priority: Major
>
> When I configure the Maven Compiler Plugin running on Java 11 to target Java
> 8:
> {code:xml}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.8.1
>
> 1.8
> 1.8
>
>
> {code}
> My compilation will fail with
> {{java.lang.annotation.AnnotationTypeMismatchException}} when I use an
> annotation processor.
> I investigated it a little bit and found out that this happens only in a very
> specific case which has to fulfil these criteria:
> 1. One annotation which has the second annotation as a parameter.
> 2. The second annotation has a parameter of type {{String[]}}.
> 3. Java 11 has the compilation target set to Java 8.
> The same scenario works without any issues when I configure the Maven
> Compiler Plugin with {{11}}.
> I debugged the code and when I set the Maven Compiler Plugin to source/target
> 1.8, I noticed changes in the *AnnotationProxyMaker$ValueVisitor#getValue()*
> method. In this case, on the line in the *getValue()* method
> {code:java}
> attr.accept(this);
> {code}
> the *attr* variable holds a *ClassReader$ArrayAttributeProxy* object (so the
> second annotation's String[] parameter is being handled) and then I can see a
> *ClassCastException* thrown inside the
> *ClassReader$ArrayAttributeProxy#accept()* method:
> {code:java}
> public void accept(Visitor v) {
> ((ProxyVisitor)v).visitArrayAttributeProxy(this); }
> {code}
> which says
> {noformat}
> class com.sun.tools.javac.model.AnnotationProxyMaker$ValueVisitor cannot be
> cast to class com.sun.tools.javac.jvm.ClassReader$ProxyVisitor
> (com.sun.tools.javac.model.AnnotationProxyMaker$ValueVisitor and
> com.sun.tools.javac.jvm.ClassReader$ProxyVisitor are in module jdk.compiler
> of loader 'app')
> {noformat}
> so the *Visitor v* (of type *AnnotationProxyMaker$ValueVisitor*) cannot be
> cast to *ClassReader$ProxyVisitor*, which is correct by looking at the source
> code, and then the exception is caught at the
> *{{AnnotationProxyMaker$ValueVisitor#visitCompound()}}* method which handles
> the whole second annotation (which the String[] parameter is a part of).
> After that, it fails with the *AnnotationTypeMismatchException*.
> Now, when I execute this with {{11}}, the *attr* variable
> holds an *Attribute$Array* object and its *accept()* method looks different:
> {code:java}
> public void accept(Visitor v) { v.visitArray(this); }
> {code}
> and the code executes perfectly fine.
> There is a workaround for this and it is pretty simple. You just need to add
> an import of the second annotation on the annotated class being processed by
> the processor, even if just the default value is used. Or, in case the
> annotated class is in the same package as the annotation itself, you just
> need to provide the default value explicitly, see:
> {code:java}
> package org.example;
> /*
> * Uncomment one of these lines and the annotation processor starts working.
> */
> //import org.example.MySecondAnnotation;
> @MyFirstAnnotation(
> //secondAnnotation = @MySecondAnnotation
> )
> public class AnnotatedClass {
> }
> {code}
> Now I don't know if the issue is with the Java compiler or the Maven Compiler
> Plugin, but if it is with the former, you can at least help me to contact the
> Java compiler developers or forward me to the correct Java compiler issue
> tracking system.
> I have also prepared a reproducer which shows this issue. It is available on
> GitHub [1] and includes a short README file with instructions on how to run
> it.
>
[jira] [Commented] (MCOMPILER-424) Annotation processor fails with AnnotationTypeMismatchException on Java 11 which targets Java 8
[
https://issues.apache.org/jira/browse/MCOMPILER-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800016#comment-17800016
]
Alexander Kriegisch commented on MCOMPILER-424:
---
The bug was accepted as
[JDK-8322706|https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8322706]
into the Oracle Java tracker and under the same ID
[JDK-8322706|https://bugs.openjdk.org/browse/JDK-8322706] in the actual OpenJDK
bug tracker. The latter is where you can watch the progress.
> Annotation processor fails with AnnotationTypeMismatchException on Java 11
> which targets Java 8
> ---
>
> Key: MCOMPILER-424
> URL: https://issues.apache.org/jira/browse/MCOMPILER-424
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Apache Maven 3.6.3
> Java 11.0.7
>Reporter: Marian Macik
>Priority: Major
>
> When I configure the Maven Compiler Plugin running on Java 11 to target Java
> 8:
> {code:xml}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.8.1
>
> 1.8
> 1.8
>
>
> {code}
> My compilation will fail with
> {{java.lang.annotation.AnnotationTypeMismatchException}} when I use an
> annotation processor.
> I investigated it a little bit and found out that this happens only in a very
> specific case which has to fulfil these criteria:
> 1. One annotation which has the second annotation as a parameter.
> 2. The second annotation has a parameter of type {{String[]}}.
> 3. Java 11 has the compilation target set to Java 8.
> The same scenario works without any issues when I configure the Maven
> Compiler Plugin with {{11}}.
> I debugged the code and when I set the Maven Compiler Plugin to source/target
> 1.8, I noticed changes in the *AnnotationProxyMaker$ValueVisitor#getValue()*
> method. In this case, on the line in the *getValue()* method
> {code:java}
> attr.accept(this);
> {code}
> the *attr* variable holds a *ClassReader$ArrayAttributeProxy* object (so the
> second annotation's String[] parameter is being handled) and then I can see a
> *ClassCastException* thrown inside the
> *ClassReader$ArrayAttributeProxy#accept()* method:
> {code:java}
> public void accept(Visitor v) {
> ((ProxyVisitor)v).visitArrayAttributeProxy(this); }
> {code}
> which says
> {noformat}
> class com.sun.tools.javac.model.AnnotationProxyMaker$ValueVisitor cannot be
> cast to class com.sun.tools.javac.jvm.ClassReader$ProxyVisitor
> (com.sun.tools.javac.model.AnnotationProxyMaker$ValueVisitor and
> com.sun.tools.javac.jvm.ClassReader$ProxyVisitor are in module jdk.compiler
> of loader 'app')
> {noformat}
> so the *Visitor v* (of type *AnnotationProxyMaker$ValueVisitor*) cannot be
> cast to *ClassReader$ProxyVisitor*, which is correct by looking at the source
> code, and then the exception is caught at the
> *{{AnnotationProxyMaker$ValueVisitor#visitCompound()}}* method which handles
> the whole second annotation (which the String[] parameter is a part of).
> After that, it fails with the *AnnotationTypeMismatchException*.
> Now, when I execute this with {{11}}, the *attr* variable
> holds an *Attribute$Array* object and its *accept()* method looks different:
> {code:java}
> public void accept(Visitor v) { v.visitArray(this); }
> {code}
> and the code executes perfectly fine.
> There is a workaround for this and it is pretty simple. You just need to add
> an import of the second annotation on the annotated class being processed by
> the processor, even if just the default value is used. Or, in case the
> annotated class is in the same package as the annotation itself, you just
> need to provide the default value explicitly, see:
> {code:java}
> package org.example;
> /*
> * Uncomment one of these lines and the annotation processor starts working.
> */
> //import org.example.MySecondAnnotation;
> @MyFirstAnnotation(
> //secondAnnotation = @MySecondAnnotation
> )
> public class AnnotatedClass {
> }
> {code}
> Now I don't know if the issue is with the Java compiler or the Maven Compiler
> Plugin, but if it is with the former, you can at least help me to contact the
> Java compiler developers or forward me to the correct Java compiler issue
> tracking system.
> I have also prepared a reproducer which shows this issue. It is available on
> GitHub [1] and includes a short README file with instructions on how to run
> it.
> Thanks for help!
> [1] [https://github.com/MarianMacik/JDK11-annotation-processor-reproducer]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
