[ANN] Apache Maven Assembly Plugin 3.3.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Assembly Plugin, version 3.3.0 The Assembly Plugin for Maven enables developers to combine project output into a single distributable archive that also contains dependencies, modules, site documentation, and other files. https://maven.apache.org/plugins/maven-assembly-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-assembly-plugin 3.3.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-assembly-plugin/download.cgi Release Notes - Maven Assembly Plugin - Version 3.3.0 ** Bug * [MASSEMBLY-879] - useDefaultExcludes has no effect in dependencySet/unpack * [MASSEMBLY-920] - ContainerDescriptorHandler for MetaInf-Services breaks folder structure * [MASSEMBLY-932] - resource filtering skipped for resources in the current project ** New Feature * [MASSEMBLY-922] - allow to override UID/GID and user name and group name for files stored in TAR (and other formats that store UID/GID) * [MASSEMBLY-927] - Support for properties mapping on executions of maven-assembly-plugin * [MASSEMBLY-934] - Support concatenation of files ** Improvement * [MASSEMBLY-765] - add property groupIdPath * [MASSEMBLY-849] - Add nonFilteredFileExtensions to avoid filtering of binary files * [MASSEMBLY-933] - make build Reproducible ** Dependency upgrade * [MASSEMBLY-924] - Upgrade commons-compress to 1.19 Enjoy, -The Apache Maven team
[RESULT] [VOTE] Release Apache Maven Assembly Plugin version 3.3.0
Hi, The vote has passed with the following result: +1 : Robert Scholte, Hervé BOUTEMY, Karl Heinz Marbaise, Eric Lilja PMC quorum: reached I will promote the artifacts to the central repo. On 30-4-2020 20:24:29, Eric Lilja wrote: +1 non-binding Nice to see a release of this plugin! - Eric Lilja On Thu, Apr 30, 2020 at 8:09 PM Karl Heinz Marbaise wrote: > Hi, > > +1 from me > > > Kind regards > Karl Heinz Marbaise > On 27.04.20 20:19, Robert Scholte wrote: > > Hi, > > > > We solved 10 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220&version=12344774&styleName=Text > > > > There are still a couple of issues left in JIRA: > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317220%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1568/ > > > https://repository.apache.org/content/repositories/maven-1568/org/apache/maven/plugins/maven-assembly-plugin/3.3.0/maven-assembly-plugin-3.3.0-source-release.zip > > > > Source release checksum(s): > > > maven-assembly-plugin-3.3.0-source-release.zip sha512: > d41ba25dd35dea5b1b690f6cb84e4e30c5466c0e6fb3d5d98305daf70cb1ba9468c0ba2181afb8fa5f6d41c735f4f1d9d462f58eb320df0c85d57dbefa70b15a > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven Assembly Plugin version 3.3.0
+1 non-binding Nice to see a release of this plugin! - Eric Lilja On Thu, Apr 30, 2020 at 8:09 PM Karl Heinz Marbaise wrote: > Hi, > > +1 from me > > > Kind regards > Karl Heinz Marbaise > On 27.04.20 20:19, Robert Scholte wrote: > > Hi, > > > > We solved 10 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220&version=12344774&styleName=Text > > > > There are still a couple of issues left in JIRA: > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317220%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1568/ > > > https://repository.apache.org/content/repositories/maven-1568/org/apache/maven/plugins/maven-assembly-plugin/3.3.0/maven-assembly-plugin-3.3.0-source-release.zip > > > > Source release checksum(s): > > > maven-assembly-plugin-3.3.0-source-release.zip sha512: > d41ba25dd35dea5b1b690f6cb84e4e30c5466c0e6fb3d5d98305daf70cb1ba9468c0ba2181afb8fa5f6d41c735f4f1d9d462f58eb320df0c85d57dbefa70b15a > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven Assembly Plugin version 3.3.0
Hi, +1 from me Kind regards Karl Heinz Marbaise On 27.04.20 20:19, Robert Scholte wrote: Hi, We solved 10 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220&version=12344774&styleName=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317220%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1568/ https://repository.apache.org/content/repositories/maven-1568/org/apache/maven/plugins/maven-assembly-plugin/3.3.0/maven-assembly-plugin-3.3.0-source-release.zip Source release checksum(s): maven-assembly-plugin-3.3.0-source-release.zip sha512: d41ba25dd35dea5b1b690f6cb84e4e30c5466c0e6fb3d5d98305daf70cb1ba9468c0ba2181afb8fa5f6d41c735f4f1d9d462f58eb320df0c85d57dbefa70b15a Staging site: https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at least 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Filtering Plugin should avoid overwriting even when filtering
The main different is the moment you know you have to write the file. If there's zero interpolation/filtering, then there's no need to write the file. As soon as you detect interpolation/filtering you can start overwriting the original file. The challenge is probably to fit this concept in the current codebase. However,the result would a much more elegant and efficient result compared to the temporary created files. Robert On 30-4-2020 09:54:55, Rob Oxspring wrote: > On 30 Apr 2020, at 07:38, Robert Scholte wrote: > > I prefer to see an in memory solution. Well if it’s reasonable to assume that filtered files are always small then we could use replace the temporary file in my solution with an in memory buffer... but I’m not sure that’s what you’re shooting at? > Key should be to detect if filtering is applied, which is done in the > MultiDelimiterInterpolatorFilterReaderLineEnding[1] > Once a value has been interpolated, you must rewrite the file, otherwise you > shouldn't. Again though, this appears to miss the subtlety: “if filtering is applied” is insufficient, the condition needs to be “if filtering is applied with different results than the previous run”. This requires either attempting to store some state between runs. We could scan the source file for filtered values and store just that state (or checksum) in a file between runs. The cost would be an extra read of the source file + state comparison + writing out the state of each filtering. Is this what you’re thinking? The alternative is to just use the target file as the (not minimal) state. We could read and filter the source file once, while reading and comparing with the target file in parallel. As soon as the contents start to differ then truncate the target file and append the rest of the filtered source to it. The cost here would be an extra full read of the target. Is this what you’re after? Otherwise I’m at a loss to understand what would be acceptable. Thanks! Rob - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: source directory layout for multirelease jars
Hi Benjamin,
You're confusing me
"Sadly, you cannot just add executions to the maven compiler plugin."
Why not? The design of the pom contains support of multiple executions within
the same plugin
"Almost no IDE supports it, ..."
I think they all do. And even if they don't, they should. I consider an IDE as
a wrapper around Maven, so it should support this basic feature
"... and when I asked about multiple executions
in the maven compiler plugin on this list I recevied only one reply
that this is not an intended way of using this plugin (although I was
using it for annotation processing with
useIncrementalCompilation=false)."
I don't recognize this question. And the answer looks incorrect to me.
That said: if you just want a META-INF/versions/9/module-info.class, you can
already do that (for a long time).
https://github.com/apache/maven-compiler-plugin/tree/master/src/it/multirelease-patterns
However, there is no one ideal pattern, you have to pick one,
Robert
On 30-4-2020 08:49:02, Benjamin Marwell wrote:
Hi,
to make the story a bit shorter - for most libraries it would be
sufficient to add a way to include a module descriptor at
"META-INF/versions/9/module-info.class" while still staying at java 8.
Most libraries will stick to java 8 or even 7 for quite a time.
Sadly, you cannot just add executions to the maven compiler plugin.
Almost no IDE supports it, and when I asked about multiple executions
in the maven compiler plugin on this list I recevied only one reply
that this is not an intended way of using this plugin (although I was
using it for annotation processing with
useIncrementalCompilation=false).
I know there is the moditect plugin for such cases, but it doesn't
play along nicely with the bundle-plugin and hasn't seen much progress
lately as far as I can tell.
That said, adding such a module descriptor would be a nice first goal
without using executions.
Of course this will all become obsolete as soon as everyone uses java 9+.
Am Sa., 25. Apr. 2020 um 21:20 Uhr schrieb Robert Scholte
:
>
> I'm afraid this will be long story, but this might be the moment to share the
> details.
>
> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> describes already several topics:
>
> - why MultiRelease Jars
> - how to build them? There are several patterns, each with its pro's and
> con's.
>
> But it doesn't explain the technical problems, so I guess we need to explain
> it a bit better.
> I will also take the time to describes things that you might already know.
>
> So you want to build a jar? You take the minimum pom (modelVersion + groupId
> + artifactId + version)
> and you can set the packaging to jar (or omit it, as it is the default value).
> You will call "package", which matches a phase of the default lifecycle.
> Maven must first figure out the matching lifecycle, by looping over all the
> available.[1]
> It will pick up all mapped Lifecycle components and will search in its
> phases. The result will be the "default" Lifecycle.
> Based on this Maven will look for "jar" named LifecycleMapper and the
> configuration for the "default" lifecycle [2]
>
> Now it knows which plugins, versions and goals must be called. (it is
> possible to call multiple calls within one phase)
> There is no explicit executionId (I'm actually not sure if you can use it
> here, I think so), so default- will be used as executionId.
> You can see this in the console output of Maven. You can use this executionId
> for explicit configuration.
> Keep in mind that plugins are very isolated.
> They have their own classloader during execution.
> They don't share configuration or instances with other plugins(*), you could
> treat the pom as the shared configuration.
>
> For the creation of a Multirelease jar we have sepatare challenges for the
> following phases: compile, test and packaging.
> The simplest of the three is probably packaging: you need to ensure that the
> manifest has the attribute Multi-Release: true
> Depending on in which folder/package structure the classes are available you
> need to build up the right structure, putting classes in their matching
> META-INF/versions/${release}/ -folder
>
>
> Now the compiling part:
> My first approach is close to what everybody wants: no additional
> configuration in the pom (the minimal pom should be enough), use
> src/main/java/ as predefined folder template.
> I did a POC, and it looks promising: the plugin would loop over the folders,
> extracted the release value and executed javac a couple of times, but the
> classes in the matching directory.
> Well, I was wrong: tests started to fail. I discovered that several
> parameters should only be used for a subset of a javac calls, or just exactly
> for one. Especially the includes/excludes caused trouble.
> I could try to find a configuration for includes/excludes per release value
> within the same execution, but I knew there were other properties needing
> simila
Re: Maven Filtering Plugin should avoid overwriting even when filtering
> On 30 Apr 2020, at 07:38, Robert Scholte wrote: > > I prefer to see an in memory solution. Well if it’s reasonable to assume that filtered files are always small then we could use replace the temporary file in my solution with an in memory buffer... but I’m not sure that’s what you’re shooting at? > Key should be to detect if filtering is applied, which is done in the > MultiDelimiterInterpolatorFilterReaderLineEnding[1] > Once a value has been interpolated, you must rewrite the file, otherwise you > shouldn't. Again though, this appears to miss the subtlety: “if filtering is applied” is insufficient, the condition needs to be “if filtering is applied with different results than the previous run”. This requires either attempting to store some state between runs. We could scan the source file for filtered values and store just that state (or checksum) in a file between runs. The cost would be an extra read of the source file + state comparison + writing out the state of each filtering. Is this what you’re thinking? The alternative is to just use the target file as the (not minimal) state. We could read and filter the source file once, while reading and comparing with the target file in parallel. As soon as the contents start to differ then truncate the target file and append the rest of the filtered source to it. The cost here would be an extra full read of the target. Is this what you’re after? Otherwise I’m at a loss to understand what would be acceptable. Thanks! Rob - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
