paketo-buildpacks/maven

A Cloud Native Buildpack that builds Maven-based applications from source

gcr.io/paketo-buildpacks/maven

The Paketo Buildpack for Maven is a Cloud Native Buildpack that builds Maven-based applications from source.

Behavior

This buildpack will participate if all the following conditions are met:

• Another buildpack requires maven, jvm-application-package or both
• <APPLICATION_ROOT>/pom.xml exists or BP_MAVEN_POM_FILE is set to an existing POM file.

The buildpack will do the following:

• Requests that a JDK be installed
• Links the ~/.m2 to a layer for caching
• If <APPLICATION_ROOT>/mvnw does not exist and mvn is not on $PATH
  • Contributes Maven or Maven Daemon to a layer with all commands on $PATH
  • Runs <MAVEN_ROOT>/bin/mvn -Dmaven.test.skip=true --no-transfer-progress package to build the application
  • Caches $BP_MAVEN_BUILT_ARTIFACT to a layer
• If <APPLICATION_ROOT>/mvnw exists
  • Runs <APPLICATION_ROOT>/mvnw -Dmaven.test.skip=true --no-transfer-progress package to build the application
  • Caches $BP_MAVEN_BUILT_ARTIFACT to a layer
• If mvn is on $PATH
  • Runs mvn -Dmaven.test.skip=true --no-transfer-progress package to build the application
  • Caches $BP_MAVEN_BUILT_ARTIFACT to a layer
• Removes the source code in <APPLICATION_ROOT>, following include/exclude rules
• If $BP_MAVEN_BUILT_ARTIFACT matched a single file
  • Restores $BP_MAVEN_BUILT_ARTIFACT from the layer, expands the single file to <APPLICATION_ROOT>
• If $BP_MAVEN_BUILT_ARTIFACT matched a directory or multiple files
  • Restores the files matched by $BP_MAVEN_BUILT_ARTIFACT to <APPLICATION_ROOT>
• If $BP_JAVA_INSTALL_NODE is set to true and the buildpack finds one of the following at <APPLICATION_ROOT> or at the path set by $BP_NODE_PROJECT_PATH:
  • a yarn.lock file, the buildpack requests that yarn and node are installed at build time
  • a package.json file, the buildpack requests that node is installed at build time

Configuration

