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
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
Ok ...
And what's the:
4.0.0
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
On Wed, 08 May 2019 09:32:42 +0200, Christofer Dutz
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
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
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
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
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
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]
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
10 matches
Mail list logo
