Re: Different parent/child configuration without child located customization?
For frontend development with Maven I found it to be easiest to define a custom lifecycle for a custom artifact type / packaging, e.g. "angular-app", "angular-lib", "webpack-app" etc. This way it is possible to specify a build flow which is more appropriate for frontend development than the default lifecycle by specifying a sensible set of plugin executions such as the frontend-maven-plugin. The generated frontend artifact can then be used as dependency in other maven modules and be unpacked with the maven-dependency-plugin to the desired location. On a more general note: in my opinion maven-tiles [1] is more appropriate for this kind of scenarios by utilizing composition-over-inheritance. I usually combine both approaches to specify a generalized build flow for the frontend first with the custom lifecycle / artifact type and maven-tiles to make customizations to this build flow. [1] https://github.com/repaint-io/maven-tiles On Sat, Nov 27, 2021, 18:08 Falko Modler wrote: > Hi, > > what also works in many cases is a profile with file activation, e.g. if > there is src/main/kotlin add the kotlin plugin. > You can even use flagfiles to control this, which isn't pretty but > sometimes it makes sense > > Cheers, > > Falko > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
maven-gpg-plugin 3.0.1 release
Hi, I think I fixed all of the remaining bugs in Jira in the past few weeks, which were blocking the maven-gpg-plugin 3.0.1 release. Would it be possible to start a new vote or did I miss something? Best Regards, Frederik
Re: [VOTE] Release Apache Maven GPG Plugin version 3.0.1
+1 Thanks for releasing it. On Wed, May 5, 2021, 18:46 Hervé BOUTEMY wrote: > Hi, > > We solved 5 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521&version=12348086&styleName=Text > > in addition to the cancelled 3.0.0 release candidate that solved 13 other > issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521&version=12330781&styleName=Text > > Staging repo: > https://repository.apache.org/content/repositories/maven-1645/ > > https://repository.apache.org/content/repositories/maven-1645/org/apache/maven/plugins/maven-gpg-plugin/3.0.1/maven-gpg-plugin-3.0.1-source-release.zip > > Source release checksum(s): > maven-gpg-plugin-3.0.1-source-release.zip sha512: > 10eef9c1f3e71724b328e0f8d76303d251922a4e7a05ffbbe44191e2293c097e976b0f6b7ec3b8783b04da13c74bbe5b34f4dabc5e0dd3a7cb5fe7aa92122af0 > > Staging site: > https://maven.apache.org/plugins-archives/maven-gpg-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 Javadoc Plugin version 3.3.0
+1 Works on Ubuntu 21.04 with Maven 3.6.3. Best Regards Frederik Boster On Sat, May 22, 2021, 09:43 Robert Scholte wrote: > Dear all, > > I need some extra votes in order to release this. > > thanks, > Robert > On 18-5-2021 20:43:37, Robert Scholte wrote: > Hi, > > We solved 28 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529&version=12346637&styleName=Text > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317529%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1649 > > https://repository.apache.org/content/repositories/maven-1649/org/apache/maven/plugins/maven-javadoc-plugin/3.3.0/maven-javadoc-plugin-3.3.0-source-release.zip > > Source release checksum(s): > > maven-javadoc-plugin-3.3.0-source-release.zip sha512: > 780e485ea5bb05a074089f243f6442ad43d9627e7a3805e5985dbda67751fcf140504e48b1e74596dc10d187cb6bb3d9a153f74dda3b733e2d8d3a42062d4794 > > Staging site: > https://maven.apache.org/plugins-archives/maven-javadoc-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 >
Re: [maven-gpg-plugin] Unable to sign artifacts with SHA-256 or higher
Hi Janardhan, The maven-gpg-plugin is only responsible for creating the "asc" files which contain the PGP signature. The file hashes are created by maven-resolver, which supports SHA-512 since version 1.5.0 ( https://issues.apache.org/jira/browse/MRESOLVER-56 ). If I remember correctly maven-resolver 1.5+ is included since Maven 3.8.1. So you would have to update your Maven to 3.8.1 and ` -Daether.checksums.algorithms=SHA-512 ` should work then. Best Regards Frederik On Wed, May 26, 2021 at 9:14 AM Janardhan wrote: > Hi Maven team, > > TL;DR: Can we sign (SHA-512) artifacts with gpg plugin and how?. Thanks. > > 1. We are trying to sign Apache SystemDS[0] release artifacts with > gpg-plugin, > we are only receiving the `.md5` and `.sha1` without the > `-Daether.checksums.algorithms=SHA-512` flag as per [1][4]. > > 2. With the following command we are receiving the .asc file additionally. > But, not the `.sha512`. > > mvn -P'distribution' deploy -DskiptTests \ > -Daether.checksums.algorithms=SHA-512 > > > 3. I have read through the mail list[1] and some source code[3]. > I have noted from discussion in [2] that the gpg arguments[5] in > pom.xml may not work but only work on the command line. > > -- > [0] https://github.com/apache/systemds/blob/master/pom.xml > [1] https://maven.apache.org/resolver/configuration.html > [2] https://www.mail-archive.com/users@maven.apache.org/msg142898.html > [3] > > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L117 > [4] > > https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#MessageDigest > [5] > > https://maven.apache.org/plugins/maven-gpg-plugin/sign-mojo.html#gpgArguments > > Thanks and regards, > Janardhan >
Re: @Parameter on a NIO Path
I did not find a pretty solution yet, but I just subclassed the BasicComponentConfigurator and replaced the Mojo configurator in the Mojo annotation of my plugin. My custom BasicComponentConfigurator exposes the DefaultConverterLookup so I can just register custom converters. This approach could probably be improved by utilizing Sisu to find custom converters on the class path. On Sat, May 29, 2021, 19:07 Gary Gregory wrote: > I don't really care about this or that superclass-shim-widget-whatever, i > just want to use a Path for a parameter. So what is the recommendation? > > Gary > > On Sat, May 29, 2021, 12:36 Tamás Cservenák wrote: > > > Howdy, > > > > Something is wrong here... > > You want to _extend_ sisu-plexus-shim, codebase that is here to buy out > > (functionally) old Plexus Containers? The one meant to be a drop-in > > replacement for legacy Plexus containers? Given we have STILL mixed use > of > > sisu-plexus-shim and "original" plexus-container, having them "drift > away" > > from each other is just opening a big door for problems. > > > > If not proactively working on Plexus Container removal (so not > proactively > > moving to JSR330), then at least keep that code _frozen_, as > > investing/extending shim-legacy codebase (sisu-plexus) meant to be > removed > > is something I cannot understand, > > > > I'd rather look into hooking in Guice TypeConverter SPI than using Plexus > > oldie AbstractBasicConverter (that servers as superclass of mentioned > > FileConverter) > > > > Ultimately, what's wrong with making that parameter a String and invoke > > Paths.get(string) with it? > > > > We should be by now in blue box, while to me it seems we keep insisting > > (and extending) red box: > > https://imgur.com/a/sc3rwPK > > > > Re Sisu project: it is healthy and all fine, thanks, 1.0 planned release > is > > soon to come. But given Plexus Shim (shim!) is in place as "compatibility > > layer", there is not much sense in investing into it, it played it's > role, > > it bought out p-c-d for all these years, but it's role is NOT to become > > yet-another p-c-d instead of p-c-d. > > > > Thanks > > T > > > > On Sat, May 29, 2021 at 5:03 PM Robert Scholte > > wrote: > > > > > Someone needs to implement #563525[1] > > > I've had the confirmation that increasing source/target of Java makes > > > sense. > > > > > > > > > thanks, > > > Robert > > > > > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=563525 > > > On 29-5-2021 16:07:50, Gary Gregory wrote: > > > Hi All, > > > > > > How do I use a @Parameter on a NIO Path? > > > > > > I don't a place to plugin a factory of some kind. > > > > > > TY, > > > > > > Gary > > > > > >
Re: Software Heritage connector to Maven repositories
I am not in any way affiliated with Apache or Sonatype. So take my opinion with a grain of salt :) Trying to mirror the entire Maven Central repository will unfortunately get you automatically banned. To circumvent that I would suggest you setup your own Maven Central mirror first. [1] [1] https://maven.apache.org/guides/mini/guide-mirror-settings.html#creating-your-own-mirror On Mon, Jun 14, 2021, 12:12 Boris Baldassari wrote: > Hiho good people, > > I am currently developing a Maven repositories connector for the > Software Heritage Foundation [1]. In a nutshell, the SWH aims to > archive all existing source code in the world, and provides useful > publicly available services and related tools (unique IDs/DOIs, search, > datasets, graph tools..). It's all open-source, and many large forges > and software systems have already been archived (GitHub, GitLab, npm, > pypi, debian packages, CRAN..) [2]. Now we would like to archive the > Maven ecosystem. > > [1] https://www.softwareheritage.org/ > [2] https://archive.softwareheritage.org/ > > I'm reaching out to ask for wisdom and start a discussion about how this > could be achieved without impacting anybody, i.e. neither Maven > repositories maintainers nor the users. Our plan for now is to use the > maven indexer indexes for the listing, and then download poms and source > jars, in a way that we see as the most efficient and fair. We of course > respect all rate-limiting policies (and http error codes), and we are > polite and patient (although tenacious). > > So, here are my questions: > > * Who should we talk to to achieve that? i.e. are there maven repository > maintainers on the list, or do you know of a better place to ask? > > * Although we believe the above mentioned process is the most efficient > and fair one, maybe there is a better way to list, and archive artefact > sources? Any feedback or mere thoughts are welcome. > > > Thanks in advance, have a wonderful day! > > > -- > Boris Baldassari > Castalia Solutions -- Elegant Software Engineering > Web: http://castalia.solutions > Tel: +33 6 48 03 82 89 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Require Java 17 for Maven 4
+1 On Wed, Feb 28, 2024, 08:31 Benjamin Marwell wrote: > Hi Maven Devs/Users/Committers and PMC members! > > After several discussions on the mailing lists, I would like to > start a vote in favour of setting the minimal Java bytecode target > of Maven-Core 4 to 17 and hence require Java 17 for Maven 4. > > This is a procedural majority vote [1*]: > You can also vote with fractions and negative votes are not vetoes. > > Please also notice: > * Maven 3 will stay at Java 8 no matter what. > * We may raise Maven 4 to JDK 21 later if we feel like it (depending > on the release date). > This is not part of this vote. > * The linked PR is not part of this vote (this is not a code vote). > But you may take a look at it to understand the intended change. > > PR: https://github.com/apache/maven/pull/1430 > > Maven-Parent will not be raised with this vote, the other PR is not > part of this vote. > > Please refrain from starting discussions in this thread, but do > include a reasoning on downvotes and feel free to start a new > discussion on the mailing list, or comment on the existing ones. > > --- > > Vote open for 72 hours: > > [ ] +1 (set JDK17 min version for Maven 4.x) > [ ] +0 > [ ] -1 (please include reasoning) > > --- > > - Ben > > [1*]: https://www.apache.org/foundation/voting.html > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