Environment Variable	Description
$BP_MAVEN_VERSION	Configure the major Maven version (e.g. 3, 4). Since the buildpack only ships a single version of each supported line, updates to the buildpack can change the exact version of Maven installed. If you require a specific minor/patch version of Maven, use the Maven wrapper instead.
$BP_MAVEN_BUILD_ARGUMENTS	Configure the arguments to pass to Maven. Defaults to -Dmaven.test.skip=true --no-transfer-progress package. --batch-mode will be prepended to the argument list in environments without a TTY.
$BP_MAVEN_ADDITIONAL_BUILD_ARGUMENTS	Configure the additionnal arguments (e.g. -DskipJavadoc; appended to BP_MAVEN_BUILD_ARGUMENTS) to pass to Maven. Defaults to `` (empty string).
$BP_MAVEN_ACTIVE_PROFILES	Configure the active profiles (comma separated: e.g. p1,!p2,?p3) to pass to Maven. Defaults to `` (empty string).
$BP_MAVEN_BUILT_MODULE	Configure the module to find application artifact in. Defaults to the root module (empty).
$BP_MAVEN_BUILT_ARTIFACT	Configure the built application artifact explicitly. Supersedes $BP_MAVEN_BUILT_MODULE Defaults to target/*.[ejw]ar. Can match a single file, multiple files or a directory. Can be one or more space separated patterns.
$BP_MAVEN_POM_FILE	Specifies a custom location to the project's pom.xml file. It should be a full path to the file under the /workspace directory or it should be relative to the root of the project (i.e. /workspace'). Defaults to pom.xml`.
$BP_MAVEN_DAEMON_ENABLED	Triggers apache maven-mvnd to be installed and configured for use instead of Maven. The default value is false. Set to true to use the Maven Daemon.
$BP_MAVEN_SETTINGS_PATH	Specifies a custom location to Maven's settings.xml file. If $BP_MAVEN_SETTINGS_PATH is set and a Maven binding is provided, the binding takes the higher precedence.
$BP_INCLUDE_FILES	Colon separated list of glob patterns to match source files. Any matched file will be retained in the final image. Defaults to `` (i.e. nothing).
$BP_EXCLUDE_FILES	Colon separated list of glob patterns to match source files. Any matched file will be specifically removed from the final image. If include patterns are also specified, then they are applied first and exclude patterns can be used to further reduce the fileset.
$BP_JAVA_INSTALL_NODE	Configure whether to request that yarn and node are installed by another buildpack**. If set to true, the buildpack will check the app root or path set by $BP_NODE_PROJECT_PATH for either: A yarn.lock file, which requires that yarn and node are installed or, a package.json file, which requires that node is installed. Defaults to false
$BP_NODE_PROJECT_PATH	Configure a project subdirectory to look for package.json and yarn.lock files

Note

** If the node and/or yarn requirements are met and the Node Engine or Yarn participate in the build, environment variables related to these buildpacks can be set, such as BP_NODE_PROJECT_PATH or BP_NODE_VERSION. See the Paketo Node.js docs for more info.

Bindings

The buildpack optionally accepts the following bindings:

Type: maven

Secret	Description
settings.xml	If present --settings=<path/to/settings.xml> is prepended to the maven arguments
settings-security.xml	If present -Dsettings.security=<path/to/settings-security.xml> is prepended to the maven arguments

Type: dependency-mapping

Key	Value	Description
<dependency-digest>	<uri>	If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

License

This buildpack is released under version 2.0 of the Apache License.

maven's Issues

[feature request] support multiple artifacts of different types.

What happened?

The maven buildpack is expecting a single build artifact of type either jar or war, which can be explicitly configured using BP_MAVEN_BUILT_ARTIFACT.
This artifact will be extracted and passed on to downstream buildpacks, like the native image buildpack.

The argument BP_MAVEN_BUILD_ARGUMENTS="-Dmaven.test.skip=true -Dquarkus.package.type=native-sources package", to create Quarkus native image sources for a separate native image build, will generate multiple artifacts that are required to build a native image eventually with the native image buildpack:

target/native-sources/native-image.args
target/native-sources/lib/
target/native-sources/getting-started-1.0.0-SNAPSHOT-runner.jar

A potential solution for this usecase, and maybe others, is to allow passing a list of artifacts to BP_MAVEN_BUILT_ARTIFACT, which items are either extracted (jar or war) or copied (e.g. lib folder)

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

• What buildpacks are you using? Please include versions.
  TBS

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Allow defining .m2 path for improved caching

• What were you attempting to do?

As stated here it is very common for gitlab CI builds to redefine the .m2 path, as it must be located within the build directory to be cachable by gitlab.

Alas, your build-pack is referring to ~/.m2 only, which is empty, when trying to re-use downloaded dependencies. This leads to re-downloading every dependency on every build.

Please provide a method for overrding the .m2 location when using this build pack.

Unable to parse command line options: Unrecognized option: --no-transfer-progress

What happened?

Spring Boot build failing with Unrecognized option: --no-transfer-progress
during maven buildpack stage

• What were you attempting to do?
  Pack build
• What did you expect to happen?
  Successful build
• What was the actual behavior? Please provide log output, if possible.
  Paketo Maven Buildpack 6.5.0
  https://github.com/paketo-buildpacks/maven
  Build Configuration:
  $BP_MAVEN_BUILD_ARGUMENTS -Dmaven.test.skip=true --no-transfer-progress package the arguments to pass to Maven
  $BP_MAVEN_BUILT_ARTIFACT target/*.[ejw]ar the built application artifact explicitly. Supersedes $BP_MAVEN_BUILT_MODULE
  $BP_MAVEN_BUILT_MODULE the module to find application artifact in
  $BP_MAVEN_DAEMON_ENABLED false use maven daemon
  $BP_MAVEN_POM_FILE pom.xml the location of the main pom.xml file, relative to the application root
  Creating cache directory /home/cnb/.m2
  Compiled Application: Contributing to layer
  Executing mvnw --batch-mode -Dmaven.test.skip=true --no-transfer-progress package
  /workspace
  Downloading https://repo1.maven.org/maven2/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-bin.zip
  .............................................................................................................................................................................................................................................................................................................................................................................................................................................................
  Unzipping /home/cnb/.m2/wrapper/dists/apache-maven-3.5.2-bin/28qa8v9e2mq69covern8vmdkj0/apache-maven-3.5.2-bin.zip to /home/cnb/.m2/wrapper/dists/apache-maven-3.5.2-bin/28qa8v9e2mq69covern8vmdkj0
  Set executable permissions for: /home/cnb/.m2/wrapper/dists/apache-maven-3.5.2-bin/28qa8v9e2mq69covern8vmdkj0/apache-maven-3.5.2/bin/mvn
  Unable to parse command line options: Unrecognized option: --no-transfer-progress
  usage: mvn [options] [<goal(s)>] [<phase(s)>]
  Options:
  -am,--also-make If project list is specified, also
  build projects required by the
  list
  -amd,--also-make-dependents If project list is specified, also
  build projects that depend on
  projects on the list
  -B,--batch-mode Run in non-interactive (batch)
  mode (disables output color)
  -b,--builder The id of the build strategy to
  use
  -C,--strict-checksums Fail the build if checksums don't
  match
  -c,--lax-checksums Warn if checksums don't match
  -cpu,--check-plugin-updates Ineffective, only kept for
  backward compatibility
  -D,--define Define a system property
  -e,--errors Produce execution error messages
  -emp,--encrypt-master-password Encrypt master security password
  -ep,--encrypt-password Encrypt server password
  -f,--file Force the use of an alternate POM
  file (or directory with pom.xml)
  -fae,--fail-at-end Only fail the build afterwards;
  allow all non-impacted builds to
  continue
  -ff,--fail-fast Stop at first failure in
  reactorized builds
  -fn,--fail-never NEVER fail the build, regardless
  of project result
  -gs,--global-settings Alternate path for the global
  settings file
  -gt,--global-toolchains Alternate path for the global
  toolchains file
  -h,--help Display help information
  -l,--log-file Log file where all build output
  will go (disables output color)
  -llr,--legacy-local-repository Use Maven 2 Legacy Local
  Repository behaviour, ie no use of
  _remote.repositories. Can also be
  activated by using
  -Dmaven.legacyLocalRepo=true
  -N,--non-recursive Do not recurse into sub-projects
  -npr,--no-plugin-registry Ineffective, only kept for
  backward compatibility
  -npu,--no-plugin-updates Ineffective, only kept for
  backward compatibility
  -nsu,--no-snapshot-updates Suppress SNAPSHOT updates
  -o,--offline Work offline
  -P,--activate-profiles Comma-delimited list of profiles
  to activate
  -pl,--projects Comma-delimited list of specified
  reactor projects to build instead
  of all projects. A project can be
  specified by [groupId]:artifactId
  or by its relative path
  -q,--quiet Quiet output - only show errors
  -rf,--resume-from Resume reactor from specified
  project
  -s,--settings Alternate path for the user
  settings file
  -t,--toolchains Alternate path for the user
  toolchains file
  -T,--threads Thread count, for instance 2.0C
  where C is core multiplied
  -U,--update-snapshots Forces a check for missing
  releases and updated snapshots on
  remote repositories
  -up,--update-plugins Ineffective, only kept for
  backward compatibility
  -v,--version Display version information
  -V,--show-version Display version information
  WITHOUT stopping build
  -X,--debug Produce execution debug output
  unable to invoke layer creator
  unable to contribute application layer
  error running build
  exit status 1
  ERROR: failed to build: exit status 1
  ERROR: failed to build: executing lifecycle: failed with status code: 51

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.
  pack 0.25.0

• What buildpacks are you using? Please include versions.
  maven build pack

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?
  paketobuildpacks/builder:base

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

Checklist

• [* ] I have included log output.
• [ *] The log output includes an error message.
• [* ] I have included steps for reproduction.

Enable use of maven repository mirrors

As a user of this buildpack I want to use a local mirror as drop in replacement for e.g. maven central. We use Artifactory for this.

To do so it would be very smooth to configure an alternative mirror via environment variables.

Allow setting maven repositories on a buildpack/stack level

Describe the Enhancement

There are often times when the user/operator/stack provider would want an easy way to specify the maven settings file to a file path in the builder/workspace which doesn't contain any credentials. For eg. changing the maven repositories.

Maven BP currently allows this via a binding, but bindings must be set by a user and cannot be set by the operator or BP author in anyway.

Possible Solution

Expose a BP_MAVEN_SETTINGS_PATH env var that allows you to do this for all builds, regardless of whether the user mounted a maven binding or not.

In case the user did mount a maven binding, it overrides the path specified by BP_MAVEN_SETTINGS_PATH.

Motivation

Support maven buildpack in enterprise settings.

Make it easier to add to the default Maven arguments

Describe the Enhancement

It is currently possible to set the arguments that will be passed to Maven using the BP_MAVEN_BUILD_ARGUMENTS environment variable. It is often desirable to add arguments to the Maven command without changing the default arguments. Activating Maven build profiles is a common use case for this.

Possible Solution

If Maven build profiles is considered the most common use case for adding arguments, then support for a new environment variable like BP_MAVEN_ACTIVE_PROFILES could be added to the buildpack. The value of the environment variable would be a comma-separated list of profiles, and the buildpack would append -P <value> to the arguments list.

A more general solution would be to add support for an environment variable like BP_MAVEN_ADDITIONAL_BUILD_ARGUMENTS. The value of this environment variable would be appended to the value of BP_MAVEN_BUILD_ARGUMENTS to get the full list of arguments.

Motivation

Overriding the entire maven command line makes it difficult to keep the build argument in sync with the Paketo buildpack defaults. Being able to more simply add arguments would ensure that default are retained.

Maven build profiles can be activated in a Maven settings.xml file that can be provided to the buildpack as a binding or with BP_MAVEN_SETTINGS_PATH. This is a useful feature, but is a bit heavy-weight if the user only wants to activate build profiles.

Add support for encrypted maven credentials

In many situations, when working with private repositories, there is a need to use encrypted maven credentials. Such setup requires having the file settings-security.xml additional to settings.xml in ~/.m2. Hence, I propose to modify the maven binding to include both files.

The implementation would be quite simple since the security settings can be passed to Maven with the system property settings.security. For instance:

mvn -s ~/.credentials/settings.xml -Dsettings.security=~/.credentials/settings-security.xml package

Support external cache location

If a user is running pack locally, or perhaps wants to do a very dangerous thing and share a cache across multiple platforms, this should be possible. If <platform>/maven exists, it should be used for the cache.

Document Include/Exclude files

With libbs 1.16.0, there is now support for including and excluding files. This needs to be documented in the Readme and also Paketo docs.

It needs to be documented for the other four libbs based Buildpacks as well.

Changes to env vars are not triggering re-execution of buildpack

Example:

SETUP: Add to pom.xml:

    <profiles>
        <profile>
            <id>test</id>
            <build>
                <resources>
                    <resource>
                        <directory>src/main/resources</directory>
                        <excludes>
                            <exclude>application.yml</exclude>
                        </excludes>
                    </resource>
                </resources>
            </build>
        </profile>
    </profiles>

FIRST BUILD:
pack build my-app --clear-cache
TEST:
docker run -it --entrypoint find my-app workspace -name application.yml
workspace/BOOT-INF/classes/application.yml

SECOND BUILD:
pack build my-app --env BP_MAVEN_BUILD_ARGUMENTS="-Dmaven.test.skip=true clean package -P test"
TEST AGAIN:
docker run -it --entrypoint find my-app workspace -name application.yml
workspace/BOOT-INF/classes/application.yml

In contrast, on my local machine, a ./mvnw clean package -P test results in a new jar without the excluded file.

Can also see the buildpack uses cache the second time:

[builder] Paketo Maven Buildpack 1.2.1
[builder]     Set $BP_MAVEN_SETTINGS to configure the contents of a settings.xml file. Default <none>.
[builder]     Set $BP_MAVEN_BUILD_ARGUMENTS to configure the arguments passed to the build system. Default -Dmaven.test.skip=true package.
[builder]     Set $BP_MAVEN_BUILT_MODULE to configure the module to find application artifact in. Default <ROOT>.
[builder]     Set $BP_MAVEN_BUILT_ARTIFACT to configure the built application artifact. Default target/*.[jw]ar.
[builder]     Creating cache directory /home/cnb/.m2
[builder]   Compiled Application: Reusing cached layer
[builder]   Removing source code

Let maven access the .git directory

We use the maven commit-id plugin to push git version information inside every build so that build can be traced back to commit-id. This plugin takes git metadata from .git directory and creates a files that's inserted into the build. However, buildpacks apparently does not keep the .git directory visible/accessible to the build process and hence the maven plugin fails to work. Leading to the error:
Failed to execute goal pl.project13.maven:git-commit-id-plugin:4.9.10:revision (default) on project fooservice: .git directory is not found! Please specify a valid [dotGitDirectory] in your pom.xml

Note: We use kpack for build

Describe the Enhancement

It would be nice if the .git directory remains accessible by the build process. Many build scripts would expect that directory to be present for a similar requirement.

Possible Solution

Please let the .git directory be accessible to the build process. If that can't be made the default, provide a flag to do so.

Motivation

Baking source commit-id info into a build is a common practice. It helps in debugging/reporting issues. I read about the git build-pack. It puts commit id into an environment variable. But I can't use that as I need a git.proerties file that the above plugin generates. This file is later used by Spring (framework) at runtime to present build information at a specific http endpoint.

Add Support to extract reports generated by Surefire/Failsafe/Jacoco Plugin

What happened?

When you run mvn clean package, if you have surefire/failsafe/jacoco plugin (which includes test coverage), there isn't a way to view or extract those coverage reports using Maven Buildpacks

• What were you attempting to do?
  Trying to extract those coverage reports so that it can be feed into another code coverage tools so that Jenkins can
  https://plugins.jenkins.io/code-coverage-api/

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Maven wrapper not executable when building on Windows

@dmikusa-pivotal : Daniel, I can confirm the above error!. I did a clean install of everything (like a new user just trying out CNB for first time). Unfortunately the experience was not great as the sample build fails.

I used the CNB sample from "https://github.com/paketo-buildpacks/samples/java/maven" and it will not build on a windows 10 machine with Docker Desktop (latest) using WSL2 as backend. I'm using the latest pack (0.19.0+git-360dbae.build-2550) with pack config default-builder paketobuildpacks/builder:base ....

After googling for the error I found this thread and I deleted mvnw and the build completed!

Dave

Originally posted by @dtillman in #6 (comment)

Support ability to use cyclonedx-maven-plugin

Currently, Syft is used to generate SBOMs. The fidelity of the resulting SBOM is very low. It does not contain provenance information of included dependencies. This information is typically included in the case of CycloneDX when leveraging the CycloneDX maven plugin as a part of the build. Maven plugins usually have access to the entire dependency graph during build time which means the SBOM contains information that can only be discovered during build time:

• issue URLs
• maven repository containing the resolved dependencies
• project pages
• test dependencies

Describe the Enhancement

Allow a maven build to contribute a CycloneDX document generated during build time.

Possible Solution

Java buildpack could discover a file such as ${project.artifactId}-${project.version}-cyclonedx.xml or ${project.artifactId}-${project.version}-cyclonedx.json and include it in the resulting cnb-sboms layer.

Motivation

CycloneDX documents generated during the maven build process will have access to more information about dependencies that can be fed into the bill of material CycloneDX document.

[builder] Error: Processing ... This may be the result of using an untrusted builder: failed with status code: 51

After downloads the errors:
[builder] Error: Processing jar:file:///workspace/BOOT-INF/lib/gax-2.19.4.jar!/META-INF/native-image/com.google.api/gax/native-image.properties failed [builder] Caused by: com.oracle.svm.driver.NativeImage$NativeImageError: Property 'Args' contains invalid entry '--add-modules=jdk.httpserver' [builder] unable to invoke layer creator [builder] unable to contribute native-image layer [builder] error running build [builder] exit status 1 [builder] ERROR: failed to build: exit status 1 ERROR: failed to build: executing lifecycle. This may be the result of using an untrusted builder: failed with status code: 51

appear and the builder stops
basically everything fails after long string of [builder] Executing native-image -H:+StaticExecutableWithDynamicLibC -H:Name=/layers/paketo-buildpacks_native-image/native-image

Motivations

i've been trying to make the native image(to reduce my image RAM usage) jar using:

pack build sample_app --env BP_NATIVE_IMAGE=true --env BP_JVM_VERSION=17 --builder paketobuildpacks/builder:0.1.136-tiny

while using --builder paketobuildpacks/builder:base instead of tiny one the errors are different such as:
Caused by: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances of ch.qos.logback.classic.Logger are allowed in the image heap as this class should be initialized at image runtime. To see how this object got instantiated use --trace-object-instantiation=ch.qos.logback.classic.Logger.

paketobuildpacks/builder:full on the other hand also granted those kind of errors:
Caused by: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances of ch.qos.logback.classic.Logger are allowed in the image heap as this class should be initialized at image runtime. To see how this object got instantiated use --trace-object-instantiation=ch.qos.logback.classic.Logger.

Support distribution of binaries

We have need for mvn or mvnd to be distributed on a build layer. This makes a maven binary available for subsequent buildpacks to use. In this scenario, the source project does not necessarily contain a pom.xml.

Describe the Enhancement

The enhancement allows the maven buildpack to operate as a distribution buildpack. Subsequent buildpacks can use the maven binary to perform maven operations.

Possible Solution

The maven buildpack could succeed to detect if BP_MAVEN_COMMAND is set to either mvn or mvnd. During the build phase, if BP_MAVEN_COMMAND is set to either mvn or mvnd then the corresponding binary is contributed as a build layer.

A buildpack that requires the maven buildpack might be expected to explicitly set a flag to disable running the maven command. The default operation of the buildpack, in the absence of the flag, would continue to run the build command.

Requires: []libcnb.BuildPlanRequire{
	{
		Name: maven.PlanEntryMaven,
		Metadata: map[string]interface{}{
			"RunBuild": false,
		},
	},
}

The current cache layer on which mvn/mvd are distributed would be made available as a build and cache layer.

Motivation

Our motivation is to support injection of Jars into an application image in a non-JVM source project. For example, python is a common language for data science projects and data science projects in python often use PySpark for distributed computation. Such use-cases commonly need to install a single Jar file, or a small number of Jar files, and make them available in the CLASSPATH. The set of Jars to install depend on the dependencies used in the Python project. Application developers do not want to manage both a python build system and a maven/gradle/sbt build system. Supporting a "distribution only" operation in the maven buildpack allows us to provide a subsequent buildpack to detect a PySpark project and inject appropriate Jar files.

Given this motivation, a data-science oriented build image might set BP_MAVEN_COMMAND=mvn by default. The buildpack that contributes the Jars would depend on the maven buildpack and set RunBuild: false. This moves the problem of managing dependencies in a pom.xml from the data-scientist to the platform operator.

Add support for Maven 4

Describe the Enhancement

Maven 4 is in alphas. We will need to keep Maven 3 around for a while, so we should add Maven 4 to buildpack.toml so we can support both at the same time.

https://maven.apache.org/ref/4-LATEST/

Possible Solution

Add Maven 4 to buildpack.toml & adjust CI so that it tracks both major releases.

Motivation

Maven 4 is a new major branch & folks will likely want to use it.

How can we debug using IntelliJ the go binary detect or build ?

Problem

How can we debug using IntelliJ the buildpack detect or build executable ?

When the project is compiled and next dlv debugger launched by intellij, then we got this error unsupported command ___detect as the first argument passed is not detect but a temp file generated /private/var/folders/t2/jwchtqkn5y76hrfrws7dqtqm0000gn/T/___detect

Main code of libcnf

libcnf/main.go is doing the following check

	switch c := filepath.Base(config.arguments[0]); c {
	case "build":
		Build(builder, options...)
	case "detect":
		Detect(detector, options...)
	default:
		config.exitHandler.Error(fmt.Errorf("unsupported command %s", c))
		return
	}

Error generated by IntelliJ

GOROOT=/usr/local/Cellar/go/1.16.4/libexec #gosetup
GOPATH=/Users/cmoullia/code/golang #gosetup
/usr/local/Cellar/go/1.16.4/libexec/bin/go build -o /private/var/folders/t2/jwchtqkn5y76hrfrws7dqtqm0000gn/T/___detect -gcflags all=-N -l /Users/cmoullia/code/cncf/paketo-debug/cmd/main/main.go #gosetup
"/Users/cmoullia/Library/Application Support/JetBrains/IntelliJIdea2021.1/plugins/go/lib/dlv/mac/dlv" --listen=0.0.0.0:59477 --headless=true --api-version=2 --check-go-version=false --only-same-user=false exec /private/var/folders/t2/jwchtqkn5y76hrfrws7dqtqm0000gn/T/___detect --
API server listening at: [::]:59477
debugserver-@(#)PROGRAM:LLDB  PROJECT:lldb-1200.0.44
 for x86_64.
Got a connection, launched process /private/var/folders/t2/jwchtqkn5y76hrfrws7dqtqm0000gn/T/___detect (pid = 34778).
unsupported command ___detect
Exiting.

Workaround

A possible workaround is to first build the go project

$home/code/cncf/paketo-maven
go build -o detect -gcflags all='-N -l' ./cmd/main/main.go

and next set 2 ENV VAR and use a remote debugger where we pass the location of platform_dir and build.toml used to export the plan

export CNB_BUILDPACK_DIR=/Users/cmoullia/code/cncf/paketo-maven
export CNB_STACK_ID=1
dlv --listen=:2345 --headless=true --api-version=2 --accept-multiclient exec ./detect ./tmp/platform ./tmp/build.toml

There is nevertheless an issue as the path of the application to be build is not customisable as during the execution of the detect.go fil, then the ctx.Application.path is set using os.Getwd().

See: https://github.com/buildpacks/libcnb/blob/main/detect.go#L93

how to add local dependecy

Currently, this is my project structure:

.
├── hes-mpi-fhir-mongodb
│  ├── deployment.yaml
│  ├── pom.xml
│  ├── skaffold.yaml
│  └──  src
└── hes-spring-boot-core     <<< dependency requiered by hes-mpi-fhir-mongodb
   ├── pom.xml
   └── src

As you can see, I managing two maven projects.

My host building steps are:

$ hes-spring-boot-core > mvn clean install
$ hes-mpi-fhir-mongodb > mvn clean package

I mean, I first install hes-spring-boot-core into local repository and then I build hes-mpi-fhir-mongodb:

My skaffold.yml file is:

apiVersion: skaffold/v2beta26
kind: Config
metadata:
  name: hes-mpi-fhir-mongodb
build:
  artifacts:
  - image: pom-xml-image
    buildpacks:
      builder: paketobuildpacks/builder:tiny 
deploy:
  kubectl:
    manifests:
    - deployment.yaml

I've also tried to perform:

$ pack build fhir-mongo --builder paketobuildpacks/builder:tiny 

I'm getting this message, when I'm trying to build image:

...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  55.841 s
[INFO] Finished at: 2022-01-03T22:43:22Z
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project hes-mpi-fhir-mongodb-service: Could not resolve dependencies for project cat.gencat.catsalut.hes.mpi.fhir:hes-mpi-fhir-mongodb-service:jar:0.0.1-SNAPSHOT: Could not find artifact cat.gencat.catsalut.hes:hes-spring-boot-core:jar:1.0.6 in central (https://repo.maven.apache.org/maven2) -> [Help 1]

It's getting me that maven builder is not able to find artifact cat.gencat.catsalut.hes:hes-spring-boot-core:jar:1.0.6.

How can I add this project a dependency?

I'm using skaffold v1.35.1 and pack 0.23.0+git-0db2c77.build-3056.

Unable to parse command line options: Unrecognized option: --no-transfer-progress

What happened?

When I use maven buildpack to build a JAVA project(https://github.com/Azure-Samples/spring-petclinic-microservices), an error happened like this

...
Paketo Maven Buildpack 6.5.0
  https://github.com/paketo-buildpacks/maven
  Build Configuration:
    $BP_MAVEN_BUILD_ARGUMENTS  -Dmaven.test.skip=true --no-transfer-progress package  the arguments to pass to Maven
    $BP_MAVEN_BUILT_ARTIFACT   target/*.[ejw]ar                                       the built application artifact explicitly.  Supersedes $BP_MAVEN_BUILT_MODULE
    $BP_MAVEN_BUILT_MODULE     ./spring-petclinic-customers-service                   the module to find application artifact in
    $BP_MAVEN_DAEMON_ENABLED   false                                                  use maven daemon
    $BP_MAVEN_POM_FILE         pom.xml                                                the location of the main pom.xml file, relative to the application root
    Creating cache directory /home/cnb/.m2
  Compiled Application: Contributing to layer
    Executing mvnw --batch-mode -Dmaven.test.skip=true --no-transfer-progress package
      Unable to parse command line options: Unrecognized option: --no-transfer-progress

      usage: mvn [options] [<goal(s)>] [<phase(s)>]

      Options:
       -am,--also-make                        If project list is specified, also
                                              build projects required by the
                                              list
       -amd,--also-make-dependents            If project list is specified, also
                                              build projects that depend on
                                              projects on the list
       -B,--batch-mode                        Run in non-interactive (batch)
                                              mode (disables output color)
       -b,--builder <arg>                     The id of the build strategy to
                                              use
       -C,--strict-checksums                  Fail the build if checksums don't
                                              match
       -c,--lax-checksums                     Warn if checksums don't match
       -cpu,--check-plugin-updates            Ineffective, only kept for
                                              backward compatibility
       -D,--define <arg>                      Define a system property
       -e,--errors                            Produce execution error messages
       -emp,--encrypt-master-password <arg>   Encrypt master security password
       -ep,--encrypt-password <arg>           Encrypt server password
       -f,--file <arg>                        Force the use of an alternate POM
                                              file (or directory with pom.xml)
       -fae,--fail-at-end                     Only fail the build afterwards;
                                              allow all non-impacted builds to
                                              continue
       -ff,--fail-fast                        Stop at first failure in
                                              reactorized builds
       -fn,--fail-never                       NEVER fail the build, regardless
                                              of project result
       -gs,--global-settings <arg>            Alternate path for the global
                                              settings file
       -gt,--global-toolchains <arg>          Alternate path for the global
                                              toolchains file
       -h,--help                              Display help information
       -l,--log-file <arg>                    Log file where all build output
                                              will go (disables output color)
       -llr,--legacy-local-repository         Use Maven 2 Legacy Local
                                              Repository behaviour, ie no use of
                                              _remote.repositories. Can also be
                                              activated by using
                                              -Dmaven.legacyLocalRepo=true
       -N,--non-recursive                     Do not recurse into sub-projects
       -npr,--no-plugin-registry              Ineffective, only kept for
                                              backward compatibility
       -npu,--no-plugin-updates               Ineffective, only kept for
                                              backward compatibility
       -nsu,--no-snapshot-updates             Suppress SNAPSHOT updates
       -o,--offline                           Work offline
       -P,--activate-profiles <arg>           Comma-delimited list of profiles
                                              to activate
       -pl,--projects <arg>                   Comma-delimited list of specified
                                              reactor projects to build instead
                                              of all projects. A project can be
                                              specified by [groupId]:artifactId
                                              or by its relative path
       -q,--quiet                             Quiet output - only show errors
       -rf,--resume-from <arg>                Resume reactor from specified
                                              project
       -s,--settings <arg>                    Alternate path for the user
                                              settings file
       -t,--toolchains <arg>                  Alternate path for the user
                                              toolchains file
       -T,--threads <arg>                     Thread count, for instance 2.0C
                                              where C is core multiplied
       -U,--update-snapshots                  Forces a check for missing
                                              releases and updated snapshots on
                                              remote repositories
       -up,--update-plugins                   Ineffective, only kept for
                                              backward compatibility
       -v,--version                           Display version information
       -V,--show-version                      Display version information
                                              WITHOUT stopping build
       -X,--debug                             Produce execution debug output
unable to invoke layer creator
unable to contribute application layer

...

I see the README.md show that

If <APPLICATION_ROOT>/mvnw exists
Runs <APPLICATION_ROOT>/mvnw -Dmaven.test.skip=true --no-transfer-progress package to build the application

The maven version in Paketo Maven Buildpack 6.5.0 is 3.8.5, it should support --no-transfer-progress, so why does the buildpack report this error log?

and what went wrong. -->

• What were you attempting to do?

Repo: https://github.com/Azure-Samples/spring-petclinic-microservices

Paketo Maven Buildpack version: 6.5.0

build the app with this maven version.

• What did you expect to happen?
  build successfully.

• What was the actual behavior? Please provide log output, if possible.
  Error happened:

   Executing mvnw --batch-mode -Dmaven.test.skip=true --no-transfer-progress package
      Unable to parse command line options: Unrecognized option: --no-transfer-progress

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

kpack 0.5.2

• What buildpacks are you using? Please include versions.

tanzu-buildpacks/java-azure: 7.20.0

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

`Detect` incorrectly detects non-maven apps

Hello,

We have a simple nodejs
app
that we build with paketo. Recently we discovered that the build suddenly started
to fail because of failures in the maven buildpack:

...
build Paketo Buildpack for Maven 6.10.0
build   https://github.com/paketo-buildpacks/maven
build   Build Configuration:
build     $BP_EXCLUDE_FILES                                                                 colon separated list of glob patterns, matched source files are removed
build     $BP_INCLUDE_FILES                                                                 colon separated list of glob patterns, matched source files are included
build     $BP_MAVEN_BUILD_ARGUMENTS  -Dmaven.test.skip=true --no-transfer-progress package  the arguments to pass to Maven
build     $BP_MAVEN_BUILT_ARTIFACT   target/*.[ejw]ar                                       the built application artifact explicitly.  Supersedes $BP_MAVEN_BUILT_MODULE
build     $BP_MAVEN_BUILT_MODULE                                                            the module to find application artifact in
build     $BP_MAVEN_DAEMON_ENABLED   false                                                  use maven daemon
build     $BP_MAVEN_POM_FILE         pom.xml                                                the location of the main pom.xml file, relative to the application root
build     $BP_MAVEN_SETTINGS_PATH                                                           the path to a Maven settings file
build     Creating cache directory /home/cnb/.m2
build   Compiled Application: Contributing to layer
build     Executing . --batch-mode -Dmaven.test.skip=true --no-transfer-progress package
build unable to invoke layer creator
build unable to contribute application layer
build error running build
build unable to start PTY
build exec: no command
build ERROR: failed to build: exit status 1

We thought it was weird to see the maven buildpack participating in the build
so we had a look at a test environment where older maven buildpack is deployed.
We configrmed that at this environment the maven buildpack is not
participating.

Therefore we created a
test
that runs Detect on the app. When ran with maven buildpack v6.8.0 the test
succeeds, i.e. Detect correctly determines that this is not a maven app.
However, with v6.9.0 onwards the test fails, i.e. Detect "believes" that this
is a maven app, hence the failure above.

Expected Behavior

The test above succeeds

Current Behavior

The test fails

Possible Solution

Detect should return an empty result for the sample app (thus making the test
happy)

Steps to Reproduce

1. Apply the commit above
2. Run go test ./...
3. See it fail

Motivations

This seems like an incompatible change that breaks the build of apps that used
to build fine. In order to mitigate it we have pinned the previous version of
the java paketo buildpack but this is just a temporary solution.

cc @georgethebeatle

Look for settings.xml in <platform>/maven/settings.xml

Currently, in order to contribute a settings.xml file to the build, you set $BP_MAVEN_SETTINGS with the content of the file you’d like. This content is then written to a temporary file and used during the build. A better solution to this would be to expose it via a binding:

<platform>
└── bindings
    └── <name>
        └── metadata
            └── kind -> "maven"
        └── secret
            └── settings.xml

To make this change, the following steps (and possibly more) are required:

• Remove configuration documentation
• Update behavior documentation
• Remove the configuration logging
• Remove settings layer
• Prepend location to arguments if it exists
• Include a hash of the contents of the file in the application’s expected metadata so that the compiled application will be invalidated if the contents of the file changes (moved to #3)

Add license information for Maven dependencies to the BOM

What happened?

Right now, the BOM shows the name, sha256 hash, and version for Maven dependencies. It would be helpful if the BOM also included information like the project license type.

• What were you attempting to do?

Get a comprehensive list of licenses used by dependencies.

• What was the actual behavior? Please provide log output, if possible.

See summary above.

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

All

• What buildpacks are you using? Please include versions.

Maven

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

Paketo

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Fix executable permission for the maven wrapper before invoking the wrapper

If we archive the source code to a tar.gz ball in Windows, it's likely we will lost the execute permission bit of the Maven wrapper (mvnw).

When the maven buildpack starts the build, it checks the existence of the maven wrapper mvnw, but it does not check the executable permission. During the build, we see the following error:

Pivotal Build System Buildpack 1.0.97
  fork/exec /workspace/mvnw: permission denied

We may need either

• skip mvnw if it's not marked as executable
• or, set the execution permission of the file before we start the build.

Execution fails at creating symbolic link "/.m2" instead of "~/.m2"

I'm using paketo-buildpacks/maven:6.15.11 as part of the paketobuildpacks/builder-jammy-tiny:0.0.211 image in an unprivileged manner.
The execution fails because the buildpack tries to write to the root location but has no permission to do so.

Here is the log output: log.txt

Expected Behavior

The paketo-buildpacks/maven should create it's symbolic link at "~/.m2" rather than under root.
The documentation also claims it would do so by the bullet point

• Links the ~/.m2 to a layer for caching (see here).

Current Behavior

The buildpack tries to create the symbolic link "/.m2" and fails due to a lack of permission.

Possible Solution

Always create symbolic links under the current user.
Allow defining alternative .m2 locations as mentioned in issue #58.

Include hash of settings.xml in layer metadata

Currently, the content of settings.xml during a build is not included in the decision to invalidate a layer if it changes. The buildpack should take into account changes to this file (which make significant changes to the build environment).

Depends on paketo-buildpacks/libbs#2.

chmod of mvnw causes GitLab CI build to fail

What happened?

• What were you attempting to do?

I was trying to build a vanilla Spring Boot Initializr demo application with Maven using a basic creator based GitLab job:

stages:
  - build

default:
  tags:
    - linux
    - x86_64 
 
build-image:
  stage: build
  image: paketobuildpacks/builder:base
  # Access to GitLab Container Registry for Paketo lifecycle
  before_script:
    - mkdir ~/.docker
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_JOB_TOKEN\"}}}" >> ~/.docker/config.json
  script:
    - /cnb/lifecycle/creator
      -app=.
      $CI_REGISTRY_IMAGE:latest

• What did you expect to happen?

Buildpacks to discover Spring Boot & maven app, build the OCI image and push it to my project's Container Registry.

• What was the actual behavior? Please provide log output, if possible.

The job failed while trying to add an executable flag (chmod +x) to the mvnw binary. Probably due to dropping privileges to normal user which lost write access to the directory.

Paketo Maven Buildpack 6.5.2
  https://github.com/paketo-buildpacks/maven
  Build Configuration:
    $BP_MAVEN_BUILD_ARGUMENTS  -Dmaven.test.skip=true --no-transfer-progress package  the arguments to pass to Maven
    $BP_MAVEN_BUILT_ARTIFACT   target/*.[ejw]ar                                       the built application artifact explicitly.  Supersedes $BP_MAVEN_BUILT_MODULE
    $BP_MAVEN_BUILT_MODULE                                                            the module to find application artifact in
    $BP_MAVEN_DAEMON_ENABLED   false                                                  use maven daemon
    $BP_MAVEN_POM_FILE         pom.xml                                                the location of the main pom.xml file, relative to the application root
Paketo Maven Buildpack 6.5.2
  unable to chmod /builds/librarians/developer-experience/test-for-eks/mvnw
  chmod /builds/librarians/developer-experience/test-for-eks/mvnw: operation not permitted
ERROR: failed to build: exit status 1
Cleaning up project directory and file based variables
00:01
ERROR: Job failed: exit code 1

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

  GitLab 14.10.1 calling the creator script from the paketobuildpacks/builder@sha256:eae726051f9e96855cdb8a393bc69eeb1dfc9670b4b59116eb5683f54191635a image

• What buildpacks are you using? Please include versions.

What got auto-discovered, as I've provided no suggestions to the creator script:

Warning: Not restoring or caching layer data, no cache flag specified.
===> DETECTING
9 of 24 buildpacks participating
paketo-buildpacks/ca-certificates   3.2.2
paketo-buildpacks/bellsoft-liberica 9.3.4
paketo-buildpacks/syft              1.11.0
paketo-buildpacks/maven             6.5.2
paketo-buildpacks/executable-jar    6.2.3
paketo-buildpacks/apache-tomcat     7.3.3
paketo-buildpacks/liberty           1.1.0
paketo-buildpacks/dist-zip          5.2.3
paketo-buildpacks/spring-boot       5.10.0

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

  Using docker image sha256:19ddf409a6cced9fb6447bdd1c23bc1ba6a47413f3b2915335ac7e6aaed0b87e for paketobuildpacks/builder:base with digest paketobuildpacks/builder@sha256:eae726051f9e96855cdb8a393bc69eeb1dfc9670b4b59116eb5683f54191635

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

There is nothing specific about that. Plain Spring Boot Initializr app, so almost no source code, no buildpack.yml, just pom.xml and mvnw in repo.

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Add support to specify the profile to use

My pom.xml has multiple profiles defined and I want a way to specify which one to use for my buildpack execution (and lifecycle).

Enable configuring a mirror of maven central

Describe the Enhancement

As a user of this buildpack I want to use a local mirror as drop in replacement for e.g. maven central. We use Artifactory for this.

Possible Solution

To do so it would be very smooth to configure an alternative mirror via environment variables.

https://github.com/paketo-buildpacks/maven/blob/main/buildpack.toml#L76
With this variable a user is able to replace https://repo1.maven.org/maven/ with something else.

Motivation

In our company we try to reduce remote traffic, which could be slow at times. Also we try to avoid that someone replaces a file and build results are changing unpredictable.

BuildPlan should request JDK according to `java.version` property of `pom.xml`

If the pom.xml of the application compiles for a specific java version and provides this information, the build plan should not just require any JDK, but at least of this version.

Describe the Enhancement

The maven buildpack could add the information that a specific min version is needed to build an application.

Example:

• Use example: https://github.com/paketo-buildpacks/samples/tree/main/java/maven
• Change java.version here to 17
• Build with pack build --builder paketobuildpacks/builder-jammy-base sample-java-image
• Error:

error: invalid target release: 17

Possible Solution

The maven buildpack could set a semver version range via metadata.version for the require and the providing buildpack could consider it.

This would most likely also need change to the JDK providing buildpacks (i.e. libjvm).

Motivation

Ease of use.