Sigh. You are right. I wonder why Maven so effectively defies doing anything even remotely sensible or creative with profile activation.
- Profiles cannot activate other profiles by any command. - Profiles cannot declare properties that trigger other profiles. - Profiles *can* be activated by properties with certain values and by property name - If there are is a profile activated by prop + value and one activated by prop-only, the latter wins no matter what value the property has (or if any at all). So there is effectively no way to have one profile activated under multiple property- or profile- controlled conditions… argh. -- Richard On 06.09.2013, at 00:05, Marshall Schor <m...@schor.com> wrote: > On 9/5/2013 5:15 PM, Richard Eckart de Castilho wrote: >> It would be possible to activate profiles by properties instead of >> explicitly. >> >> E.g. we could build a "rat" profile which is activated by two properties >> "apache.release" and "jenkins.build". >> >> mvn -Dapache.release >> >> vs. >> >> mvn -Papache.release >> >> If multiple conditions are specified on a profile, it is activated if any of >> the >> conditions is true (OR). > I think there's a catch here. By "multiple conditions", maven means (I > believe) > 0 or 1 of the 4 kinds of conditions, and not 2 or more of the same kind (e.g. > 2 > "property" conditions). > > Have you tried this? > > Both the XSD and the Javadoc for the model api's seem to indicate that > multiples > of conditions are not supported. > > -Marshall > >> >> That way, we could bind profiles to multiple circumstances. Additional >> profiles >> could be set up for running code quality plugins (I currently invoke these >> goals explicitly in the Maven build) and they could also be bound to the >> "jenkins.build" property (mind there are some properties always set during >> jenkins builds, so we could just hijack one of these instead of inventing a >> new one). >> >> Finally, if any of the profiles had a serious problem, it should still be >> possible to explicitly disable them, e.g. "-P!findbugs" >> >> -- Richard >> >> On 05.09.2013, at 23:04, Marshall Schor <m...@schor.com> wrote: >> >>> On 9/5/2013 4:53 PM, Richard Eckart de Castilho wrote: >>>> Wouldn't we have to duplicate significant parts of the configurations? >>> I guess that would depend on what we wanted to include in the Jenkins build >>> that's not already there. I don't think there's too much worthwhile. The >>> only >>> thing I see of interest is the RAT check. Other things like the >>> source-releases >>> build don't seem useful to do (because that step is very unlikely to cause >>> any >>> errors). >>> >>> I think the only other thing done is the apidocs line-endings fixup (not >>> very >>> interesting). >>> >>> -Marshall >>>> -- Richard >>>> >>>> On 05.09.2013, at 22:50, Marshall Schor <m...@schor.com> wrote: >>>> >>>>> how about having a jenkins-build profile, set for jenkins builds? Then >>>>> we could >>>>> put anything we wanted into that. >>>>> >>>>> I think that might be more "direct" and maintainable than turning on >>>>> apache-release, and then somehow turning off some parts of that. >>>>> >>>>> -Marshall >>>>> On 9/5/2013 2:50 PM, Richard Eckart de Castilho wrote: >>>>>> Did you look at the Jenkins build of the SDK recently? ;) >>>>>> >>>>>> https://builds.apache.org/job/UIMA-SDK/ >>>>>> >>>>>> Btw. I'd like to turn on apache-release on the Jenkins build >>>>>> and just skip the gpg signing, so that we get immediate failures >>>>>> on missing license headers and the like. Any objections? >>>>>> >>>>>> -- Richard >>>>>> >>>>>> On 05.09.2013, at 20:20, Marshall Schor <m...@schor.com> wrote: >>>>>> >>>>>>> OK. I've updated the build process to produce javadocs (but only under >>>>>>> -Papache-release, to keep development builds going faster). >>>>>>> >>>>>>> Running this for the 1st time on uimaj-core produced >400 warnings... >>>>>>> (the >>>>>>> Javadocs on internals haven't been invested in ...) >>>>>>> >>>>>>> -Marshall >> >
