Allow spring-boot-maven-plugin RepackageMojo to use a source classifer

[tuliogomesbarbosa]

Hi,
i'm using spring-boot-maven-plugin to generate a fat jar that have jars (bouncycastle family) inside it .

I'm also using maven profiles to customize my generated jar with classifiers. Thus i have a maven-jar-plugin configured this way:

	<plugin>
		<groupId>org.apache.maven.plugins</groupId>
		<artifactId>maven-jar-plugin</artifactId>
		<version>3.0.2</version>
		<executions>
			<execution>
				<id>hom</id>
				<goals>
					<goal>jar</goal>
				</goals>
				<phase>package</phase>
				<configuration>
					<classifier>hom</classifier>
					<archive>
						<index>true</index>
						<manifestEntries>
							<Application-Name>My Applet</Application-Name>
							<Permissions>all-permissions</Permissions>
							<Codebase>*</Codebase>
							<Application-Library-Allowable-Codebase>*</Application-Library-Allowable-Codebase>
							<Caller-Allowable-Codebase>*</Caller-Allowable-Codebase>
							<Trusted-Only>true</Trusted-Only>
							<Trusted-Library>true</Trusted-Library>
							<Built-By>My Company</Built-By>
						</manifestEntries>
					</archive>
				</configuration>
			</execution>
		</executions>
	</plugin>

Debugging the spring-boot-maven-plugin i could see that the method Repackager.repackage (line 150, tag 1.4.2.RELEASE) does not consider the classified jar generated previously by maven-jar-plugin as a input.

My spring boot plugin configuration is as follow:

<plugin>
						<groupId>org.springframework.boot</groupId>
						<artifactId>spring-boot-maven-plugin</artifactId>
						<executions>
							<execution>
								<goals>
									<goal>repackage</goal>
								</goals>
								<configuration>
								    <attach>true</attach>
									<layout>NONE</layout>
									<classifier>hom</classifier>
									<requiresUnpack>
										<requiresUnpack>
											<groupId>org.bouncycastle</groupId>
											<artifactId>bcprov-jdk15</artifactId>
											<version>1.45</version>
										</requiresUnpack>
									</requiresUnpack>
								</configuration>
							</execution>
						</executions>
					</plugin>

In short, after the build i got something like this:

myjar-hom.jar without my manifest entries configured in maven-jar-plugin because the spring boot plugin considers the raw myjar.jar generated along with the classified myjar-hom.jar

PS: the raw jar doesn't have these manifest entries

Is this a bug or i'm missing some configuration?

Thanks in advance

[philwebb]

Currently the RepackageMojo.execute() method calls this.project.getArtifact().getFile() to obtain the source. I don't think we currently have any way to specify the source artifact. Your options in the short term are to either not use a classifier (i.e. switch things around so that the non-classifier version has your edits) or do the packaging yourself using the assembly plugin.

Here's how we package up the Spring CLI app using the assembly plugin. Be aware that the latest version of the assembly plugin has a bug so make sure you use the version provided by our parent POM.

[philwebb]

Supporting a source classifier for RepacakgeMojo would be a nice addition. It's probably not too tricky if you want to try and contribute a pull-request.

[tuliogomesbarbosa]

@philwebb thanks for your response. I'll give assembly-plugin a chance and try to give my contribution in this enhancement when possible.

[snicoll]

Supporting a source classifier for RepacakgeMojo would be a nice addition.

@philwebb Maybe we should look for a file with that classifier and overwrite it the same way we do it for the standard jar. If we don't do anything we replace the artifact by default so it seems consistent to do the same if the classified jar already exists. The documentation of the classifier attribute will have to be adapted a bit though.

[philwebb]

@snicoll Do you mean use the classifier property that we already have? We could use that but then we couldn't support repacking from one classifier to a different one. Perhaps that's not an issue.

[snicoll]

I think that's not an issue. It's yet another advanced use case nobody complained about...

[tuliogomesbarbosa]

I think this is an issue because doesn't make sense IMO the plugin defined inside the profile not take in consideration the artifact generated by this profile. In this case, an artifact with a classifier.
I looked at the shade plugin and noticed that it supports the classified jar through shadedArtifactAttached and shadedClassifierName attributes.

Maybe is it necessary to create a new attribute? I was thinking about using the classifier property but you guys are seeing some problems, right?

[philwebb]

@tuliogomesbarbosa I think @snicoll means that reusing the existing classifier is not an issue. We're in agreement that your original report is valid.

[tuliogomesbarbosa]

oh sorry for the misunderstanding. I'll let you aware of my progress.

[tuliogomesbarbosa]

How can i test plugin modifications? Through a local repository? I need to debug but maven is downloading the plugin from the remote repository...

[snicoll]

Look at src/it. We have integration tests there.

[elie-delorme]

I also have this issue, my main artifact has a classifier so the plugin throws "java.lang.IllegalArgumentException: Source must refer to an existing file".
It would be nice to add the path of the file it's looking for with the error message.

I added the classifier to the plugin so it works but I would rather not have to push the original jar.

[juanpablo-santos]

Hi,

we're also facing this issue; we use the classifiers to mark our release-candidate builds, which get kicked via a dedicated maven profile on a parent pom. We can use the assembly workaround but it gets messy (we have to change a common ci pipeline to handle this corner cases).

It would be nice though if the plugin could take care of this O:-)

best regards,
juan pablo

[snicoll]

Closing in favour of PR #11061