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" <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

Reply via email to