It does seem some kind of list or something similar to the stacks.yaml is ideal. This could potentially be useful in other projects like JBDS too.

One small note too, the plugin artifact id should probably be "dependency-checker-maven-plugin" to stick with the common naming conventions.

On 12/12/2012 01:10 PM, Rafael Benevides wrote: > > Hi all, > > For the maven-dependency-checker plugin (more details bellow or at > https://github.com/jboss/maven-dependency-checker ) we have 3 major > features: > > 1. Detect unsupported dependency versions. > > 2. Detect api dependencies that should be relocated to corresponding > jboss-spec artifacts > > 3. Provide an excludes configuration to tell the plugin to ignore > things that the user is intentionally not using a supported version > of - especially for cases where there is no supported version > > For feature #1 I basically check if the GAV version has the -redhat-N > prefix but this is not working for all cases since there are many > libraries that is supported and it's not rebuilt by Red Hat. One > example is the Spring Sports Club in WFK. > > I would like suggestions how can this plugin check if GAV is a > supported version. We can start thinking about having a properties > file with this information, but the management cost of that seems too > high. Maybe we can find an alternative way. > > I'm opened to suggestion. > > Thank you > > > -------- Mensagem original -------- > Assunto: Re: Design of maven plugin to verify supported versions > Data: Wed, 14 Nov 2012 18:27:09 -0200 > De: Rafael Benevides <benevides(a)redhat.com&gt; > Empresa: Red Hat > Para: John Casey <jcasey(a)redhat.com&gt; > CC: Enterprise Maven Repo (Project Wolf) > <enterprise-maven-list(a)redhat.com&gt;, Pete Muir <pmuir(a)redhat.com&gt; > > > > Hi all, > > > Today, I pushed a new version of the maven-dependency-checker plugin > with the following changes: > > 1 - The relocated dependencies is checked on groupId and artifactId > of the declared dependency. So it's now possible to detect uses of > example: org.glassfish.main:javax.ejb and propose the right relocate > dependency > > 2 - Pete gave an excelent suggestion to check if a dependency has a > BOM for it. So it uses the JBoss Stacks project > (http://www.jboss.org/jdf/stack/stacks/) to discover all BOMs and > them it looks for matches on the managed BOM dependencies and project > dependencies. > > 3 - The Readme instructions was updated with instructions on how to > use the plugin on command line without needing to add it on the > project pom.xml. > > > I believe that it's now ready to start using it. > > Thank you. > > Em 12-11-2012 11:44, Rafael Benevides escreveu: >> The first functional version is available here: >> https://github.com/rafabene/maven-dependency-checker >> >> Please, >> >> Feel free to provide any feedback. >> >> Cheers >> >> Em 08-11-2012 12:53, John Casey escreveu: >>> I've started working with rbenevides on the Maven plugin we >>> discussed yesterday. He's jumping into coding the first version, >>> but I wanted to reflect the requirements we discussed on IRC so we >>> can get feedback. >>> >>> Basically, it does three things: >>> >>> 1. Detect unsupported dependency versions. >>> >>> 2. Detect api dependencies that should be relocated to >>> corresponding jboss-spec artifacts >>> >>> 3. Provide an excludes configuration to tell the plugin to ignore >>> things that the user is intentionally not using a supported version >>> of - especially for cases where there is no supported version >>> >>> >>> For #1, it's not clear whether we need to be verifying that the >>> dependencies used are from the same product release. If so, this >>> will be a fair bit more complicated, as we'll need to download a >>> product definition in terms of artifacts. >>> >>> Additionally, we would probably want to provide a flag to switch >>> between WARN vs FAIL modes. >>> >>> For relocations, we're currently thinking of loading the list >>> either from a maven artifact (type == properties, perhaps), or else >>> from some Git repository. >>> >>> This is a fairly lightweight sketch, but are there any >>> questions/concerns so far? > > > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jdf-dev -- James R. Perkins JBoss by Red Hat _______________________________________________ jdf-dev mailing list jdf-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jdf-dev

Hi Rafael, in WFK we use Spring BOMs (one per Spring version certified). Spring BOM is released with -redhat-1 version in WFK Enterprise Maven Repository, however contains upstream (e.g. Maven Central) dependencies that are certified. So one of the suggestions would be to check if there is any enterprise BOM (including JDF ones) that contain dependency version in question. I think this should work, problematic part would be how to figure out what are the supported enterprise BOM (maybe agree on groupId or at least its prefix (com.redhat.jboss. ?, so the searched space could be reduced).

Having a BOM with customers would make dependency management easier for customers, a nice positive side effect. Karel On Wed, 12 Dec 2012 19:10:54 -0200 Rafael Benevides&lt;benevides(a)redhat.com&gt; wrote: > Hi all, > > For the maven-dependency-checker plugin (more details bellow or at > https://github.com/jboss/maven-dependency-checker ) we have 3 major > features: > > 1. Detect unsupported dependency versions. > > 2. Detect api dependencies that should be relocated to corresponding > jboss-spec artifacts > > 3. Provide an excludes configuration to tell the plugin to ignore things > that the user is intentionally not using a supported version of - > especially for cases where there is no supported version > > For feature #1 I basically check if the GAV version has the -redhat-N > prefix but this is not working for all cases since there are many > libraries that is supported and it's not rebuilt by Red Hat. One example > is the Spring Sports Club in WFK. > > I would like suggestions how can this plugin check if GAV is a supported > version. We can start thinking about having a properties file with this > information, but the management cost of that seems too high. Maybe we > can find an alternative way. > > I'm opened to suggestion. > > Thank you > > > -------- Mensagem original -------- > Assunto: Re: Design of maven plugin to verify supported versions > Data: Wed, 14 Nov 2012 18:27:09 -0200 > De: Rafael Benevides&lt;benevides(a)redhat.com&gt; > Empresa: Red Hat > Para: John Casey&lt;jcasey(a)redhat.com&gt; > CC: Enterprise Maven Repo (Project Wolf) > <enterprise-maven-list(a)redhat.com&gt;, Pete Muir&lt;pmuir(a)redhat.com&gt; > > > > Hi all, > > > Today, I pushed a new version of the maven-dependency-checker plugin > with the following changes: > > 1 - The relocated dependencies is checked on groupId and artifactId of > the declared dependency. So it's now possible to detect uses of example: > org.glassfish.main:javax.ejb and propose the right relocate dependency > > 2 - Pete gave an excelent suggestion to check if a dependency has a BOM > for it. So it uses the JBoss Stacks project > (http://www.jboss.org/jdf/stack/stacks/) to discover all BOMs and them > it looks for matches on the managed BOM dependencies and project > dependencies. > > 3 - The Readme instructions was updated with instructions on how to use > the plugin on command line without needing to add it on the project pom.xml. > > > I believe that it's now ready to start using it. > > Thank you. > > Em 12-11-2012 11:44, Rafael Benevides escreveu: >> The first functional version is available here: >> https://github.com/rafabene/maven-dependency-checker >> >> Please, >> >> Feel free to provide any feedback. >> >> Cheers >> >> Em 08-11-2012 12:53, John Casey escreveu: >>> I've started working with rbenevides on the Maven plugin we discussed >>> yesterday. He's jumping into coding the first version, but I wanted >>> to reflect the requirements we discussed on IRC so we can get feedback. >>> >>> Basically, it does three things: >>> >>> 1. Detect unsupported dependency versions. >>> >>> 2. Detect api dependencies that should be relocated to corresponding >>> jboss-spec artifacts >>> >>> 3. Provide an excludes configuration to tell the plugin to ignore >>> things that the user is intentionally not using a supported version >>> of - especially for cases where there is no supported version >>> >>> >>> For #1, it's not clear whether we need to be verifying that the >>> dependencies used are from the same product release. If so, this will >>> be a fair bit more complicated, as we'll need to download a product >>> definition in terms of artifacts. >>> >>> Additionally, we would probably want to provide a flag to switch >>> between WARN vs FAIL modes. >>> >>> For relocations, we're currently thinking of loading the list either >>> from a maven artifact (type == properties, perhaps), or else from >>> some Git repository. >>> >>> This is a fairly lightweight sketch, but are there any >>> questions/concerns so far?