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

Re: Defining a property designed to be overridden?

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

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

Re: Defining a property designed to be overridden?

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

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

Re: Defining a property designed to be overridden?

'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

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

Re: Defining a property designed to be overridden?

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

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

Re: Defining a property designed to be overridden?

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

Re: Defining a property designed to be overridden?

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. > > We released scijava-maven-plugin 1.0.0 on Maven Central; feel free to use >

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,