maven/impl/maven-cli/pom.xml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

124 lines
3.8 KiB
XML
Raw Normal View History

[MNG-8283] Maven CLIng (#1750) New CLI for Maven. Goals are reusability, extensibility and easier embeddability (a la mvnd). If you build this branch, you will end up with Maven distro that uses "new" `maven-cli:org.apache.maven.cling.MavenCling` class as entry point instead of "old" `maven-embedder:org.apache.maven.cli.MavenCli`. First step is to make "pretty much equivalent" capable CLI as compared to "old", with some exceptions: * "encryption" ops are gone, those should be in separate tool anyway * "deprecated and unsupported" CLI options like `-llr` present ONLY to make Maven fail are gone (now Arg parser will fail). Current state of affairs is messy, MavenCli mixes everything it can, contains interleaved logic for bootstrapping, arg parsing, default logic and executing Maven. First goal is to clean this up. Commons CLI are also hidden in this PR, so is ClassWorlds. This basically opens up way to have "alternative" CLI arguments parsers as well. Currently the "local" (CLI) flow is this: ``` arg[] -> localParser -> Request -> localInvoker -> maven runs (in situ) ``` But the point is if you "come up" somehow with a Request instance, one can also do just: ``` Request -> invoker -> maven runs (somewhere) ``` Local parser: * parses CLI args * infers the defaults * creates Request object that contains all information needed to run Maven * can be reused outside of CLI as well * does NOT fiddle with Plexus, logging, etc. Local invoker: * accepts Request object * deals with configuring env (logging, etc), creating DI container, and running Maven ONLY There are some experiments ongoing as well, like `ForkedInvoker` is, but also `MavenTool`. --- https://issues.apache.org/jira/browse/MNG-8283
2024-10-03 12:03:55 -04:00
<?xml version="1.0" encoding="UTF-8"?>
<!--
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.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache.maven</groupId>
<artifactId>maven</artifactId>
<version>4.0.0-beta-6-SNAPSHOT</version>
<relativePath>../../</relativePath>
[MNG-8283] Maven CLIng (#1750) New CLI for Maven. Goals are reusability, extensibility and easier embeddability (a la mvnd). If you build this branch, you will end up with Maven distro that uses "new" `maven-cli:org.apache.maven.cling.MavenCling` class as entry point instead of "old" `maven-embedder:org.apache.maven.cli.MavenCli`. First step is to make "pretty much equivalent" capable CLI as compared to "old", with some exceptions: * "encryption" ops are gone, those should be in separate tool anyway * "deprecated and unsupported" CLI options like `-llr` present ONLY to make Maven fail are gone (now Arg parser will fail). Current state of affairs is messy, MavenCli mixes everything it can, contains interleaved logic for bootstrapping, arg parsing, default logic and executing Maven. First goal is to clean this up. Commons CLI are also hidden in this PR, so is ClassWorlds. This basically opens up way to have "alternative" CLI arguments parsers as well. Currently the "local" (CLI) flow is this: ``` arg[] -> localParser -> Request -> localInvoker -> maven runs (in situ) ``` But the point is if you "come up" somehow with a Request instance, one can also do just: ``` Request -> invoker -> maven runs (somewhere) ``` Local parser: * parses CLI args * infers the defaults * creates Request object that contains all information needed to run Maven * can be reused outside of CLI as well * does NOT fiddle with Plexus, logging, etc. Local invoker: * accepts Request object * deals with configuring env (logging, etc), creating DI container, and running Maven ONLY There are some experiments ongoing as well, like `ForkedInvoker` is, but also `MavenTool`. --- https://issues.apache.org/jira/browse/MNG-8283
2024-10-03 12:03:55 -04:00
</parent>
<artifactId>maven-cli</artifactId>
<name>Maven 4 CLI</name>
<description>Maven 4 CLI component, with CLI and logging support.</description>
[MNG-8283] Maven CLIng (#1750) New CLI for Maven. Goals are reusability, extensibility and easier embeddability (a la mvnd). If you build this branch, you will end up with Maven distro that uses "new" `maven-cli:org.apache.maven.cling.MavenCling` class as entry point instead of "old" `maven-embedder:org.apache.maven.cli.MavenCli`. First step is to make "pretty much equivalent" capable CLI as compared to "old", with some exceptions: * "encryption" ops are gone, those should be in separate tool anyway * "deprecated and unsupported" CLI options like `-llr` present ONLY to make Maven fail are gone (now Arg parser will fail). Current state of affairs is messy, MavenCli mixes everything it can, contains interleaved logic for bootstrapping, arg parsing, default logic and executing Maven. First goal is to clean this up. Commons CLI are also hidden in this PR, so is ClassWorlds. This basically opens up way to have "alternative" CLI arguments parsers as well. Currently the "local" (CLI) flow is this: ``` arg[] -> localParser -> Request -> localInvoker -> maven runs (in situ) ``` But the point is if you "come up" somehow with a Request instance, one can also do just: ``` Request -> invoker -> maven runs (somewhere) ``` Local parser: * parses CLI args * infers the defaults * creates Request object that contains all information needed to run Maven * can be reused outside of CLI as well * does NOT fiddle with Plexus, logging, etc. Local invoker: * accepts Request object * deals with configuring env (logging, etc), creating DI container, and running Maven ONLY There are some experiments ongoing as well, like `ForkedInvoker` is, but also `MavenTool`. --- https://issues.apache.org/jira/browse/MNG-8283
2024-10-03 12:03:55 -04:00
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-api-cli</artifactId>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-embedder</artifactId>
</dependency>
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-classworlds</artifactId>
</dependency>
<dependency>
<groupId>javax.inject</groupId>
<artifactId>javax.inject</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.eclipse.sisu</groupId>
<artifactId>org.eclipse.sisu.inject</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.eclipse.sisu</groupId>
<artifactId>org.eclipse.sisu.plexus</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-jline</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</dependency>
<dependency>
<groupId>commons-cli</groupId>
<artifactId>commons-cli</artifactId>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.google.jimfs</groupId>
<artifactId>jimfs</artifactId>
<version>1.3.0</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.sisu</groupId>
<artifactId>sisu-maven-plugin</artifactId>
</plugin>
[MNG-8283] Maven CLIng (#1750) New CLI for Maven. Goals are reusability, extensibility and easier embeddability (a la mvnd). If you build this branch, you will end up with Maven distro that uses "new" `maven-cli:org.apache.maven.cling.MavenCling` class as entry point instead of "old" `maven-embedder:org.apache.maven.cli.MavenCli`. First step is to make "pretty much equivalent" capable CLI as compared to "old", with some exceptions: * "encryption" ops are gone, those should be in separate tool anyway * "deprecated and unsupported" CLI options like `-llr` present ONLY to make Maven fail are gone (now Arg parser will fail). Current state of affairs is messy, MavenCli mixes everything it can, contains interleaved logic for bootstrapping, arg parsing, default logic and executing Maven. First goal is to clean this up. Commons CLI are also hidden in this PR, so is ClassWorlds. This basically opens up way to have "alternative" CLI arguments parsers as well. Currently the "local" (CLI) flow is this: ``` arg[] -> localParser -> Request -> localInvoker -> maven runs (in situ) ``` But the point is if you "come up" somehow with a Request instance, one can also do just: ``` Request -> invoker -> maven runs (somewhere) ``` Local parser: * parses CLI args * infers the defaults * creates Request object that contains all information needed to run Maven * can be reused outside of CLI as well * does NOT fiddle with Plexus, logging, etc. Local invoker: * accepts Request object * deals with configuring env (logging, etc), creating DI container, and running Maven ONLY There are some experiments ongoing as well, like `ForkedInvoker` is, but also `MavenTool`. --- https://issues.apache.org/jira/browse/MNG-8283
2024-10-03 12:03:55 -04:00
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>org.apache.maven.cling.MavenCling</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemPropertyVariables>
<maven.home>${maven.home}</maven.home>
</systemPropertyVariables>
</configuration>
</plugin>
</plugins>
</build>
</project>