Indeed. I'm willing to work as liaison for Gradle :-) Let's make it work!
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 8:03 PM Robert Scholte <[email protected]> wrote: > Some already know about my plan/wish to bring experts representing the > different buildtools, IDEs and artifact repositories together and work an > a new specification. > I am aware of the Gradle papers, haven't compared them yet with our first > proposals yet. > I'm sure we have the same goal, but this will only work if all related > parties join. > > thanks, > Robert > > > On Mon, 06 May 2019 19:53:58 +0200, Andres Almiray <[email protected]> > wrote: > > > 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] > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
