You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Christofer Dutz <ch...@c-ware.de> on 2019/05/06 08:03:33 UTC
Additional Maturity Metadata in artifacts (especially in the pom)?
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
Re: Additional Maturity Metadata in artifacts (especially in the
pom)?
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Robert,
well how it's implemented in the end I don't really have any strong feelings. It just felt as if a 4.1.0 pom would make sense.
If in the end I am able to provide metadata, this metadata survives distribution through repository managers and we have
tooling to help utilize that information (enforcer-plugin-module to check a certain minimal maturity), then all is good.
I just noticed then working on the python stuff, that they had this and thought it would be great to have it in Maven too ;-)
Chris
Am 08.05.19, 23:18 schrieb "Robert Scholte" <rf...@apache.org>:
Remote repositories should always provide a model 4.0.0 pom, otherwise
tools including all currently known Maven versions will not work. The
first check is if the modelVersion is 4.0.0, otherwise Maven will simply
stop working.
Since the pom on the system is copied/uploaded as-is, there's no way to do
real improvements on the pom right now. This is quite hardened is Maven
Core. So one of the things we are working on is implementing a way where
the build-pom can be adjusted to a valid 4.0.0 before being published.
Maven 3.6.x already contains a couple of preparations.
Once there's a separation, real improvements can be done. And then it
makes sense to keep the the pom for builds, upload it as 4.0.0 and some
new + improved format.
Robert
On Wed, 08 May 2019 22:48:38 +0200, Christofer Dutz
<ch...@c-ware.de> wrote:
> Ok ...
>
> And what's the:
> <modelVersion>4.0.0</modelVersion>
> And the:
> xmlns="http://maven.apache.org/POM/4.0.0"
> About?
>
> One should think that a system like Nexus should be able to be extended
> to support multiple POM Versions ...
> So as this metadata adds new features, wouldn't this simply be a
> modelVersion=4.1.0?
>
> Chris
>
>
>
>
> Am 08.05.19, 20:38 schrieb "Robert Scholte" <rf...@apache.org>:
>
> On Wed, 08 May 2019 09:32:42 +0200, Christofer Dutz
> <ch...@c-ware.de> wrote:
> > Well depending on how much metadata should be added ...
> >
> > Guess we already have a lot of stuff in the pom.xml which is
> considered
> > metadata ... having some additional optional elements shouldn't
> break
> > anything (I think)
> This part is actually very tricky. We've done it recently in order to
> control SCM path resolution, but it did break at several places, e.g.
> uploads to Centrals didn't work, because poms are validated against
> the
> 4.0.0 XSD [1]. As you can see the 4.0.0 has been updated while
> keeping the
> same version, not that elegant.
> If there is a place in the current version (e.g. existing String
> element
> with new value) we could consider it, otherwise I would like to push
> it
> forward.
> thanks,
> Robert
> [1] http://maven.apache.org/xsd/maven-4.0.0.xsd (look for attributes
> with
> child.scm)
> > But adding some additional files exclusively used for metadata might
> > also be an option ... would this be alongside the pom and
> artifacts or
> > inside the artifacts as static resources?
> > Cause having additional files alongside the pom and jar artifacts
> for
> > example could require changing the tooling ... jar-embedded or
> > pom-embedded resources should work out of the box.
> >
> > Chris
> >
> > Am 06.05.19, 19:15 schrieb "Robert Scholte" <rf...@apache.org>:
> >
> > 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
> > <ch...@c-ware.de> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Additional Maturity Metadata in artifacts (especially in the
pom)?
Posted by Robert Scholte <rf...@apache.org>.
Remote repositories should always provide a model 4.0.0 pom, otherwise
tools including all currently known Maven versions will not work. The
first check is if the modelVersion is 4.0.0, otherwise Maven will simply
stop working.
Since the pom on the system is copied/uploaded as-is, there's no way to do
real improvements on the pom right now. This is quite hardened is Maven
Core. So one of the things we are working on is implementing a way where
the build-pom can be adjusted to a valid 4.0.0 before being published.
Maven 3.6.x already contains a couple of preparations.
Once there's a separation, real improvements can be done. And then it
makes sense to keep the the pom for builds, upload it as 4.0.0 and some
new + improved format.
Robert
On Wed, 08 May 2019 22:48:38 +0200, Christofer Dutz
<ch...@c-ware.de> wrote:
> Ok ...
>
> And what's the:
> <modelVersion>4.0.0</modelVersion>
> And the:
> xmlns="http://maven.apache.org/POM/4.0.0"
> About?
>
> One should think that a system like Nexus should be able to be extended
> to support multiple POM Versions ...
> So as this metadata adds new features, wouldn't this simply be a
> modelVersion=4.1.0?
>
> Chris
>
>
>
>
> Am 08.05.19, 20:38 schrieb "Robert Scholte" <rf...@apache.org>:
>
> On Wed, 08 May 2019 09:32:42 +0200, Christofer Dutz
> <ch...@c-ware.de> wrote:
> > Well depending on how much metadata should be added ...
> >
> > Guess we already have a lot of stuff in the pom.xml which is
> considered
> > metadata ... having some additional optional elements shouldn't
> break
> > anything (I think)
> This part is actually very tricky. We've done it recently in order to
> control SCM path resolution, but it did break at several places, e.g.
> uploads to Centrals didn't work, because poms are validated against
> the
> 4.0.0 XSD [1]. As you can see the 4.0.0 has been updated while
> keeping the
> same version, not that elegant.
> If there is a place in the current version (e.g. existing String
> element
> with new value) we could consider it, otherwise I would like to push
> it
> forward.
> thanks,
> Robert
> [1] http://maven.apache.org/xsd/maven-4.0.0.xsd (look for attributes
> with
> child.scm)
> > But adding some additional files exclusively used for metadata might
> > also be an option ... would this be alongside the pom and
> artifacts or
> > inside the artifacts as static resources?
> > Cause having additional files alongside the pom and jar artifacts
> for
> > example could require changing the tooling ... jar-embedded or
> > pom-embedded resources should work out of the box.
> >
> > Chris
> >
> > Am 06.05.19, 19:15 schrieb "Robert Scholte" <rf...@apache.org>:
> >
> > 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
> > <ch...@c-ware.de> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Additional Maturity Metadata in artifacts (especially in the
pom)?
Posted by Christofer Dutz <ch...@c-ware.de>.
Ok ...
And what's the:
<modelVersion>4.0.0</modelVersion>
And the:
xmlns="http://maven.apache.org/POM/4.0.0"
About?
One should think that a system like Nexus should be able to be extended to support multiple POM Versions ...
So as this metadata adds new features, wouldn't this simply be a modelVersion=4.1.0?
Chris
Am 08.05.19, 20:38 schrieb "Robert Scholte" <rf...@apache.org>:
On Wed, 08 May 2019 09:32:42 +0200, Christofer Dutz
<ch...@c-ware.de> wrote:
> Well depending on how much metadata should be added ...
>
> Guess we already have a lot of stuff in the pom.xml which is considered
> metadata ... having some additional optional elements shouldn't break
> anything (I think)
This part is actually very tricky. We've done it recently in order to
control SCM path resolution, but it did break at several places, e.g.
uploads to Centrals didn't work, because poms are validated against the
4.0.0 XSD [1]. As you can see the 4.0.0 has been updated while keeping the
same version, not that elegant.
If there is a place in the current version (e.g. existing String element
with new value) we could consider it, otherwise I would like to push it
forward.
thanks,
Robert
[1] http://maven.apache.org/xsd/maven-4.0.0.xsd (look for attributes with
child.scm)
> But adding some additional files exclusively used for metadata might
> also be an option ... would this be alongside the pom and artifacts or
> inside the artifacts as static resources?
> Cause having additional files alongside the pom and jar artifacts for
> example could require changing the tooling ... jar-embedded or
> pom-embedded resources should work out of the box.
>
> Chris
>
> Am 06.05.19, 19:15 schrieb "Robert Scholte" <rf...@apache.org>:
>
> 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
> <ch...@c-ware.de> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Additional Maturity Metadata in artifacts (especially in the
pom)?
Posted by Robert Scholte <rf...@apache.org>.
On Wed, 08 May 2019 09:32:42 +0200, Christofer Dutz
<ch...@c-ware.de> wrote:
> Well depending on how much metadata should be added ...
>
> Guess we already have a lot of stuff in the pom.xml which is considered
> metadata ... having some additional optional elements shouldn't break
> anything (I think)
This part is actually very tricky. We've done it recently in order to
control SCM path resolution, but it did break at several places, e.g.
uploads to Centrals didn't work, because poms are validated against the
4.0.0 XSD [1]. As you can see the 4.0.0 has been updated while keeping the
same version, not that elegant.
If there is a place in the current version (e.g. existing String element
with new value) we could consider it, otherwise I would like to push it
forward.
thanks,
Robert
[1] http://maven.apache.org/xsd/maven-4.0.0.xsd (look for attributes with
child.scm)
> But adding some additional files exclusively used for metadata might
> also be an option ... would this be alongside the pom and artifacts or
> inside the artifacts as static resources?
> Cause having additional files alongside the pom and jar artifacts for
> example could require changing the tooling ... jar-embedded or
> pom-embedded resources should work out of the box.
>
> Chris
>
> Am 06.05.19, 19:15 schrieb "Robert Scholte" <rf...@apache.org>:
>
> 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
> <ch...@c-ware.de> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Additional Maturity Metadata in artifacts (especially in the
pom)?
Posted by Christofer Dutz <ch...@c-ware.de>.
Well depending on how much metadata should be added ...
Guess we already have a lot of stuff in the pom.xml which is considered metadata ... having some additional optional elements shouldn't break anything (I think)
But adding some additional files exclusively used for metadata might also be an option ... would this be alongside the pom and artifacts or inside the artifacts as static resources?
Cause having additional files alongside the pom and jar artifacts for example could require changing the tooling ... jar-embedded or pom-embedded resources should work out of the box.
Chris
Am 06.05.19, 19:15 schrieb "Robert Scholte" <rf...@apache.org>:
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
<ch...@c-ware.de> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Additional Maturity Metadata in artifacts (especially in the pom)?
Posted by Andres Almiray <aa...@gmail.com>.
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 <rf...@apache.org> 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 <aa...@gmail.com>
> 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 <rf...@apache.org>
> > 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
> >> <ch...@c-ware.de> 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: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Additional Maturity Metadata in artifacts (especially in the
pom)?
Posted by Robert Scholte <rf...@apache.org>.
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 <aa...@gmail.com>
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 <rf...@apache.org>
> 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
>> <ch...@c-ware.de> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Additional Maturity Metadata in artifacts (especially in the pom)?
Posted by Andres Almiray <aa...@gmail.com>.
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 <rf...@apache.org> 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
> <ch...@c-ware.de> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Additional Maturity Metadata in artifacts (especially in the
pom)?
Posted by Robert Scholte <rf...@apache.org>.
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
<ch...@c-ware.de> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org