Re: Defining a property designed to be overridden?
Hi, > I get the sense that adding is something that would > upset IDEs (my experience has been that they cope relatively poorly > with anything uncommon like that). My group uses "" a lot in IDEs including Eclipse, NetBeans and IDEA, and it works for us. I suggest giving it a try and seeing if it causes you any problems. Of course, in your case, since you have multi-module builds, you probably actually _want_ the default behavior of ".." for your submodules, so maybe you don't want to change anything. > Can a module name contain slashes? Sure can! It's a relative directory path. > I will give it a go. I've had somewhat poor experiences with the Maven > APIs as they tend not to be documented too well. Yeah, me too. I've found it pretty hard to get into Maven plugin development, especially since the APIs have gone through a few major iterations from 2.x to 3.0.x to 3.1.x etc. And in some cases, plugins mix and match APIs from those different iterations. :-O That said, this list (and the Maven dev list) is here for you. Others on this list know a lot more about it, and can help you win awards. > I may end up living with just not enforcing these things... Well, since this rule is mostly for you yourself, and not some nebulous cloud of community developers consuming your stuff, you can probably get away with a nice shell script that calls grep over your POMs, and barfs when various things are not found. Easy, right? Regards, Curtis -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden Did you know ImageJ has a forum? http://forum.imagej.net/ On Thu, Mar 2, 2017 at 1:34 PM,wrote: > On 2017-03-02T11:12:58 -0600 > Curtis Rueden wrote: > > > Hi, > > > > > I'd need to think a bit more about it, but I personally dislike > > > relativePath and have never used it (across hundreds of projects), > > > pretty much for the sorts of reasons you've described. Hard-coding > > > paths that represent links to other modules seems like a > > > horrendously bad idea. > > > > That is fair. I will point out, though, that if you do not specify the > > relativePath, then it is ".." by default. Best practice is to write > > "" if you explicitly do _not_ want Maven to check for the > > parent in the parent directory. Hence, if we implemented my > requireElements > > enhancement, the relativePath would be treated as ".." when one is not > > explicitly specified. > > Right. > > I get the sense that adding is something that would > upset IDEs (my experience has been that they cope relatively poorly > with anything uncommon like that). > > > I will also point out that each "" of a multi-module build is > also > > a hard-coded link to another module, which according to your reasoning, > > makes multi-module projects in general a horrendous idea. (And I am not > > being totally facetious here—I personally prefer never to use > multi-module > > projects at all. Though I would not go so far as to call them > > "horrendous"—they definitely have their uses.) > > Hehe, I probably overstated it a touch. I tend to think of the > entries slightly differently though: I consider them to be module names > that match the artifact ID of the submodule and also just happen to > correspond to the directory that contains the module's sources. They > don't inspire the same revulsion because they don't exist in my mental > model as filesystem paths. I'm not actually sure they are in Maven's > model either... Can a module name contain slashes? > > > > I've written a few plugins, but I'm not intimately familiar with the > > > Maven API: Shouldn't it be possible to recursively retrieve the parent > > > POMs from the reactor (and failing that, the local and remote > > > repositories) within the plugin? That would remove the need for > > > . > > > > Sure. You are absolutely welcome to file a PR against the > > scijava-maven-plugin adding this feature. The complication is just that > > instead of loading POMs from local files, you now also need to resolve > them > > from the appropriate remote repositories, for which there is certainly > > Maven API, but I am also not familiar enough with it to tell you what it > is > > off the top of my head. Hopefully someone else here can comment in more > > detail, and/or suggest alternative solutions here. In any case, if you > > pursue this, it should work to test locally by installing the plugin into > > your local repo cache using the "install" phase, and then using > > "org.scijava:scijava-maven-plugin:1.0.1-SNAPSHOT" in your test POMs. > > I will give it a go. I've had somewhat poor experiences with the Maven > APIs as they tend not to be documented too well. I may end up living > with just not enforcing these things... > > M >
Re: Defining a property designed to be overridden?
On 2017-03-02T11:12:58 -0600 Curtis Ruedenwrote: > Hi, > > > I'd need to think a bit more about it, but I personally dislike > > relativePath and have never used it (across hundreds of projects), > > pretty much for the sorts of reasons you've described. Hard-coding > > paths that represent links to other modules seems like a > > horrendously bad idea. > > That is fair. I will point out, though, that if you do not specify the > relativePath, then it is ".." by default. Best practice is to write > "" if you explicitly do _not_ want Maven to check for the > parent in the parent directory. Hence, if we implemented my requireElements > enhancement, the relativePath would be treated as ".." when one is not > explicitly specified. Right. I get the sense that adding is something that would upset IDEs (my experience has been that they cope relatively poorly with anything uncommon like that). > I will also point out that each "" of a multi-module build is also > a hard-coded link to another module, which according to your reasoning, > makes multi-module projects in general a horrendous idea. (And I am not > being totally facetious here—I personally prefer never to use multi-module > projects at all. Though I would not go so far as to call them > "horrendous"—they definitely have their uses.) Hehe, I probably overstated it a touch. I tend to think of the entries slightly differently though: I consider them to be module names that match the artifact ID of the submodule and also just happen to correspond to the directory that contains the module's sources. They don't inspire the same revulsion because they don't exist in my mental model as filesystem paths. I'm not actually sure they are in Maven's model either... Can a module name contain slashes? > > I've written a few plugins, but I'm not intimately familiar with the > > Maven API: Shouldn't it be possible to recursively retrieve the parent > > POMs from the reactor (and failing that, the local and remote > > repositories) within the plugin? That would remove the need for > > . > > Sure. You are absolutely welcome to file a PR against the > scijava-maven-plugin adding this feature. The complication is just that > instead of loading POMs from local files, you now also need to resolve them > from the appropriate remote repositories, for which there is certainly > Maven API, but I am also not familiar enough with it to tell you what it is > off the top of my head. Hopefully someone else here can comment in more > detail, and/or suggest alternative solutions here. In any case, if you > pursue this, it should work to test locally by installing the plugin into > your local repo cache using the "install" phase, and then using > "org.scijava:scijava-maven-plugin:1.0.1-SNAPSHOT" in your test POMs. I will give it a go. I've had somewhat poor experiences with the Maven APIs as they tend not to be documented too well. I may end up living with just not enforcing these things... M pgpNNHD4Cw4ln.pgp Description: OpenPGP digital signature
Re: Defining a property designed to be overridden?
Hi, > I'd need to think a bit more about it, but I personally dislike > relativePath and have never used it (across hundreds of projects), > pretty much for the sorts of reasons you've described. Hard-coding > paths that represent links to other modules seems like a > horrendously bad idea. That is fair. I will point out, though, that if you do not specify the relativePath, then it is ".." by default. Best practice is to write "" if you explicitly do _not_ want Maven to check for the parent in the parent directory. Hence, if we implemented my requireElements enhancement, the relativePath would be treated as ".." when one is not explicitly specified. I will also point out that each "" of a multi-module build is also a hard-coded link to another module, which according to your reasoning, makes multi-module projects in general a horrendous idea. (And I am not being totally facetious here—I personally prefer never to use multi-module projects at all. Though I would not go so far as to call them "horrendous"—they definitely have their uses.) > I've written a few plugins, but I'm not intimately familiar with the > Maven API: Shouldn't it be possible to recursively retrieve the parent > POMs from the reactor (and failing that, the local and remote > repositories) within the plugin? That would remove the need for > . Sure. You are absolutely welcome to file a PR against the scijava-maven-plugin adding this feature. The complication is just that instead of loading POMs from local files, you now also need to resolve them from the appropriate remote repositories, for which there is certainly Maven API, but I am also not familiar enough with it to tell you what it is off the top of my head. Hopefully someone else here can comment in more detail, and/or suggest alternative solutions here. In any case, if you pursue this, it should work to test locally by installing the plugin into your local repo cache using the "install" phase, and then using "org.scijava:scijava-maven-plugin:1.0.1-SNAPSHOT" in your test POMs. Regards, Curtis -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden On Thu, Mar 2, 2017 at 11:02 AM,wrote: > On 2017-03-02T10:29:30 -0600 > Curtis Rueden wrote: > > > > it seems that I can only require that the XML elements be overridden > > > in *all* descendant POMs, and this introduces too much redundancy. > > > > I see. > > > > Would it be sufficient if the requireElements rule had a multiModule flag > > which, if set, green-lighted the build when the stated elements are > defined > > in the local parent POM? This feature would assume you are using the > > aggregator==parent scheme, and follow the declared in the > > of each POM. If it finds a POM there, it would parse it and then > > check for the required elements in _that_ POM instead of the initial one. > > And do this recursively, in case you have a multi-layered multi-module > > build. > > > > The downside of this approach: modules of a project would only build if > the > > parent is available locally. E.g.: if you try to build one module of a > > multi-module build which has been physically disconnected from its parent > > (e.g., a partial SVN checkout), the enforcer would fail because it would > > not find the local parent POM to validate against. One can also imagine > > various "aggegator != parent" organizations where the parent is not > > available locally, which would also all fail to support this scheme. > > > > I'd need to think a bit more about it, but I personally dislike > relativePath and have never used it (across hundreds of projects), > pretty much for the sorts of reasons you've described. Hard-coding > paths that represent links to other modules seems like a horrendously > bad idea. > > I've written a few plugins, but I'm not intimately familiar with the > Maven API: Shouldn't it be possible to recursively retrieve the parent > POMs from the reactor (and failing that, the local and remote > repositories) within the plugin? That would remove the need for > . > > If that is possible, then I think the pseudocode is: > > let root(p) be the root POM of project p > let parent(p) be the parent of p > let definesElements(p) return true if p defines the required elements > > Project q = p > while (!done) { > if (q == root(p)) { > throw RequiredElementsMissing() > } > > if (definesElements(q)) { > done = true > } > > q = parent(p) > } > > This feels like it would achieve what I need with only minimal > assumptions about the hierarchy of projects. > > M >
Re: Defining a property designed to be overridden?
On 2017-03-02T10:29:30 -0600 Curtis Ruedenwrote: > > it seems that I can only require that the XML elements be overridden > > in *all* descendant POMs, and this introduces too much redundancy. > > I see. > > Would it be sufficient if the requireElements rule had a multiModule flag > which, if set, green-lighted the build when the stated elements are defined > in the local parent POM? This feature would assume you are using the > aggregator==parent scheme, and follow the declared in the > of each POM. If it finds a POM there, it would parse it and then > check for the required elements in _that_ POM instead of the initial one. > And do this recursively, in case you have a multi-layered multi-module > build. > > The downside of this approach: modules of a project would only build if the > parent is available locally. E.g.: if you try to build one module of a > multi-module build which has been physically disconnected from its parent > (e.g., a partial SVN checkout), the enforcer would fail because it would > not find the local parent POM to validate against. One can also imagine > various "aggegator != parent" organizations where the parent is not > available locally, which would also all fail to support this scheme. > I'd need to think a bit more about it, but I personally dislike relativePath and have never used it (across hundreds of projects), pretty much for the sorts of reasons you've described. Hard-coding paths that represent links to other modules seems like a horrendously bad idea. I've written a few plugins, but I'm not intimately familiar with the Maven API: Shouldn't it be possible to recursively retrieve the parent POMs from the reactor (and failing that, the local and remote repositories) within the plugin? That would remove the need for . If that is possible, then I think the pseudocode is: let root(p) be the root POM of project p let parent(p) be the parent of p let definesElements(p) return true if p defines the required elements Project q = p while (!done) { if (q == root(p)) { throw RequiredElementsMissing() } if (definesElements(q)) { done = true } q = parent(p) } This feels like it would achieve what I need with only minimal assumptions about the hierarchy of projects. M pgp1IyM3UMFWw.pgp Description: OpenPGP digital signature
Re: Defining a property designed to be overridden?
> it seems that I can only require that the XML elements be overridden > in *all* descendant POMs, and this introduces too much redundancy. I see. Would it be sufficient if the requireElements rule had a multiModule flag which, if set, green-lighted the build when the stated elements are defined in the local parent POM? This feature would assume you are using the aggregator==parent scheme, and follow the declared in the of each POM. If it finds a POM there, it would parse it and then check for the required elements in _that_ POM instead of the initial one. And do this recursively, in case you have a multi-layered multi-module build. The downside of this approach: modules of a project would only build if the parent is available locally. E.g.: if you try to build one module of a multi-module build which has been physically disconnected from its parent (e.g., a partial SVN checkout), the enforcer would fail because it would not find the local parent POM to validate against. One can also imagine various "aggegator != parent" organizations where the parent is not available locally, which would also all fail to support this scheme. Thoughts? -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden On Thu, Mar 2, 2017 at 9:13 AM,wrote: > 'Ello. > > On 2017-03-02T08:16:43 -0600 > Curtis Rueden wrote: > > > Hi, > > > > > I do actually want to enforce this, the issue is that I only want to > > > enforce it as far as the first ancestor. > > > > Sorry if you stated otherwise in your writeup, but my understanding is > that > > you want to define some empty properties in your new root POM, and then > > ensure they are _not_ empty in the next level down. Right? > > Yes, but additionally some XML elements as well. > > I'd like to enforce that: > > 1. Some properties that are defined as empty in the root POM are > non-empty in all descendants. > > 2. Some XML elements that are defined in the root POM (such as > issueManagement) are overridden _at least once_ between the root > and any leaf project. > > The requireProperty rule you provided does seem to properly handle point > 1, but I think that the options we've discussed are too heavy-handed > for point 2. Unless I've missed something obvious, it seems that I can > only require that the XML elements be overridden in *all* descendant > POMs, and this introduces too much redundancy. > > M >
Re: Defining a property designed to be overridden?
'Ello. On 2017-03-02T08:16:43 -0600 Curtis Ruedenwrote: > Hi, > > > I do actually want to enforce this, the issue is that I only want to > > enforce it as far as the first ancestor. > > Sorry if you stated otherwise in your writeup, but my understanding is that > you want to define some empty properties in your new root POM, and then > ensure they are _not_ empty in the next level down. Right? Yes, but additionally some XML elements as well. I'd like to enforce that: 1. Some properties that are defined as empty in the root POM are non-empty in all descendants. 2. Some XML elements that are defined in the root POM (such as issueManagement) are overridden _at least once_ between the root and any leaf project. The requireProperty rule you provided does seem to properly handle point 1, but I think that the options we've discussed are too heavy-handed for point 2. Unless I've missed something obvious, it seems that I can only require that the XML elements be overridden in *all* descendant POMs, and this introduces too much redundancy. M pgpx1cabVCYFf.pgp Description: OpenPGP digital signature
Re: Defining a property designed to be overridden?
Hi, > I do actually want to enforce this, the issue is that I only want to > enforce it as far as the first ancestor. Sorry if you stated otherwise in your writeup, but my understanding is that you want to define some empty properties in your new root POM, and then ensure they are _not_ empty in the next level down. Right? If so, then I think the requireProperty rule should be sufficient. You can write: org.apache.maven.plugins maven-enforcer-plugin 1.4.1 enforce-property enforce io7m.previous.version You must define the io7m.previous.version property! .+ You must set the io7m.previous.version property! true Regards, Curtis -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden On Thu, Mar 2, 2017 at 2:50 AM,wrote: > Hello! > > On 2017-03-01T15:49:10 -0600 > Curtis Rueden wrote: > > > > If what you want is to ensure the property is simply non-empty, or > matching > > a particular regex, then take a look at the requireProperty enforcer rule > > [1]. > > > > Or if your goal is to make sure that a property value _differs_ from the > > value defined in an ancestor, the requirePropertyDiverges rule [2] might > be > > for you. > > I do actually want to enforce this, the issue is that I only want to > enforce it as far as the first ancestor. My current projects look like > this (where indentation indicates inheritance): > > + io7m-jtensors > + io7m-jtensors-core > + io7m-jtensors-tests > + io7m-jtensors-ieee754b16 > + ... > + io7m-r2 > + io7m-r2-core > + io7m-r2-shaders > + ... > > I want to move to: > > + io7m-ancestor > + io7m-jtensors > + io7m-jtensors-core > + io7m-jtensors-tests > + io7m-jtensors-ieee754b16 > + ... > + io7m-r2 > + io7m-r2-core > + io7m-r2-shaders > + ... > > So I want to enforce that io7m-jtensors and io7m-r2 override the > required properties (and elements such as issueManagement), but I don't > want to propagate that requirement to the individual submodules of > io7m-jtensors such as io7m-jtensors-core, because this would introduce > pointless redundancy. I have around 50 top-level projects to manage in > this form, so any redundancy that can be eliminated really needs to be! > > I'm not sure the enforcer plugin is able to express this "only redefine > once" aspect of the above. Am I wrong? > > M >
Re: Defining a property designed to be overridden?
Hello! On 2017-03-01T15:49:10 -0600 Curtis Ruedenwrote: > > If what you want is to ensure the property is simply non-empty, or matching > a particular regex, then take a look at the requireProperty enforcer rule > [1]. > > Or if your goal is to make sure that a property value _differs_ from the > value defined in an ancestor, the requirePropertyDiverges rule [2] might be > for you. I do actually want to enforce this, the issue is that I only want to enforce it as far as the first ancestor. My current projects look like this (where indentation indicates inheritance): + io7m-jtensors + io7m-jtensors-core + io7m-jtensors-tests + io7m-jtensors-ieee754b16 + ... + io7m-r2 + io7m-r2-core + io7m-r2-shaders + ... I want to move to: + io7m-ancestor + io7m-jtensors + io7m-jtensors-core + io7m-jtensors-tests + io7m-jtensors-ieee754b16 + ... + io7m-r2 + io7m-r2-core + io7m-r2-shaders + ... So I want to enforce that io7m-jtensors and io7m-r2 override the required properties (and elements such as issueManagement), but I don't want to propagate that requirement to the individual submodules of io7m-jtensors such as io7m-jtensors-core, because this would introduce pointless redundancy. I have around 50 top-level projects to manage in this form, so any redundancy that can be eliminated really needs to be! I'm not sure the enforcer plugin is able to express this "only redefine once" aspect of the above. Am I wrong? M pgpqJtii9lFmz.pgp Description: OpenPGP digital signature
Re: Defining a property designed to be overridden?
Hi, > Note how this is a module of the root project and therefore it'd be > redundant to have to re-specify all of the information such as the > contributors, SCM location [0], etc. I only provide the information > that's specific to that module such as the OSGi manifest, > dependencies, etc. If what you want is to ensure the property is simply non-empty, or matching a particular regex, then take a look at the requireProperty enforcer rule [1]. Or if your goal is to make sure that a property value _differs_ from the value defined in an ancestor, the requirePropertyDiverges rule [2] might be for you. In my case, I really wanted to make sure that all those properties were (re)defined in the child POM, because otherwise, it was too easy for downstream developers to accidentally forget to override things propertly. E.g., the parent POM defines as the issue tracker for that parent POM itself—but this should never be inherited by the child; instead, every child should define its own for its own issue tracker. (If you don't have an issue tracker, you can write None to satisfy the enforcer.) Regards, Curtis [1] https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html [2] http://www.mojohaus.org/extra-enforcer-rules/ requirePropertyDiverges.html -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden Did you know ImageJ has a forum? http://forum.imagej.net/ On Wed, Mar 1, 2017 at 2:17 PM,wrote: > On 2017-03-01T12:46:45 -0600 > Curtis Rueden wrote: > > > > In this way, I ensure that all projects which extend our parent add all > the > > useful metadata and properties needed for successful builditude. > > > > Hm, slight issue with this. > > If you take a look at how my projects are usually designed: > > https://github.com/io7m/jtensors/blob/develop/pom.xml > > That's the root pom for the project. It defines all of the project's > information such as plugin versions, dependency versions, metadata such > as the SCM location, site, etc. > > Then, each module looks like this: > > https://github.com/io7m/jtensors/blob/develop/io7m-jtensors-core/pom.xml > > Note how this is a module of the root project and therefore it'd be > redundant to have to re-specify all of the information such as the > contributors, SCM location [0], etc. I only provide the information > that's specific to that module such as the OSGi manifest, dependencies, > etc. > > Using the scijava-maven-plugin RequireElements rule would seem to > require me to specify all of this information again in each module. > Is there a way to avoid this? > > M > > [0] Although I do actually have to re-specify the SCM location due to > an utterly ancient bug/design flaw in the site plugin. >
Re: Defining a property designed to be overridden?
On 2017-03-01T12:46:45 -0600 Curtis Ruedenwrote: > > In this way, I ensure that all projects which extend our parent add all the > useful metadata and properties needed for successful builditude. > Hm, slight issue with this. If you take a look at how my projects are usually designed: https://github.com/io7m/jtensors/blob/develop/pom.xml That's the root pom for the project. It defines all of the project's information such as plugin versions, dependency versions, metadata such as the SCM location, site, etc. Then, each module looks like this: https://github.com/io7m/jtensors/blob/develop/io7m-jtensors-core/pom.xml Note how this is a module of the root project and therefore it'd be redundant to have to re-specify all of the information such as the contributors, SCM location [0], etc. I only provide the information that's specific to that module such as the OSGi manifest, dependencies, etc. Using the scijava-maven-plugin RequireElements rule would seem to require me to specify all of this information again in each module. Is there a way to avoid this? M [0] Although I do actually have to re-specify the SCM location due to an utterly ancient bug/design flaw in the site plugin. pgp5ZQu43yUl2.pgp Description: OpenPGP digital signature
Re: Defining a property designed to be overridden?
On 2017-03-01T12:46:45 -0600 Curtis Ruedenwrote: > > In this way, I ensure that all projects which extend our parent add all the > useful metadata and properties needed for successful builditude. > > We released scijava-maven-plugin 1.0.0 on Maven Central; feel free to use > it if it helps you. Hah, well, I'm not sure you could have solved my problem any more precisely than that! Looks like exactly what I need. Thanks very much! M pgpLYGw3U7Uf4.pgp Description: OpenPGP digital signature
Re: Defining a property designed to be overridden?
Hi, > if a project forgets to override the property value, it won't get a > sensible "You didn't define this property" error because it's already > defined with an empty value in the parent. The way I solved this problem with my project builds is to create a custom requireElements enforcer rule, part of the scijava-maven-plugin [1], which lets you require the existence of particular elements in the POM itself—not an ancestor. Here is the configuration we use: https://github.com/scijava/pom-scijava-base/blob/pom- scijava-base-3.0.0/pom.xml#L610-L628 In this way, I ensure that all projects which extend our parent add all the useful metadata and properties needed for successful builditude. We released scijava-maven-plugin 1.0.0 on Maven Central; feel free to use it if it helps you. Regards, Curtis [1] https://github.com/scijava/scijava-maven-plugin/blob/ scijava-maven-plugin-1.0.0/src/main/java/org/scijava/maven/plugin/enforcer/ RequireElements.java#L55-L61 -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden On Wed, Mar 1, 2017 at 12:35 PM,wrote: > Hello. > > I'm looking to move to an organization-wide parent POM but am not sure > how to handle the following configuration case. > > The japicmp [0] plugin takes a configuration parameter that specifies > the previous version of a module against which the current version of > the module will be checked for API compatibility. I believe it can > sometimes infer the correct version by itself, but for the sake of > explanation here, let's assume that it can't and that I need to specify > it myself. This isn't a japicmp plugin issue, it's just a specific > example of a more general problem regarding the scope and definitions > of properties. > > I have a parent pom: > > https://github.com/io7m/maven-parent-properties-20170301/blo > b/develop/pom.xml > > ... which contains a definition like this: > > > ... > > > > > ... > > > > > > > com.github.siom79.japicmp > japicmp-maven-plugin > 0.9.4 > > > verify > > cmp > > > > > ${project.groupId} > ${project.artifactId} > ${io7m.previousVersion} > jar > > > > > > > > > > > > I then have an example project that inherits from the parent: > > https://github.com/io7m/maven-parent-properties-20170301/blo > b/develop/mod-a/pom.xml > > > > com.io7m.experimental > maven-parent-properties-20170301 > 1.0.0 > > > mod-a > > 0.9.0 > > > > > > com.github.siom79.japicmp > japicmp-maven-plugin > > > > > > Note that the child project must override the io7m.previousVersion > property from the parent. Is this the correct way to handle this? The > downside to this is that if a project forgets to override the property > value, it won't get a sensible "You didn't define this property" error > because it's already defined with an empty value in the parent. If I > don't define the property in the parent, many IDEs get upset at the > presence of an undefined property in the POM. > > Any advice would be appreciated. > > M > > [0] https://siom79.github.io/japicmp/MavenPlugin.html >
Defining a property designed to be overridden?
Hello. I'm looking to move to an organization-wide parent POM but am not sure how to handle the following configuration case. The japicmp [0] plugin takes a configuration parameter that specifies the previous version of a module against which the current version of the module will be checked for API compatibility. I believe it can sometimes infer the correct version by itself, but for the sake of explanation here, let's assume that it can't and that I need to specify it myself. This isn't a japicmp plugin issue, it's just a specific example of a more general problem regarding the scope and definitions of properties. I have a parent pom: https://github.com/io7m/maven-parent-properties-20170301/blob/develop/pom.xml ... which contains a definition like this: ... ... com.github.siom79.japicmp japicmp-maven-plugin 0.9.4 verify cmp ${project.groupId} ${project.artifactId} ${io7m.previousVersion} jar I then have an example project that inherits from the parent: https://github.com/io7m/maven-parent-properties-20170301/blob/develop/mod-a/pom.xml com.io7m.experimental maven-parent-properties-20170301 1.0.0 mod-a 0.9.0 com.github.siom79.japicmp japicmp-maven-plugin Note that the child project must override the io7m.previousVersion property from the parent. Is this the correct way to handle this? The downside to this is that if a project forgets to override the property value, it won't get a sensible "You didn't define this property" error because it's already defined with an empty value in the parent. If I don't define the property in the parent, many IDEs get upset at the presence of an undefined property in the POM. Any advice would be appreciated. M [0] https://siom79.github.io/japicmp/MavenPlugin.html pgpMdi3j13ccx.pgp Description: OpenPGP digital signature