Re: Publish Via the Central Portal

> We are also working on Maven 4, so today the plugin should be possible to > > use with the next Maven major version. > > As I remember nexus-staging-plugin can not be used with Maven 4. > > Can a new plugin be used with Maven 4? > > > > > > śr., 1 maj 202

Re: Publish Via the Central Portal

Hey all. Thanks Romain for pointing out the thread for me. One issue is that Central publishers is a much larger set of folks than the Maven Dev group. Obviously there's lots of overlap, but as Romain said, creating a plugin is a thing that can be done independently. As we've been working

Re: [DISCUSS] Java version for Maven

x.x. > > Elliotte gave a good reason for this: There are two camps now (read: > > ALREADY). > > There is no reason to not go with either of them. > > > > Am Do., 22. Feb. 2024 um 19:56 Uhr schrieb Brian Fox >: > > > > > > We dumped 30 days b

Re: [DISCUSS] Java version for Maven

> > > > > Maven UA is created like this: > > > > > > > > > > > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555 > > > > > > > > I was

Re: [DISCUSS] Java version for Maven

Hi everyone. I haven't caught up on this thread but Tamas pinged me to get some usage data from Central. Attached are the Maven versions and JDK Version counts as reported by User Agent by distinct IP for the last 30 days: On Wed, Feb 21, 2024 at 4:15 PM Hunter C Payne wrote: > I also want

Re: SBOM

On Fri, Oct 27, 2023 at 7:22 AM Gary Gregory wrote: > > FYI to Logging and Brian, > > Over at Apache Commons, I added generating of CycloneDX and SPDX SBOMs > that we publish along with our artifacts. So I'd be curious if "we're > doing it wrong" ;-) > > My take is that it is still early in the

Re: [spdx] Completely new to this - link to SBOM data?

Hi Mark, if you happen to be into podcasts, I highly recommend this one. I've been involved in SBOMs and related tech for longer than the term "SBOM" and I still find new information here. The early episodes do a fantastic job at covering a lot of the space from many angles.

Re: [spdx] EU CRA is very supportive of SBOM

bleenergyanalytics.com > > Tel: +1 978-696-1788 > > > > > > *From:* spdx@lists.spdx.org *On Behalf Of *Mike > Linksvayer > *Sent:* Monday, July 31, 2023 4:19 PM > *To:* spdx@lists.spdx.org > *Cc:* sc...@ietf.org; scrm-nist ; swsupplychain-eo < > swsupplychain...@nis

Re: [spdx] EU CRA is very supportive of SBOM

t; >> >> >> *Active Member of the CISA Critical Manufacturing Sector, * >> >> *Sector Coordinating Council – A Public-Private Partnership* >> >> >> >> *Never trust software, always verify and report! >> <https://reliableenergyanalytics.c

Re: [spdx] EU CRA is very supportive of SBOM

On Mon, Jul 31, 2023 at 3:10 PM David Prater via lists.spdx.org wrote: > Addressing the open-source business model by ensuring that no commercial > entities will participate in/contribute to open source work for fear of > being held responsible for that software is certainly an interesting >

Re: [spdx] EU CRA is very supportive of SBOM

On Sun, Jul 30, 2023 at 8:05 AM Dick Brooks < d...@reliableenergyanalytics.com> wrote: > Mike, > > > > I agree. The CRA is raising questions about the open-source business > model, which IMO is broken and needs to be fixed. Open-source developers > and maintainers are very talented and work very

Re: SPDX should take a stronger stance against vanity/promotional licenses

Maybe start assigning ids for these with a format like vanity-xxx and that might make people think twice about it and actually put some work into really explaining why they need yet-another-license that does something different from the standards so they can avoid the vanity label, which

Re: [spdx] Congress is considering removing the SBOM provision from the NDAA Bill now before Congress

