Hello everyone, FWIW Gradle has come up with its own metadata format (announced at https://blog.gradle.org/gradle-metadata-1.0, explained at https://github.com/gradle/gradle/blob/f6a98158e75a636245f70d46604fcab3152361e8/subprojects/docs/src/docs/design/gradle-module-metadata-1.0-specification.md )
Perhaps here's an opportunity to collaborate and decide on a common format and/or features that benefit all of us, what do you think? Cheers, Andres ------------------------------------------- Java Champion; Groovy Enthusiast JCP EC Associate Seat http://andresalmiray.com http://www.linkedin.com/in/aalmiray -- What goes up, must come down. Ask any system administrator. There are 10 types of people in the world: Those who understand binary, and those who don't. To understand recursion, we must first understand recursion. On Mon, May 6, 2019 at 7:15 PM Robert Scholte <[email protected]> wrote: > Assuming we need a new metadatafile in the future to extend/enrich the > current pom file, do you think it would fit in something like a PDT > file[1]? > > If so, please at a comment so we can take it into account when working on > new specifications. > > Robert > > [1] > > https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema > > On Mon, 06 May 2019 10:03:33 +0200, Christofer Dutz > <[email protected]> wrote: > > > Hi all, > > > > I am currently working hard on adding support for other languages in > the > > PLC4X maven build. While working on the python I noticed that they have > > some sort of maturity self-assessment metadata in their artifacts and I > > think that actually quite a good thing. > > > > Doing some research I couldn’t find any means to provide similar data > > for maven. > > > > In PLC4X we have a lot of modules. Some are older and mature, but > others > > we’d like to mark as experimental. > > It would be great if we could also provide enforcer rules to for > example > > allow only mature modules or modules with a maturity scoring of at > least > > X … > > > > I thing we could achieve something like this manually, by providing > > metadata in form of resources in the jars and custom enforcer modules, > > but that would be an island solution only working in our domain. I > think > > this could be beneficial to the entire Maven ecosystem to have > something > > more generic in the system itself. > > > > Any thoughts & suggestions on this? > > > > Chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
