Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

HV-574/HV-575: Avoiding NPEs when applying the AP to projects without HV/BV on the classpath #117

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
2 participants
Owner

gunnarmorling commented Apr 13, 2012

The change also contains an update of the documentation with respect to the JARs required on the processor path.

I tried to include the hibernate-validator testing jar. Then we could for example use @testforissue

    <dependency>
        <groupId>org.hibernate</groupId>
        <artifactId>hibernate-validator</artifactId>
        <classifier>testing</classifier>
        <scope>test</scope>
    </dependency>

It works fine from the command line, but Idea had problems wit the classifier (http://youtrack.jetbrains.com/issue/IDEA-54530) . You basically have to manually add the jar from your local repo. This makes the whole probably not worth the effort.

Owner

gunnarmorling replied Apr 14, 2012

Last time I tried it, the test classifier gave me some trouble in Eclipse as well. So I'd prefer to avoid it for now. We might duplicate the annotation to the AP project for the time being.

Out of interest, why here 1.6 target?

By the way, did you see the comments on https://hibernate.onjira.com/browse/HV-569. Because JBoss Logging is compiled w/ 1.6 as target we have indeed problems. I really would like them to cut another release with 1.5 target. I don't see what the runtime logging lib need to have 1.6 as target :-(

Owner

gunnarmorling replied Apr 14, 2012

Out of interest, why here 1.6 target?

When importing the project into Eclipse, based on this setting always a 1.5 execution environment was assigned. This resulted in a lot of warnings due to types from JDK 1.6 being accessed. Strictly speaking, language level 1.5 would suffice for the AP, but it's based on 1.6 APIs of course.

By the way, did you see the comments on https://hibernate.onjira.com/browse/HV-569. [...] I really would like them to cut another release with 1.5 target.

Yepp, I've seen the comments, that's not so good. Do you think there will be another release of the logging tools in the near future? Too sad that there is no real web page for the logging project stating things like this :-(

Yepp, I've seen the comments, that's not so good. Do you think there will be another release of the logging tools in the near future?

I was hoping so, but after the last comment on the LOGTOOL issue I am not so sure

Too sad that there is no real web page for the logging project stating things like this :-(

indeed

Owner

gunnarmorling replied Apr 16, 2012

funny through how many hoops you have to jumps sometimes to test annotations processors :-) Especially in maven

Owner

gunnarmorling replied Apr 14, 2012

Too right :-)

In particular I was rather sure that setting the class path for compilation tasks using "-classpath" would work, but for some reason always the complete class path of the "hosting" project was used. Previously I wasn't aware of StandardJavaFileManager#setLocation(), but that seems to do the trick now.

I think if you are using the fqcn within a {@link } you don't get the import statements, but you have the link.

Forget what I just said. I get it now, validator and co are test dependencies and javax.validation are not on the classpath for runtime classes

out of interest, which XMLEditor are you using? For some reason the editor started removing whitespaces before the closing '/>'. I have the same "problem" when I edit any existing documentation atm. I don't mind so much, but others seem to be concerned the bigger diff.

Owner

gunnarmorling replied Apr 14, 2012

I'm using XMLMind 5.1.1. We had the same issue for the BV spec; older versions of the editor used to add a space before "/>", while the newer doesn't. Are you using 5.1.1 as well? Maybe it's a good idea to load and store all documentation files once to have the new formatting applied consistently.

Actually I am using 5.2.0. It is not a big issue for me. I mainly wanted to know why it is happening.

Owner

hferentschik commented Apr 14, 2012

Rebased and applied the pull request. Needed to make a minor change in the docs, since it caused problems for the translations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment