Re: [hibernate-dev] Annotation Processors
I decided to hold off on this for now until GRADLE-2966[1] is resolved,
which would allow us to fold hibernate-testing into hibernate-core from
a source/project perspective but still allow us to publish
hibernate-testing as a artifact.
So I am also working on reverting the change to use -proc:both with a
single compile phase. However, what we will end up with is still a
single -proc:only phase no matter how many processors are run. They
will output to a unified directory
(${buildDir}/generated-src/apt/${sourceSet.name}) and will still give
us a single command up from to generateSources.
[1] http://issues.gradle.org/browse/GRADLE-2966
On Fri 29 Nov 2013 04:12:18 AM CST, Gunnar Morling wrote:
> We've removed the dependency to hibernate-testing from OGM now as it
> indeed wasn't actually used.
>
> --Gunnar
>
>
>
> 2013/11/25 Steve Ebersole >
>
> If I were to collapse it into hibernate-core... To use Maven
> terms, I can expose it as a hibernate-core artifact with a
> different classifier. But I would no longer be able to expose it
> using the hibernate-testing artifact id.
>
> This works fine either way within the hibernate-orm project. In
> fact we already have a very similar usage to this in hibernate-orm
> between envers and hem. If I publish the jar, others can access
> it as well using that published classifier.
>
>
>
> On Mon 25 Nov 2013 08:42:49 AM CST, Gunnar Morling wrote:
>
> Hi,
>
> Hibernate OGM is using hibernate-testing, but I'm not totally
> sure why.
>
> When I remove the dependency, the build still passes; Maybe it was
> used in the past. But also if we started to use stuff from
> hibernate-testing one day, a merge with hibernate-core
> wouldn't be a
> problem, provided you publish a test JAR (speaking in Maven
> terms).
>
> --Gunnar
>
>
>
> 2013/11/25 Brett Meyer >>
>
>
> IMO, there shouldn't be anything preventing us from pulling
> hibernate-testing into hibernate-core. Are there any external
> modules/projects that use testing w/o core? AFAIK, no, but
> correct me if I'm overlooking something.
>
> Brett Meyer
> Software Engineer
> Red Hat, Hibernate ORM
>
> - Original Message -
> From: "Steve Ebersole"
> >>
> To: "hibernate-dev"
> >>
> Sent: Friday, November 22, 2013 5:05:23 PM
> Subject: [hibernate-dev] Annotation Processors
>
> I started today on removing the separate calls to javac to
> execute
> Annotation Processors in the Hibernate ORM build. From
> Gradle it is
> working fine. However when I try to enable Annotation
> Processing in
> IntelliJ, it complains about the "module cycle" between
> hibernate-core
> and hibernate-testing.
>
> I'd really like to get a gauge on how many people really use
> hibernate-testing.
>
>
> _
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
>
> >
>
> https://lists.jboss.org/__mailman/listinfo/hibernate-dev
>
> _
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
>
> >
> https://lists.jboss.org/__mailman/listinfo/hibernate-dev
>
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Annotation Processors
On 2 Jan 2013, at 16:07, Steve Ebersole wrote:
> So I am also working on reverting the change to use -proc:both with a
> single compile phase. However, what we will end up with is still a
> single -proc:only phase no matter how many processors are run. They
> will output to a unified directory
+1 I have always said, that at least the processors should run in a dedicated
phase.
Happy to let them all run at the same time.
Funny enough there are people there seems to be people who claim that this is
not a
valid setup ;-)
> (${buildDir}/generated-src/apt/${sourceSet.name}) and will still give
> us a single command up from to generateSources.
sounds good
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Annotation Processors
Well technically it is not valid according to the javac spec, which was
David's point (which I assume who you are referring to). And in fact
we get a slew of errors from running `javac -proc:only`. We just
happen to eat/ignore them.
For example, take hibernate-core as it is the more "complex". There we
generate:
1) Antlr sources - non apt
2) Jaxb sources - non apt
3) JBoss Logging - apt
By the time we get to `javac -proc:only` for #3 javac errors out
validly in cases were the source being processed references either the
Antlr or the Jaxb generated sources. It just happens to work here
because JBoss Logging is never needing to process any of the sources
that javac throws out (prior to even calling the AP).
Take hibernate-envers as another example. There we generate:
1) JBoss Logging - apt
2) JPA metamodel generator - apt
Again this "works" because we happen to ignore the errors from javac.
But imagine that hibernate-envers instead did:
1) Jaxb - non apt
2) JBoss Logging - apt
3) JPA metamodel generator - apt
and further say that one or more of the sources that JPA metamodel
generator needs to process reference classes that come from sources
generated by Jaxb. What would happen is that javac would immediately
log that error and stop processing that source file before the JPA
metamodel generator had a chance to see it. This is where what we do
breaks down.
In general we are just lucky that it works for us ;)
On Mon 02 Dec 2013 10:46:20 AM CST, Hardy Ferentschik wrote:
>
> On 2 Jan 2013, at 16:07, Steve Ebersole wrote:
>
>> So I am also working on reverting the change to use -proc:both with a
>> single compile phase. However, what we will end up with is still a
>> single -proc:only phase no matter how many processors are run. They
>> will output to a unified directory
>
> +1 I have always said, that at least the processors should run in a dedicated
> phase.
> Happy to let them all run at the same time.
>
> Funny enough there are people there seems to be people who claim that this is
> not a
> valid setup ;-)
>
>> (${buildDir}/generated-src/apt/${sourceSet.name}) and will still give
>> us a single command up from to generateSources.
>
> sounds good
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
