For the record: Both plexus metadata and JSR 330 annotated classes work the
same way. I had a typo in the group id.
Still one thing might be relevant to others: It is never necessary to
explicitly set the version for goals of the plugin itself (as this always has a
version set in the
I tried to come up with an implementation in
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/81,
but there is a subtle difference to using plexus metadata. Now plugins versions
inside the mapping are required, with plexus metadata they weren't. Does anyone
know where
Hi Tamás,
thanks a lot for that example. Unfortunately one cannot use
`o.a.m.lifecycle.mapping.Lifecycle.setPhases(Map)` due to
https://issues.apache.org/jira/browse/MNG-5958 in Maven [3.3.9,3.5.0).
So an implementation of LifecycleMapping or Provider is
unfortunately requiring a lot of glue
Howdy,
just for fun I hit the same issue, and this is how I got rid of Plexus XML
https://github.com/apache/maven-rar-plugin/pull/3/files#diff-b7fae2df008a8b4ad8bc93e5c2229a5768fbdc77e904615d706c5c29e5ad4997
HTH
T
On Wed, Jul 6, 2022 at 4:26 PM Konrad Windszus wrote:
>
>
> On 2022/07/06
On 2022/07/06 14:18:28 Tamás Cservenák wrote:
> Maven 3.0 did not support sisu-index (produced by sisu-maven-plugin during
> build), but 3.1 onward does support it.
>
> Hence. If you support Maven 3.0 inclusive, you must stick with plexus xml,
> otherwise is not required.
>
> T
The problem
Maven 3.0 did not support sisu-index (produced by sisu-maven-plugin during
build), but 3.1 onward does support it.
Hence. If you support Maven 3.0 inclusive, you must stick with plexus xml,
otherwise is not required.
T
On Wed, Jul 6, 2022, 15:17 Konrad Windszus wrote:
>
> > or are you trying
> or are you trying to create bindings for a new packaging?
Yes, this is what I am doing. You can see it already in
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/master/src/main/resources/META-INF/plexus/components.xml.
But from all your information I derived that I
btw, are you trying ot override the default lifecycle
= https://maven.apache.org/ref/3.8.6/maven-core/lifecycles.html
or are you trying to override the default bindings for some packaging
= https://maven.apache.org/ref/3.8.6/maven-core/default-bindings.html
or are you trying to create bindings
AbstractLifecycleMappingProvider is just an internal utility class to ease
each Provider class writing, can be copied
on Maven mixing plexus metadata with sisu and making sure overrides work, I
confess you should test...
on the lifecycle definition in maven-jar-plugin, the current copy is done
Thanks for the explanation.
As the AbstractLifecycleMappingProvider is Maven 4 only the solution for
extensions/plugins supporting Maven 3 is staying with plexus metadata?
Also I see that this is still the current way of how this is implemented in
maven-jar-plugin
on getting rid of plexus metadata for lifecycle mappings, see the work done in
core [1]: they are replaced by Provider classes
I suppose that doing equivalent classes with JSR-330 annotations in an
extension will override the core-provided classes given classpath order
Regards,
Hervé
[1]
Hi,
What is the best way to get rid of plexus metadata (components.xml) and
override the default lifecycle mapping for a certain type (as outlined in
https://blog.sonatype.com/2009/08/create-a-customized-build-process-in-maven/)
only leveraging JSR 330 annotations
Is there any way to override the clean lifecycle
I have overridden the default lifecycle and it would be useful to add a goal to
the pre-clean phase. The pom would be cleaner if I add that in components.xml.
thanks
13 matches
Mail list logo
