Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Flume >> mail # dev >> Re: issues compiling trunk on a new clone

Copy link to this message
Re: issues compiling trunk on a new clone
Also, if you really wanted the javadoc and not the javadoc jar then you can either unzip the javadoc jar or you can remove the plugin declaration from the build section and add


to the reporting section. That will successfully build the javadoc as part of the site so that may impact where the distribution has to copy the javadoc from.


On Jul 2, 2012, at 2:51 AM, Ralph Goers wrote:

> Mike, I'm obviously aware of the RTC policy. However, my impression of Hari's request was that It was a request to get the build working ASAP. If I was going to have to create a Jira and have it reviewed I wouldn't have bothered since I didn't know all the details of how it is being used. That is also why I referred to it as a temporary commit below,
> Ralph
> On Jul 1, 2012, at 11:16 PM, Mike Percy <[EMAIL PROTECTED]> wrote:
>> Hi Ralph,
>> Thanks for finding the issue! It seems that the "aggregate" goal is still
>> suffering from bug MJAVADOC-116 <
>> https://jira.codehaus.org/browse/MJAVADOC-116> whereas the aggregate-jar
>> functionality does not have the same problem. However, making that change
>> broke the docs and required an addition to dist.xml so as the 1.2.0 release
>> manager I've committed that change to trunk on top of your commit as well
>> as onto the 1.2.0 branch.
>> Side note, and no offense intended, I did not see a +1 for that commit? Per
>> Flume's RTC policy we must get a +1 on-list whenever we check into the
>> Flume codebase, except for special situations such as RMing.
>> Per your earlier question, the purpose of aggregating the javadocs is to
>> include the apidocs directory in the binary distribution, so that the
>> convenience artifact ships with up-to-date javadocs in a browsable format
>> inside the docs directory. The RST docs link to them from the index page.
>> Thanks and regards,
>> Mike
>> On Sat, Jun 30, 2012 at 6:53 PM, Ralph Goers <[EMAIL PROTECTED]>wrote:
>>> Ok - I've made the change. However, I believe Mike already cut a release
>>> branch so he will have to do something there as well.
>>> Ralph
>>> On Jun 30, 2012, at 6:50 PM, Ralph Goers wrote:
>>>> Yes, changing the goal to aggregate-jar fixed the issue for me. But it
>>> obviously generates a javadoc jar where the aggregate goal does not.  I'm
>>> not sure what the original intent here was/is so I can't say if that is the
>>> correct fix or if the javadoc plugin was really meant to be part of the
>>> site plugin.
>>>> I'll be happy to make a temporary commit to get it working.
>>>> Ralph
>>>> On Jun 30, 2012, at 5:19 PM, Hari Shreedharan wrote:
>>>>> Ralph,
>>>>> Will changing the goal to aggregate-jar fix the issue? I currently do
>>> not
>>>>> have access to the code or the machine on which I work, so I have not
>>> been
>>>>> able to try it out. If that works, lets do that, else disable the plugin
>>>>> till we can resolve this issue?
>>>>> Thanks
>>>>> Hari
>>>>> On Sat, Jun 30, 2012 at 12:51 AM, Ralph Goers <
>>> [EMAIL PROTECTED]>wrote:
>>>>>> Change the javadoc goal from aggregate to aggregate-jar.  aggregate
>>> would
>>>>>> normally be used in the reporting section when creating the web site.
>>> I am
>>>>>> assuming that a javadoc jar is what is desired. Otherwise I'm not sure
>>> what
>>>>>> the intent of the aggregate goal is there.
>>>>>> Ralph
>>>>>> On Jun 29, 2012, at 8:51 PM, Mike Percy wrote:
>>>>>>> I just did a pom.xml search-and-replace to change the version after
>>>>>>> branching for 1.2.0 and I ran into this error when attempting to
>>> build,
>>>>>> so
>>>>>>> I didn't check in the pom version changes. I will have to look at this
>>>>>> over
>>>>>>> the weekend. If anyone has enough Maven expertise to suggest a fix