On 31 juil. 2013, at 13:14, Hardy Ferentschik wrote:
>
> On 31 Jan 2013, at 10:41 AM, Gunnar Morling wrote:
>
>> Personally I prefer to include a class via fully qualified name if it is
>> only used in the javadocs.
>> I think the readability does not suffer too much and adding an actual impo
For the record, I side with Gunnar in relaxing this. I actually did not see
this thread and opened a issue for it this very morning.
In most situations we reference classes local to the module via {@link} and the
fully qualified class name is very annoying and very long.
On 31 juil. 2013, at 09
See inline...
On 07/31/2013 06:08 AM, Sanne Grinovero wrote:
> # Hibernate:
>
> Probably the best finding is the 'Shared non-thread-safe content'
> finding in the class 'EntityManagerFactoryRegistry'. In general, the
> inconsistent and mixed synchronisation findings are not very good, but
> the (
I can look after I get done mucking around with the JPA TCK...
On 07/31/2013 06:08 AM, Sanne Grinovero wrote:
> Hi all,
> the ThreadSafe team (http://contemplateltd.com) kindly offered a trial
> license to inspect Hibernate and Infinispan projects for code
> correctness; you can think of this as t
> It's a tradeoff, it's not the end of the world if this module doesn't
> compile for day.
> On the other hand I run the build dozens of times a day, quite happy
> it takes just 2 minutes, which is not possible with the performance
> tests.
I think we have to differentiate here. I am not saying t
On 31 July 2013 13:04, Gunnar Morling wrote:
> 2013/7/31 Hardy Ferentschik
>>
>>
>> On 31 Jan 2013, at 1:38 PM, Sanne Grinovero wrote:
>>
>> > Hi Hardy,
>> > sorry I screwed up both during review and setting up ci.hibernate.org
>> > : the code in Maven module _hibernate-search-performance_ isn't
2013/7/31 Hardy Ferentschik
>
> On 31 Jan 2013, at 1:38 PM, Sanne Grinovero wrote:
>
> > Hi Hardy,
> > sorry I screwed up both during review and setting up ci.hibernate.org
> > : the code in Maven module _hibernate-search-performance_ isn't
> > compiling anymore; could you extend your refactorin
2013/7/31 Sanne Grinovero
> On 31 July 2013 09:41, Gunnar Morling wrote:
> > 2013/7/31 Hardy Ferentschik
> >
> >> Hi,
> >>
> >> Personally I prefer to include a class via fully qualified name if it is
> >> only used in the javadocs.
> >> I think the readability does not suffer too much and addi
On 31 Jan 2013, at 1:38 PM, Sanne Grinovero wrote:
> Hi Hardy,
> sorry I screwed up both during review and setting up ci.hibernate.org
> : the code in Maven module _hibernate-search-performance_ isn't
> compiling anymore; could you extend your refactoring to this module
> please?
:-( I can have
Hi Hardy,
sorry I screwed up both during review and setting up ci.hibernate.org
: the code in Maven module _hibernate-search-performance_ isn't
compiling anymore; could you extend your refactoring to this module
please?
This slipped in as the profile is disabled by default; I'm fixing the
pull req
On 31 Jan 2013, at 10:41 AM, Gunnar Morling wrote:
> Personally I prefer to include a class via fully qualified name if it is only
> used in the javadocs.
> I think the readability does not suffer too much and adding an actual import
> has actually
> runtime consequences. We already had cases
Hi all,
the ThreadSafe team (http://contemplateltd.com) kindly offered a trial
license to inspect Hibernate and Infinispan projects for code
correctness; you can think of this as the "Findbugs for concurrent
code". The idea is to mutually benefit from it: we get to use the
tool, but we should also
On 31 July 2013 09:41, Gunnar Morling wrote:
> 2013/7/31 Hardy Ferentschik
>
>> Hi,
>>
>> Personally I prefer to include a class via fully qualified name if it is
>> only used in the javadocs.
>> I think the readability does not suffer too much and adding an actual
>> import has actually
>> runti
2013/7/31 Hardy Ferentschik
> Hi,
>
> Personally I prefer to include a class via fully qualified name if it is
> only used in the javadocs.
> I think the readability does not suffer too much and adding an actual
> import has actually
> runtime consequences. We already had cases where a javadoc im
I had a very minor preference for declaring the import over writing
verbose javadocs, but Hardy's point on decoupling is very interesting.
+1 to keep the error
On 31 July 2013 09:08, Hardy Ferentschik wrote:
> Hi,
>
> Personally I prefer to include a class via fully qualified name if it is only
Hi,
Personally I prefer to include a class via fully qualified name if it is only
used in the javadocs.
I think the readability does not suffer too much and adding an actual import
has actually
runtime consequences. We already had cases where a javadoc import caused a hard
link
between code w
Hi,
Currently CheckStyle raises an error due to an "unused import" if a class
imports types which are only referenced in JavaDoc comments. This issue
occurs for instance when referring to a super type in the comments while
only sub-types are used in the actual code:
/**
* This factory cr
17 matches
Mail list logo
