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" <rfscho...@apache.org>:
On Wed, 08 May 2019 09:32:42 +0200, Christofer Dutz
<christofer.d...@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" <rfscho...@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
> <christofer.d...@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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org