You shared this previously https://insidecybersecurity.com/share/14118 I think that's a significant reason. And even as a proponent / agitator of SBOMs myself, I find the arguments they lay out compelling as we sit right now. On Fri, Dec 16, 2022 at 4:33 PM Dick Brooks <

Re: [spdx-tech] Simplifying Identities

+1 On Mon, May 9, 2022 at 11:06 PM Kay Williams via lists.spdx.org wrote: > +1 > > > > *From:* Spdx-tech@lists.spdx.org *On Behalf Of > *William Bartholomew (CELA) via lists.spdx.org > *Sent:* Monday, May 9, 2022 8:00 PM > *To:* spdx-tech > *Subject:* [spdx-tech] Simplifying Identities > > >

Re: [spdx] SPDX Company Membership

Once signing up, how are nominations made? On Tue, Mar 29, 2022 at 10:17 PM Steve Winslow wrote: > Hello SPDX community, > > Just wanted to send a reminder from Phil's original email announcing the > SPDX project membership process -- see his email below. > > As mentioned previously, companies

Re: Feature Request: Add CPE String to pom.xml

Hi Sebastian, The challenge is that CPE as a coordinate system doesn’t have enough specificity to match artifacts. It has organization/product/version and therefore doesn’t have the ability to capture sub module. This is what leads to most of the mismatch issues seen in CVE based tools (but not

CVE-2021-26291: Apache Maven: block repositories using http by default

Apache Maven may follow repositories that are defined in a dependency’s Project Object Model (pom) which may be surprising to some users, resulting in potential risk if a malicious actor takes over that repository or is able to insert themselves into a position to pretend to be that repository.

CVE-2021-26291: Apache Maven: block repositories using http by default

Apache Maven may follow repositories that are defined in a dependency’s Project Object Model (pom) which may be surprising to some users, resulting in potential risk if a malicious actor takes over that repository or is able to insert themselves into a position to pretend to be that repository.

CVE-2021-26291: Apache Maven: block repositories using http by default

Apache Maven may follow repositories that are defined in a dependency’s Project Object Model (pom) which may be surprising to some users, resulting in potential risk if a malicious actor takes over that repository or is able to insert themselves into a position to pretend to be that repository.

Re: [VOTE] Release Apache Maven version 3.8.0

I'm +1. If the worst thing we can find to worry about is the version number 3.7, 3.8, then it seems like we're close enough. On Wed, Mar 24, 2021 at 3:11 AM Romain Manni-Bucau wrote: > > +0 cause of the versioning which is unexpected (but you know what? since it > is a git tag we can drop it and

Re: [VOTE] Release Apache Maven version 3.8.0

The CVE is for documentation and the hardening of default behavior, it's not your typical zero day. On Mon, Mar 22, 2021 at 10:53 PM Gary Gregory wrote: > > You are acknowledging a CVE _before_ a release? > > Gary > > > On Mon, Mar 22, 2021, 15:40 Robert Scholte wrote: > > > Hi, > > > > For the

Re: uploading to central via ossrh is problematic

ss stuff. > Moreover, I initially thought that OSSRH timeout was not 'just' a Sonatype > issue even if Sonatype is the operator of central & OSSRH (and I thank you > for that). I saw it as a community problem and thus I just wanted to have > some feedback from this community. > >

Re: uploading to central via ossrh is problematic

Hi Matthieu, I think continuing the conversation on your existing ossrh ticket is the right place to resolve this. While it seems like you're having recurring issues, it's not occurring across the entire system so we need to figure out what the unique issue is. --Brian Cofounder & CTO Sonatype

Re: [DISCUSS] Distribution guidelines for other platforms

I independently noticed and added [1] so that's covered. On Mon, Jun 29, 2020 at 12:06 PM Joey Frazee wrote: > > Justin this is great and I find myself searching mailing lists and INFRA and > LEGAL JIRAs for past guidance like this. > > A few nit-y suggestions: > > - I think it’d be helpful to

Re: Moving hashes (checksums) forward

't be done w/o careful planning. That's clear. > Who's the right contact at Sonatype? Brian Fox? > > > > On 31-5-2020 16:58:58, Michael Osipov wrote: > > Folks, > > > > I have been recently (indirectly) approached by Mark Thomas for the > > Tomcat committers that h

Re: [RESULT] [IP CLEARANCE] Maven Wrapper

s thread seems to have been acquired by > Walmart Labs? > > --David > > On Mon, Feb 3, 2020 at 11:01 PM Brian Fox wrote: > > > > I think what Robert is highlighting was that collectively, the > > contributors are still owners and have granted permission to use >

Re: [RESULT] [IP CLEARANCE] Maven Wrapper

I think what Robert is highlighting was that collectively, the contributors are still owners and have granted permission to use another license. On Mon, Feb 3, 2020 at 4:59 PM David Nalley wrote: > > On Mon, Feb 3, 2020 at 9:27 PM Justin Mclean wrote: > > > > HI, > > > > I agree with what John

Re: [VOTE] Retire Maven Downloader

+1 On Sun, Jun 9, 2019 at 5:32 AM Karl Heinz Marbaise wrote: > > Hi, > > +1 from me. > > Kind regards > Karl Heinz Marbaise > On 07.06.19 15:32, Robert Scholte wrote: > > Hi, > > > > The Apache Maven project consist of about 90 (sub)projects. Due to the > > small number of volunteers and the

Deprecating HTTP access to Central

Last year, we deprecated old and insecure TLS protocols on Central to make access more secure. This year, we're moving things forward again by deprecating and later removing access to insecure by default HTTP access. Right now this affects less than 20% of the traffic hitting Central. To find out

Deprecating HTTP access to Central

Last year, we deprecated old and insecure TLS protocols on Central to make access more secure. This year, we're moving things forward again by deprecating and later removing access to insecure by default HTTP access. Right now this affects less than 20% of the traffic hitting Central. To find out

[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors

[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1676#comment-1676 ] Brian Fox commented on WAGON-541: - A system property isn't a great solution. For companies trying to roll

Re: [ANNOUNCEMENT] HttpComponents Client 4.5.7 GA Released

There were some network issues messing up the sync. It's still being worked on, but typically they would appear on Central within hours. On Fri, Jan 25, 2019 at 8:31 AM Gary Gregory wrote: > It can take up to a few hours for MC to pick up new releases, sometimes > many hours. We publish to the

Re: Release HTTP Client 4.5.7 not available on maven repository

Looking into it On Fri, Jan 25, 2019 at 6:29 AM Philippe Mouawad wrote: > Hello, > Thanks for the release 4.5.7. > > There seem to be an issue with publication to Maven Central, it is not > available: > >- https://repo1.maven.org/maven2/org/apache/httpcomponents/httpclient/ > > >

Re: Maven error during Raspberry to Amazon Echo project.

Can you attach your logs as text? Most people aren't going to watch a video to see what you did and the screenshot was not sent through to the mail so there's no way to see what your error was. On Thu, Jan 3, 2019 at 8:35 PM Mikail Eryilmaz wrote: > > > > > Skickades från E-post

Re: [Urgent] Question about Nexus repo and Hadoop release

ng to figure out the issue, still no luck. >>> >>> >>> >>> I just filed https://issues.sonatype.org/browse/OSSRH-45646, really >>> >>> appreciate if anybody could add some suggestions. >>> >>> >>>

Re: [Urgent] Question about Nexus repo and Hadoop release

ng to figure out the issue, still no luck. >>> >>> >>> >>> I just filed https://issues.sonatype.org/browse/OSSRH-45646, really >>> >>> appreciate if anybody could add some suggestions. >>> >>> >>>

Re: [Urgent] Question about Nexus repo and Hadoop release

ng to figure out the issue, still no luck. >>> >>> >>> >>> I just filed https://issues.sonatype.org/browse/OSSRH-45646, really >>> >>> appreciate if anybody could add some suggestions. >>> >>> >>>

Re: [Urgent] Question about Nexus repo and Hadoop release

ng to figure out the issue, still no luck. >>> >>> >>> >>> I just filed https://issues.sonatype.org/browse/OSSRH-45646, really >>> >>> appreciate if anybody could add some suggestions. >>> >>> >>>

Re: [Urgent] Question about Nexus repo and Hadoop release

HI Brain, > > Thanks for responding, could u share how to push to keys to Apache pgp > pool? > > > > Best, > > Wangda > > > > On Mon, Jan 14, 2019 at 10:44 AM Brian Fox wrote: > > > >> Did you push your key up to the pgp pool?

Re: [Urgent] Question about Nexus repo and Hadoop release

HI Brain, > > Thanks for responding, could u share how to push to keys to Apache pgp > pool? > > > > Best, > > Wangda > > > > On Mon, Jan 14, 2019 at 10:44 AM Brian Fox wrote: > > > >> Did you push your key up to the pgp pool?

Re: [Urgent] Question about Nexus repo and Hadoop release

HI Brain, > > Thanks for responding, could u share how to push to keys to Apache pgp > pool? > > > > Best, > > Wangda > > > > On Mon, Jan 14, 2019 at 10:44 AM Brian Fox wrote: > > > >> Did you push your key up to the pgp pool?

Re: [Urgent] Question about Nexus repo and Hadoop release

HI Brain, > > Thanks for responding, could u share how to push to keys to Apache pgp > pool? > > > > Best, > > Wangda > > > > On Mon, Jan 14, 2019 at 10:44 AM Brian Fox wrote: > > > >> Did you push your key up to the pgp pool?

Re: [Urgent] Question about Nexus repo and Hadoop release

Did you push your key up to the pgp pool? That's what Nexus is validating against. It might take time to propagate if you just pushed it. On Mon, Jan 14, 2019 at 9:59 AM Elek, Marton wrote: > Seems to be an INFRA issue for me: > > 1. I downloaded a sample jar file [1] + the signature from the >

Re: [Urgent] Question about Nexus repo and Hadoop release

Did you push your key up to the pgp pool? That's what Nexus is validating against. It might take time to propagate if you just pushed it. On Mon, Jan 14, 2019 at 9:59 AM Elek, Marton wrote: > Seems to be an INFRA issue for me: > > 1. I downloaded a sample jar file [1] + the signature from the >

Re: [Urgent] Question about Nexus repo and Hadoop release

Did you push your key up to the pgp pool? That's what Nexus is validating against. It might take time to propagate if you just pushed it. On Mon, Jan 14, 2019 at 9:59 AM Elek, Marton wrote: > Seems to be an INFRA issue for me: > > 1. I downloaded a sample jar file [1] + the signature from the >

Re: [Urgent] Question about Nexus repo and Hadoop release

Did you push your key up to the pgp pool? That's what Nexus is validating against. It might take time to propagate if you just pushed it. On Mon, Jan 14, 2019 at 9:59 AM Elek, Marton wrote: > Seems to be an INFRA issue for me: > > 1. I downloaded a sample jar file [1] + the signature from the >

[jira] [Reopened] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors

[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox reopened WAGON-541: - We've also experienced this as a regression. When the server chooses to provide additional context

[jira] [Comment Edited] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors

[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734730#comment-16734730 ] Brian Fox edited comment on WAGON-541 at 1/5/19 1:59 AM: - We've also experienced

Re: Adding Crypto APIs to Maven

See https://central.sonatype.org --mobile > On Dec 11, 2018, at 10:23 AM, BizDev wrote: > > Dear Maven team, > > We are reaching out in order to deploy our project to Maven Central > Repository. > Could you please let us know what are the steps and what information we need > to provide? >

Re: deploying to repository.apache.org: gpg signatures on .sha512 checksums required?

I have a patch to the plugin that I need to get some time to test. I'm the bottle neck unfortunately. Is the rule blocking only because of the missing signature or is it balking at the hashes too? On Thu, Oct 18, 2018 at 9:05 AM Marshall Schor wrote: > Hi, > > Following more requests to update

Re: Maven Repository Hosting Support

Hi Shams, see here: https://central.sonatype.org/pages/producers.html On Fri, Aug 3, 2018 at 9:03 AM, wrote: > Dear Support, > > > > I wanted to host a JAVA Spring Maven Repository (.jar) file within one of > your approved central repositories. The library implements server side > components

Re: Announcing OSSIndex plugins for Apache Maven: Scan your dependencies for known vulnerabilities

--mobile > On Jul 25, 2018, at 9:24 PM, Mark Derricutt wrote: > > On 26 Jul 2018, at 12:55, Brian Fox wrote: > > Find the Maven Plugin docs here: > https://sonatype.github.io/ossindex-maven/maven-plugin/ > > This looks awesome! One nit pick tho - the XML plu

Announcing OSSIndex plugins for Apache Maven: Scan your dependencies for known vulnerabilities

You probably know Sonatype for our work in the Maven community, Nexus Repository Manager, and for hosting Central. You may not know that for the last 7 years we've also been leading the way in solutions that allow developers to innovate faster and be able to improve security, license compliance

Re: Notice: Java 6 and 7 users: SSL Protocol upgrades coming to Central

Bumping this again. Cutover is next week. On Mon, May 21, 2018 at 2:22 PM, Brian Fox wrote: > The march of standards continues unabated. Legacy TLS protocols 1.0 > and 1.1 have varying weaknesses that could lead to a false sense of > security. > > In June, in an effort to

Notice: Java 6 and 7 users: SSL Protocol upgrades coming to Central

The march of standards continues unabated. Legacy TLS protocols 1.0 and 1.1 have varying weaknesses that could lead to a false sense of security. In June, in an effort to raise security and comply with modern standards, the insecure TLS 1.0 & 1.1 protocols will no longer be supported for SSL

[Notice] Java 6 and 7 users: TLS 1.1 being discontinued on Central

it along and we will include that as well. https://central.sonatype.org/articles/2018/May/04/discontinue-support-for-tlsv11-and-below/ --Brian Fox Apache Maven PMC CTO, Sonatype - To unsubscribe, e-mail: dev-unsubscr

Re: Set up Nexus staging profile for Dubbo (Incubating)

Was there discussion somewhere that decided to allow an Apache project to publish coordinates using com.alibaba? From my perspective this is highly unusual for an ASF project. From a central point of view, the fact that com.alibaba is registered to publish from a completely different repo

Re: Looking for recommendations how to best use Maven in a muti-stagePipeline build to only deploy at the end

On Wed, Feb 14, 2018 at 9:31 PM, Eric B wrote: > Bernd, > > Nexus 3.x does not support staging repos b/c they are rewriting the entire > platform to support not just Maven artifacts, but any type of repo-based > artifact. Ex: docker images, npm dependencies, etc... This is

Re: alternative solution / ScanCode

What was the podcast? On Sat, Feb 24, 2018 at 3:36 PM, P. Ottlinger wrote: > Hi, > > I'm just listening to a podcast about scancode and got a github > notification from DRAT that they want to use scancode next to RAT for > their stack. > > Just fyi: >

Re: Does the string "Java/1.8.0_112" in httpclient log messages indicate the running JDK, or what it was compiled against?

In my experience it's the version of the JVM running the application making the request. On Mon, Dec 4, 2017 at 2:30 PM, KARR, DAVID wrote: > I'm trying to track an issue with JDK versions being used with our code. > In our log messages, we're seeing strings with the following

Re: Who owns maven central?

Answered. On Fri, Dec 1, 2017 at 4:15 AM, Francis De Brabandere wrote: > I got into a discussion at > https://github.com/sbt/sbt/issues/3594#issuecomment-348440770 > > and was looking for documentation regarding maven central ownership. > > Can you help me there? > >

Re: [VOTE] Release Maven Indexer 6.0.0

On Fri, Dec 1, 2017 at 3:19 AM, Andreas Sewe < s...@st.informatik.tu-darmstadt.de> wrote: > Olivier Lamy wrote: > > probably no issues for sure. > > I just don't know if we will be able to still download the index from > > central and use it with this new version > > TBH I haven't done any

Re: [VOTE] Release Maven Indexer 6.0.0

Eyeballing the list, most of the changes seem irrelevant to the central use case. Is there anything in here that matters for Central (and if so, what are the backwards compat implications?) On Thu, Nov 30, 2017 at 2:07 AM, Olivier Lamy wrote: > +1 > > I'm not clear if this new

Re: Update on 4.5.4 release?

Tue, Nov 28, 2017 at 10:22 AM, Brian Fox <bri...@infinity.nu> wrote: > > > > > > > > Not so long ago Sonatype as a commercial entity was openly hostile to > > > > this project. > > > Reference? > > > > I am sorry if that sound

Re: Update on 4.5.4 release?

> > > Not so long ago Sonatype as a commercial entity was openly hostile to > > this project. > Reference? > > I am sorry if that sounds harsh, but personally I am not going to do > > anything to advance commercial interests of an unfriendly company. > That's your prerogative, of course, but Peter

Re: Maven JDeprScan Plugin

All set. On Sat, Oct 28, 2017 at 9:48 AM, Robert Scholte wrote: > Hi, > > I'd like to prepare an alpha release of the Maven JDeprScan Plugin > It is a wrapper around the jdeprscan tool[1], available since Java 9. > > You use the jdeprscan tool as a static analysis tool

Re: dependency:go-offline broken?

, Benedikt Ritter <brit...@apache.org> wrote: > Hello Brain, > > > Am 26.09.2017 um 23:10 schrieb Brian Fox <bri...@infinity.nu>: > > > > On Mon, Sep 25, 2017 at 2:10 PM, Benedikt Ritter <brit...@apache.org> > wrote: > > > >> Hello Bri

Re: dependency:go-offline broken?

On Mon, Sep 25, 2017 at 2:10 PM, Benedikt Ritter <brit...@apache.org> wrote: > Hello Brian, > > > Am 20.09.2017 um 23:16 schrieb Brian Fox <bri...@infinity.nu>: > > > > It's been a really long time, but I recall that there were issues getting > > the depe

Re: dependency:go-offline broken?

It's been a really long time, but I recall that there were issues getting the dependencies of plugins bound to the lifecycle. This looks to be the same problem. I think the documentation talked about a way to do this effectively. On Wed, Sep 20, 2017 at 4:48 PM, Benedikt Ritter

Re: Maven BOF session @ JavaOne

Cool. I'll be there as well. On Sat, Jul 29, 2017 at 5:58 AM, Robert Scholte wrote: > Hi, > > Both my talk and the BOF have been accepted for JavaOne 2017. > I will host the BOF session together with Manfred Moser. > All are invited to join. > > > thanks, > Robert > >

[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM

[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070348#comment-16070348 ] Brian Fox commented on MNG-6216: I'm bumping into this on Mac with 3.5.0 and https://github.com/jeremylong

index out of bounds 3.5 regression

I'm getting index out of bounds exceptions with 3.5 that don't occur with 3.3.9. I haven't debugged it yet, but wondering if this is already known? Fwiw reproducible with the DependencyCheck 2.0-snapshot master. [ERROR] 13978 java.lang.ArrayIndexOutOfBoundsException: 13978 at

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Even more than redefining what Central does, you're effectively describing a new, unofficial java class packaging and distribution mechanism. This seems like it will violate signatures etc and make tracking of what you actually have a nightmare. On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY

Re: Missing maven-bundle-plugin Jar file in Maven Central...

This should be fixed now --Brian (mobile) > On May 9, 2017, at 3:01 PM, Brian Fox <bri...@infinity.nu> wrote: > > Could be an endpoint problem. I'll find out and get the cache kicked. > > --Brian (mobile) > > >> On May 9, 2017, at 1:15 PM, Karl Heinz M

Re: Missing maven-bundle-plugin Jar file in Maven Central...

Could be an endpoint problem. I'll find out and get the cache kicked. --Brian (mobile) > On May 9, 2017, at 1:15 PM, Karl Heinz Marbaise wrote: > > Hi, > > I just tested it from here (germany) : > >

Re: Revised proposal for #AutomaticModuleNames

On Fri, May 5, 2017 at 10:41 AM, wrote: > I suspect what you really mean is "Never publish JARs that refer to > automatic modules that do not have `Automatic-Module-Name` attributes". > In general that's good advice. > +1 For me, the point of the attribute was to allow

Re: Revised proposal for #AutomaticModuleNames

On Thu, May 4, 2017 at 1:39 PM, <mark.reinh...@oracle.com> wrote: > Thanks to everyone, and especially Stephen Colebourne, Brian Fox, and > Robert Scholte, for the extensive feedback. > > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/ > 2017-May/000687.html >

Re: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

On Wed, Apr 26, 2017 at 12:27 PM, wrote: > If one of those automatic modules is modularized later on, and given a > different name, then how is having to fix that materially different from > having to fix code that was using a package that's no longer exported? > If

Re: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

Here's one I'm familiar with: https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html At least within Maven, it's a known best practice to ensure you're not dependent on transitives. On Tue, Apr 25, 2017 at 11:44 AM, wrote: > 2017/4/25 6:53:45

Re: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

On Tue, Apr 25, 2017 at 9:10 AM, David M. Lloyd wrote: > I agree with everything except for this last point. I think that, given > the amount of evangelism over the past 5 or so years, people will adopt > JPMS whether or not it is a fit for their use case. Different

Re: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

I completely agree with Stephen. While it's technically true you can consider all the exports to be part of the API, the reality is that most libraries aren't used that way. In fact, there are commonly accepted tools to detect when you are depending on a transitive dependency that isn't

Re: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

On Mon, Apr 24, 2017 at 12:14 PM, wrote: > The problem with any approach that allows you to give a stable name to > what is otherwise an automatic module is that the API of that module is > inherently unstable. If and when the module is completely modularized > then

Jigsaw removes the ability for tools to help name transition

Robert and I wrote a bit previously [1] about the issues with the automodules in jigsaw (hint: they use only the filename to default a module which we've demonstrated is a terrible idea). There was a happy medium which would have allowed library developers to select a name before full

Build tools can help, if you let us

very quick for the ecosystem to get to a sane building point for full modularization. Without the Module-Name metadata or some equivalent, you are effectively barring all the build systems from helping with the conversion to achieve the very goal of this entire process. --Brian Fox

Re: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

path between now and when this hits critical mass. Now that it's out the window, we're right back where we started from. On Wed, Apr 5, 2017 at 1:17 AM, <mark.reinh...@oracle.com> wrote: > 2017/4/4 2:38:37 -0700, Brian Fox <bri...@infinity.nu>: > > Mark I think s

Re: #VersionsInModuleNames

The standard within the scala ecosystem is to append the runtime version to the artifactid, making every scala module out of compliance with the proposal. On Wed, Mar 15, 2017 at 4:00 PM, Robert Scholte wrote: > On Wed, 15 Mar 2017 11:13:25 +0100, Stephen Colebourne < >

Re: How to name modules, automatic and otherwise

This seems sensible and not unfamiliar with how import statements already work in Java to determine the fqn to search for a given class. On Fri, Feb 17, 2017 at 4:07 AM, Michael Rasmussen < michael.rasmus...@zeroturnaround.com> wrote: > On 17 February 2017 at 01:19, Stephen Colebourne

Re: Fwd: How to name modules, automatic and otherwise

> this in the future. Maybe it would be good if all Apache project and > others > > that are going to publish modules start with using the full namespace in > > the module name. Problem is of course that the examples I saw so far all > do > > NOT do that

Re: Fwd: How to name modules, automatic and otherwise

build up the right practices before jigsaw takes off. > > -- > Regards, > Igor > > On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote: > > I generally agree the concerns were mostly ignored. Specifically the > > dangers in not carefully approaching and setting best pr

Re: How to name modules, automatic and otherwise

Thanks for the follow up Mark. I obviously don't completely agree with all of the assumptions and that's ok. I do however applaud the inclusion of the Module-Name into the algorithm. This gives enough of a hook that tools like Maven can hopefully send the ecosystem down a smooth transition path,

Re: Fwd: How to name modules, automatic and otherwise

ame modules, automatic and otherwise > > Date: Thu, 16 Feb 2017 17:48:27 +0100 > > > > This note is in reply to the concerns about automatic modules raised by > > Robert Scholte and Brian Fox [1], and by Stephen Colebourne and others > > [2]. I've collected my con

Re: Automatic module names

On Fri, Feb 3, 2017 at 10:40 AM, Alan Bateman wrote: > As regards the example naming clash then these two projects might already > get complaints over their poor choice of artifacts, esp. when artifacts for > both projects are in same directory (say where someone

Re: Automatic module names

In my mind, proposal 2 (eliminating automobiles) is infinitely preferable to what we have today. The one downside as compared to leveraging the existing coordinates (proposal 1) is that it doesn't do anything to set a best practice in what good names look like. If nothing else, the maven

Re: Unable to close staging repository on repository.apache.org

I looked a little closer, the servers are up and your key 843ddb767188601c is not there. Make sure you've published your key to the pgp servers and that you can search it from here: http://pool.sks-keyservers.net:11371/ On Thu, May 26, 2016 at 6:15 PM, Brian Fox <bri...@infinity.nu>

Re: Unable to close staging repository on repository.apache.org

When this happens, it's a failure in the pgp key server ring and despite the fact that the ring is meant to distribute load, they all seem to go down at the same time. There isn't actually anything we can do on the rao side to make this work besides drop the staging rule that checks the key. I

Re: Board feedback on 2016-05-18 Creadur report

On Mon, May 23, 2016 at 2:13 PM, Bertrand Delacretaz wrote: > On Sun, May 22, 2016 at 4:42 PM, Sam Ruby wrote: > > ...Perhaps the content of the emails should contain a standard footer > > that says that questions can be addressed either by

Re: Jira access for new committer

Added simpligility to maven-dev On Wed, Jun 24, 2015 at 12:38 AM, Barrie Treloar baerr...@gmail.com wrote: I've pinged Brian to have a look. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands,

[jira] [Updated] (MPH-10) NPE when -Dplugin value can not find specified plugin

[ https://issues.apache.org/jira/browse/MPH-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MPH-10: - Reporter: Barrie Treloar (was: Barrie Treloar) NPE when -Dplugin value can not find specified plugin

Re: [VOTE] Add Manfred Moser as committer

+1 --mobile On May 13, 2015, at 2:55 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Hi, I'd like to introduce Manfred Moser as committer for the Apache Maven project. He's working on Android Maven plugin for years, has great discussions both on users and dev MLs, has a great

Re: [RDF] grant Commons RDF (incubating) permission to deploy artifacts to org.apache.commons groupId

As there is no ldap group for the podling, can you please file an infra jira with the user ids to be added? On Tue, May 5, 2015 at 9:53 AM, Sergio Fernández wik...@apache.org wrote: Hi, the CommonsRDF podling is preparing the fist incubating release, and the PPMC members need to be granted

  1   2   3   4   5   6   7   8   9   10   >