You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2013/08/29 23:40:06 UTC
javadoc generating conventions
We have our multi-module builds set up so that
a) Javadocs are run just for the publicly-viewable apis
b) not run for individual sub-modules (e.g., not for uimaj-core).
Many releases ago, we did not even publish modules (other than maven plugins) to
maven-central - we just did binary convenience builds, and source releases,
published to the Apache Mirroring system.
Gradually, (as of uimaj release 2.3.1) we conformed more to the Maven normal
conventions, and we started making our individual projects available on maven
central, although without javadocs.
We could "turn on" javadoc creation for individual modules (probably only under
the -Papache-release profile, to make development builds go faster). I think
these would (by default - need to investigate) be "full" javadocs.
Richard suggests we do this, I'm +0 on this (not convinced that the Javadocs are
of actual interest to anyone, and they take up space -- but I guess that's
old-fashioned thinking :-)).
Other opinions?
-Marshall
Re: javadoc generating conventions
Posted by Marshall Schor <ms...@schor.com>.
I also can't log in - I think the login is for the admins only.
Re set-up: I found this:
https://issues.apache.org/jira/browse/INFRA-3486
You might try making a similar Jira, but I would also suggest saying something
about not finding any links to the correct process to get set up... That should
be fixed...
-Marshall
On 9/15/2013 12:31 PM, Richard Eckart de Castilho wrote:
> Nice, I cannot log in with my Apache LDAP account. What is necessary
> to set this up for uimaFIT?
>
> Cheers,
>
> -- Richard
>
> On 15.09.2013, at 13:38, Marshall Schor <ms...@schor.com> wrote:
>
>> You might be interested also in this report, or in setting up other "projects"
>> to get a report like this:
>>
>> https://analysis.apache.org/dashboard/index/50467
>>
>> Currently, only the UIMA SDK is set up, I think.
>>
>> -Marshall
>>
>> On 9/5/2013 4:56 PM, Richard Eckart de Castilho wrote:
>>> Yep, that someone was me. When the JavaDoc is built, we should
>>> see those warnings as well. From time to time I may tackle some
>>> of these warnings, but it can also be a general motivation to
>>> tackle some things here and there while working on related code.
>>>
>>> -- Richard
>>>
>>> On 05.09.2013, at 22:53, Marshall Schor <ms...@schor.com> wrote:
>>>
>>>> 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/
>>>> no, I hadn't looked. Looks like someone added additional code running checks
>>>> and other reports; maybe these can inspire some other volunteers to tackle and
>>>> fix these things...
>>>>
>>>> -Marshall
>>>>> 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 <ms...@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
>
Re: javadoc generating conventions
Posted by Richard Eckart de Castilho <re...@apache.org>.
Nice, I cannot log in with my Apache LDAP account. What is necessary
to set this up for uimaFIT?
Cheers,
-- Richard
On 15.09.2013, at 13:38, Marshall Schor <ms...@schor.com> wrote:
> You might be interested also in this report, or in setting up other "projects"
> to get a report like this:
>
> https://analysis.apache.org/dashboard/index/50467
>
> Currently, only the UIMA SDK is set up, I think.
>
> -Marshall
>
> On 9/5/2013 4:56 PM, Richard Eckart de Castilho wrote:
>> Yep, that someone was me. When the JavaDoc is built, we should
>> see those warnings as well. From time to time I may tackle some
>> of these warnings, but it can also be a general motivation to
>> tackle some things here and there while working on related code.
>>
>> -- Richard
>>
>> On 05.09.2013, at 22:53, Marshall Schor <ms...@schor.com> wrote:
>>
>>> 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/
>>> no, I hadn't looked. Looks like someone added additional code running checks
>>> and other reports; maybe these can inspire some other volunteers to tackle and
>>> fix these things...
>>>
>>> -Marshall
>>>> 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 <ms...@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
Re: javadoc generating conventions
Posted by Marshall Schor <ms...@schor.com>.
You might be interested also in this report, or in setting up other "projects"
to get a report like this:
https://analysis.apache.org/dashboard/index/50467
Currently, only the UIMA SDK is set up, I think.
-Marshall
On 9/5/2013 4:56 PM, Richard Eckart de Castilho wrote:
> Yep, that someone was me. When the JavaDoc is built, we should
> see those warnings as well. From time to time I may tackle some
> of these warnings, but it can also be a general motivation to
> tackle some things here and there while working on related code.
>
> -- Richard
>
> On 05.09.2013, at 22:53, Marshall Schor <ms...@schor.com> wrote:
>
>> 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/
>> no, I hadn't looked. Looks like someone added additional code running checks
>> and other reports; maybe these can inspire some other volunteers to tackle and
>> fix these things...
>>
>> -Marshall
>>> 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 <ms...@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
>
Re: javadoc generating conventions
Posted by Richard Eckart de Castilho <re...@apache.org>.
Yep, that someone was me. When the JavaDoc is built, we should
see those warnings as well. From time to time I may tackle some
of these warnings, but it can also be a general motivation to
tackle some things here and there while working on related code.
-- Richard
On 05.09.2013, at 22:53, Marshall Schor <ms...@schor.com> wrote:
> 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/
> no, I hadn't looked. Looks like someone added additional code running checks
> and other reports; maybe these can inspire some other volunteers to tackle and
> fix these things...
>
> -Marshall
>> 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 <ms...@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
Re: javadoc generating conventions
Posted by Marshall Schor <ms...@schor.com>.
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/
no, I hadn't looked. Looks like someone added additional code running checks
and other reports; maybe these can inspire some other volunteers to tackle and
fix these things...
-Marshall
> 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 <ms...@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
>
Re: javadoc generating conventions
Posted by Marshall Schor <ms...@schor.com>.
On 9/5/2013 6:37 PM, Richard Eckart de Castilho wrote:
> 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.
I think there's actually a reason - an "intention" about this in the Maven design.
One of the things that drove the creation of Maven was the very wide variety and
complexity of Ant script based builds. In reaction to the difficulties that
arose in long-term maintaining of these, Maven is trying to create manageable
builds around a few principles. I think these are basically 2 ideas:
1) convention over configuration
2) making bigger reusable units (maven plugins) and making it "harder" to stray
off into programming complex / hard-to-maintain etc. build systems.
For those more complex things, they want you to think hard about what it is
you're doing and then to write down the complex stuff using a programming
language (Java) and package it up into a reusable component (a maven plugin).
They really don't want to support more complex logic in their builds - its
complicated enough as it is :-).
-Marshall
>
> -- Richard
>
> On 06.09.2013, at 00:05, Marshall Schor <ms...@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 <ms...@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 <ms...@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 <ms...@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
>
Re: javadoc generating conventions
Posted by Richard Eckart de Castilho <re...@apache.org>.
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 <ms...@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 <ms...@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 <ms...@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 <ms...@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
>>
>
Re: javadoc generating conventions
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@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 <ms...@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 <ms...@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
>
Re: javadoc generating conventions
Posted by Richard Eckart de Castilho <re...@apache.org>.
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).
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 <ms...@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 <ms...@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 <ms...@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
>
Re: javadoc generating conventions
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@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 <ms...@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
Re: javadoc generating conventions
Posted by Richard Eckart de Castilho <re...@apache.org>.
Wouldn't we have to duplicate significant parts of the configurations?
-- Richard
On 05.09.2013, at 22:50, Marshall Schor <ms...@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 <ms...@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
Re: javadoc generating conventions
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@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
>
Re: javadoc generating conventions
Posted by Richard Eckart de Castilho <re...@apache.org>.
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 <ms...@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
Re: javadoc generating conventions
Posted by Marshall Schor <ms...@schor.com>.
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
On 9/5/2013 6:50 AM, Richard Eckart de Castilho wrote:
> So I suppose this means that we should create JavaDoc artifacts in the
> future:
>
> 2x +1 (Richard, Peter)
> 1x +0 (Marschall)
>
> No other votes ;)
>
> -- Richard
>
> On 30.08.2013, at 10:46, Peter Klügl <pk...@uni-wuerzburg.de> wrote:
>
>> On 29.08.2013 23:40, Marshall Schor wrote:
>>> We have our multi-module builds set up so that
>>>
>>> a) Javadocs are run just for the publicly-viewable apis
>>> b) not run for individual sub-modules (e.g., not for uimaj-core).
>>>
>>> Many releases ago, we did not even publish modules (other than maven plugins) to
>>> maven-central - we just did binary convenience builds, and source releases,
>>> published to the Apache Mirroring system.
>>>
>>> Gradually, (as of uimaj release 2.3.1) we conformed more to the Maven normal
>>> conventions, and we started making our individual projects available on maven
>>> central, although without javadocs.
>>>
>>> We could "turn on" javadoc creation for individual modules (probably only under
>>> the -Papache-release profile, to make development builds go faster). I think
>>> these would (by default - need to investigate) be "full" javadocs.
>>>
>>> Richard suggests we do this, I'm +0 on this (not convinced that the Javadocs are
>>> of actual interest to anyone, and they take up space -- but I guess that's
>>> old-fashioned thinking :-)).
>>>
>>> Other opinions?
>> +1
>>
>> (not that ruta has javadocs yet)
>>
>> Peter
>>
>>> -Marshall
Re: javadoc generating conventions
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
So I suppose this means that we should create JavaDoc artifacts in the
future:
2x +1 (Richard, Peter)
1x +0 (Marschall)
No other votes ;)
-- Richard
On 30.08.2013, at 10:46, Peter Klügl <pk...@uni-wuerzburg.de> wrote:
> On 29.08.2013 23:40, Marshall Schor wrote:
>> We have our multi-module builds set up so that
>>
>> a) Javadocs are run just for the publicly-viewable apis
>> b) not run for individual sub-modules (e.g., not for uimaj-core).
>>
>> Many releases ago, we did not even publish modules (other than maven plugins) to
>> maven-central - we just did binary convenience builds, and source releases,
>> published to the Apache Mirroring system.
>>
>> Gradually, (as of uimaj release 2.3.1) we conformed more to the Maven normal
>> conventions, and we started making our individual projects available on maven
>> central, although without javadocs.
>>
>> We could "turn on" javadoc creation for individual modules (probably only under
>> the -Papache-release profile, to make development builds go faster). I think
>> these would (by default - need to investigate) be "full" javadocs.
>>
>> Richard suggests we do this, I'm +0 on this (not convinced that the Javadocs are
>> of actual interest to anyone, and they take up space -- but I guess that's
>> old-fashioned thinking :-)).
>>
>> Other opinions?
>
> +1
>
> (not that ruta has javadocs yet)
>
> Peter
>
>>
>> -Marshall
Re: javadoc generating conventions
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 29.08.2013 23:40, Marshall Schor wrote:
> We have our multi-module builds set up so that
>
> a) Javadocs are run just for the publicly-viewable apis
> b) not run for individual sub-modules (e.g., not for uimaj-core).
>
> Many releases ago, we did not even publish modules (other than maven plugins) to
> maven-central - we just did binary convenience builds, and source releases,
> published to the Apache Mirroring system.
>
> Gradually, (as of uimaj release 2.3.1) we conformed more to the Maven normal
> conventions, and we started making our individual projects available on maven
> central, although without javadocs.
>
> We could "turn on" javadoc creation for individual modules (probably only under
> the -Papache-release profile, to make development builds go faster). I think
> these would (by default - need to investigate) be "full" javadocs.
>
> Richard suggests we do this, I'm +0 on this (not convinced that the Javadocs are
> of actual interest to anyone, and they take up space -- but I guess that's
> old-fashioned thinking :-)).
>
> Other opinions?
+1
(not that ruta has javadocs yet)
Peter
>
> -Marshall
>