A “maven-rfc” repo is a good idea if the issue of governance can be worked out. There will be a good deal of overhead related to maintaining, gatekeeping, and administration of such a repository. If RFC’s were just specs with problem statements, decision records that might be easier. An RFC should also be sponsored/owned by a committer. The work could happen in a fork somewhere that was established by the sponsor who could then manage whether to leave it wide open for contribution or to a select few.
As for Bernd’s question and the “Handling sensitive data in Maven” wiki, couldn’t this problem be solved by injecting an implementation of org.apache.maven.settings.building.SettingsBuilder to suite your needs? For example, I could have a SettingsBuilder that gets settings from some on-line storage (imagine a build environment where “settings.xml" is centralized). On 2024/06/05 20:31:40 Tamás Cservenák wrote: > Asf wiki is not the best place for brainstorming, as is usable only for > people w asf accounts (i guess). > > What if we create a repo like "maven-rfc", where anyone can raise PRs (new > functionality, change requests or just ideas), these would be like > "proposals", that we discuss and modify specs w PRs, and once proposal > considered "complete", it can be moved to "to be implemented" state (those > could be plain directories), maybe even version those things? > > And then implementation can happen based on documented > requirements/functionality? > > T > > On Wed, Jun 5, 2024, 20:27 Tamás Cservenák > <ta...@cservenak.net<mailto:ta...@cservenak.net>> wrote: > > > Howdy, > > > > Bernd, I would be very interested to collect some ideas to solve exactly > > this problem... > > When I revamped maven-gpg-plugin re "worst practices", I started tinkering > > about this... > > > > Created page just to gather ideas... > > > > https://cwiki.apache.org/confluence/display/MAVEN/Handling+sensitive+data+in+Maven > > > > Unsure is this editable for you... we may want some other place for > > brainstorming? > > > > Thanks > > T > > > > On Wed, Jun 5, 2024 at 7:24 PM Bernd Eckenfels > > <ec...@zusammenkunft.net<mailto:ec...@zusammenkunft.net>> > > wrote: > > > >> BTW Speaking of “custom”, I would be very interested in > >> a token based authentication, at least for read access to > >> our repository server and mirror, we currently ship a static > >> read-only login, and also we don’t want to allow putting > >> their write (LDAP Login) credentials into files. > >> > >> If the maven ecosystem would have a OS/Token method > >> like requestin a JWT token from a distribution point which > >> uses native Kerberos SSPI or user certificates that would > >> greatly improve this, > >> > >> What’s your plan for that auth, can you upstream it? > >> > >> Gruß > >> Bernd > >> > >> David Grieve wrote on 4. June 2024 20:33 (GMT +02:00): > >> > >> > Thank you for the hint, Tamás. > >> > > >> > The problem I’m trying to solve is that I want a custom Authentication > >> > for a particular server. I do not want to re-implement HttpTransporter. > >> > Here are the important bits of what I’ve come up with. > >> > ---------------------------------- > >> > public class MyTransporterFactory implements TransporterFactory { > >> > > >> > // copied from > >> > org.eclipse.aether.transport.http.HttpTransporterFactory > >> > private static Map<String, ChecksumExtractor> > >> > getManuallyCreatedExtractors() { > >> > HashMap<String, ChecksumExtractor> map = new HashMap<>(); > >> > map.put(Nexus2ChecksumExtractor.NAME, new > >> > Nexus2ChecksumExtractor()); > >> > map.put(XChecksumChecksumExtractor.NAME, new > >> > XChecksumChecksumExtractor()); > >> > return Collections.unmodifiableMap(map); > >> > } > >> > > >> > // I’m not happy with this... > >> > private final HttpTransporterFactory httpTransporterFactory = new > >> > HttpTransporterFactory(getManuallyCreatedExtractors()); > >> > > >> > @Override > >> > public Transporter newInstance(RepositorySystemSession session, > >> > RemoteRepository repository) throws NoTransporterException { > >> > > >> > if (requiresSpecialAuth(repository)) { > >> > repository = new RemoteRepository.Builder(repository) > >> > .setAuthentication(new MyAuthentication(repository)) > >> > .build(); > >> > } > >> > return httpTransporterFactory.newInstance(session, repository); > >> > } > >> > ---------------------------------- > >> > > >> > Then “MyAuthentication” does the right thing for the fill method. > >> > > >> > This approach is working for me, but I’d be interested to know if there > >> > is a better way. I do not want to re-implement HttpTransport! > >> > > >> > > >> > On 2024/06/03 20:25:48 Tamás Cservenák wrote: > >> >> Howdy, > >> >> > >> >> What are you trying to do? You may go better if you implement custom > >> >> (resolver) transport maybe? > >> — > >> https://bernd.eckenfels.net > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: > >> users-unsubscr...@maven.apache.org<mailto:users-unsubscr...@maven.apache.org> > >> For additional commands, e-mail: > >> users-h...@maven.apache.org<mailto:users-h...@maven.apache.org> > >> > >> >
