7:04 a.m.
Personally, I am not a big fan of changing build structure for the purpose
of an
IDE. generated-src belong imo into target.
That said, I know the troubles of having to manually adjust the Idea
configuration
after importing. If it bothers you so much or if you had several reports
of people
having problems setting up the project in the IDE, I's say go for it.
Yes, this is completely a pragmatic consideration. I set the build up with
generated-src under target because that is what I believe is proper in the
idyllic sense. But at some point I'd like to have an import that
JustWorks(tm).
> To be honest I think I'd alter jpa-metamodel-gen to not be
AP-based as
the
> best-case scenario.
Not sure what you mean? Are you referring to the actual annotation
processor module
or do you mean that you want to statically check in the generated meta
model classes
needed for our tests in the hibernate-core/hibernate-entitymanager module?
I assume
the latter. Again, not a big fan.
No, I actually mean the former. Probably as an alternative to the AP-based
generation, I think a non-AP solution would be good. After having talked
to David a few times about this, I believe annotation processing is not the
proper way to be generating these classes. My new belief is that
annotation processors that generate code that is then needed to compile is
bad mojo.
> It seems to me the only real option currently is to expect a full compile
> prior to import.
Right. Something I would recommend anyways.
Dunno here. Often my initial touch point with a project is to check out
the code and import it into the IDE. And I think that I am not unusual in
that sense, so I think there is a ton of value in that working smoothly.
Speaking of the hibernate-testing circularity, I do still want to get
rid
> of that. Currently I have been waiting on Gradle adding support for
> publishing multiple artifacts from a project (module).
That would be nice. Is there an issue for that? Did they agree on
implementing
it?
They said it was something they wanted to do. I'll follow up to see if it
was ever done.
7:26 a.m.
New subject: ORM build - IDE imports
Hi,
> > To be honest I think I'd alter jpa-metamodel-gen to not
be AP-based as
> the
> > best-case scenario.
>
> Not sure what you mean? Are you referring to the actual annotation
> processor module
> or do you mean that you want to statically check in the generated meta
> model classes
> needed for our tests in the hibernate-core/hibernate-entitymanager module?
> I assume
> the latter. Again, not a big fan.
>
No, I actually mean the former. Probably as an alternative to the AP-based
generation, I think a non-AP solution would be good
Interesting. For me the metamodel generation is a classic example for using
an annotation processor.
After having talked
to David a few times about this, I believe annotation processing is not the
proper way to be generating these classes
What would be the right way then in your opinion?
annotation processors that generate code that is then needed to
compile
Not sure. IMO the annotation processor is designed for exactly that. In fact if you
run the processor as part of the main compilation it does generation and compilation
in the same build phase. I don't see the bad mojo here.
> > It seems to me the only real option currently is to expect
a full compile
> > prior to import.
>
> Right. Something I would recommend anyways.
Dunno here. Often my initial touch point with a project is to check out
the code and import it into the IDE. And I think that I am not unusual in
that sense, so I think there is a ton of value in that working smoothly.
Sure, there is value in making it work smoothly. However, I prefer to start the
command line build first after checking out the code.
> That would be nice. Is there an issue for that? Did they agree
on
> implementing
> it?
>
They said it was something they wanted to do. I'll follow up to see if it
was ever done.
Cool
--Hardy
8:48 a.m.
New subject: ORM build - IDE imports
On Mon, Nov 10, 2014 at 7:26 AM, Hardy Ferentschik <hardy(a)hibernate.org>
wrote:
Hi,
> > > To be honest I think I'd alter jpa-metamodel-gen to not be AP-based
as
> > the
> > > best-case scenario.
> >
> > Not sure what you mean? Are you referring to the actual annotation
> > processor module
> > or do you mean that you want to statically check in the generated meta
> > model classes
> > needed for our tests in the hibernate-core/hibernate-entitymanager
module?
> > I assume
> > the latter. Again, not a big fan.
> >
>
> No, I actually mean the former. Probably as an alternative to the
AP-based
> generation, I think a non-AP solution would be good
Interesting. For me the metamodel generation is a classic example for using
an annotation processor.
I think that's true *if* the compilation unit producing the metamodel is
not also the one consuming it. For example a CRM project that produces and
bundles a JPA static metamodel of its domain model for developer use.
However, in cases where we try to both produce and consume the static
metamodel from the same compilation unit as we do in our usages. I think
about the whole point of AP, and as a user especially this static
metamodel. So I am writing code in which I am relying on this static
metamodel for type-safety, but I cannot even do that as the static
metamodel types dont even exist. Until I introduce some unnatural (imo)
step into the development process: develop, then compile so that I can
develop some more.
> After having talked
> to David a few times about this, I believe annotation processing is not
the
> proper way to be generating these classes
What would be the right way then in your opinion?
Well again I am pointing out the appropriateness of each. I think the AP
approach makes sense in certain cases. Just that our case within the
Hibernate build is not one of these. I think a tool leveraging source code
reading/analysis
> annotation processors that generate code that is then needed to compile
Not sure. IMO the annotation processor is designed for exactly that. In
fact if you
run the processor as part of the main compilation it does generation and
compilation
in the same build phase. I don't see the bad mojo here.
I consider it bad mojo because I load it up into the IDE and see red all
over the place. Yes I realize we have the same with Antlr and/or JAXB.
But I can completely rationalize running a source code generation *tool*
here.
I have a hard time making that rationalization for running the compiler in
order to see if my code will compile due to sources that are not there :)
> > > It seems to me the only real option currently is to
expect a full
compile
> > > prior to import.
> >
> > Right. Something I would recommend anyways.
I fully understand about needing/recommending some task prior to
importing. Specifically a source-generation task. I just don't think I am
alone in not immediately assuming/grokking a full compilation as the
source-generation task.
>
> Dunno here. Often my initial touch point with a project is to check out
> the code and import it into the IDE. And I think that I am not unusual
in
> that sense, so I think there is a ton of value in that working smoothly.
Sure, there is value in making it work smoothly. However, I prefer to
start the
command line build first after checking out the code.
I am not so sure that is the norm. For sure it is not generally what I do
at least. Projects tend to have such widely differing build assumptions
and requirements. When you first check it out, how do you know what
command line to do?
1:11 p.m.
New subject: ORM build - IDE imports
I just tried to import it in Eclipse.
Compiling it once from the command line upfront helped to reduce the
errors.. but I still have 10, and while I suspect one of them relates
to a bug in Eclipse's not-so-smart handling of generics, the others to
me look like it shouldn't compile so I'm going to need some
hand-holding on each of them.
Some examples:
EnhancerTask class not found: seems to be a groovy class. Do I need to
setup the project as Groovy, or get some Groovy SDK installed as well?
package-info.java sources in the jpamodelgen module seem to be in the
wrong package - or they are missing the package declaration. They also
have the wrong license header (JBoss instead of Hibernate, Apache
instead of LGPL).
Code snippet "CoreMatchers.<Object>notNullValue()" doesn't compile as
the method is not generic. Apparently IDEA and javac consider this
acceptable, but Eclipse won't. May I remove the generics usage?
I've sent a PR proposal here which includes a second problem with
generics: https://github.com/hibernate/hibernate-orm/pull/843
Sanne
On 10 November 2014 14:48, Steve Ebersole <steve(a)hibernate.org> wrote:
On Mon, Nov 10, 2014 at 7:26 AM, Hardy Ferentschik
<hardy(a)hibernate.org>
wrote:
> Hi,
>
> > > > To be honest I think I'd alter jpa-metamodel-gen to not be
AP-based
> as
> > > the
> > > > best-case scenario.
> > >
> > > Not sure what you mean? Are you referring to the actual annotation
> > > processor module
> > > or do you mean that you want to statically check in the generated meta
> > > model classes
> > > needed for our tests in the hibernate-core/hibernate-entitymanager
> module?
> > > I assume
> > > the latter. Again, not a big fan.
> > >
> >
> > No, I actually mean the former. Probably as an alternative to the
> AP-based
> > generation, I think a non-AP solution would be good
>
> Interesting. For me the metamodel generation is a classic example for using
> an annotation processor.
>
I think that's true *if* the compilation unit producing the metamodel is
not also the one consuming it. For example a CRM project that produces and
bundles a JPA static metamodel of its domain model for developer use.
However, in cases where we try to both produce and consume the static
metamodel from the same compilation unit as we do in our usages. I think
about the whole point of AP, and as a user especially this static
metamodel. So I am writing code in which I am relying on this static
metamodel for type-safety, but I cannot even do that as the static
metamodel types dont even exist. Until I introduce some unnatural (imo)
step into the development process: develop, then compile so that I can
develop some more.
> > After having talked
> > to David a few times about this, I believe annotation processing is not
> the
> > proper way to be generating these classes
>
> What would be the right way then in your opinion?
>
Well again I am pointing out the appropriateness of each. I think the AP
approach makes sense in certain cases. Just that our case within the
Hibernate build is not one of these. I think a tool leveraging source code
reading/analysis
>
> > annotation processors that generate code that is then needed to compile
>
> Not sure. IMO the annotation processor is designed for exactly that. In
> fact if you
> run the processor as part of the main compilation it does generation and
> compilation
> in the same build phase. I don't see the bad mojo here.
>
I consider it bad mojo because I load it up into the IDE and see red all
over the place. Yes I realize we have the same with Antlr and/or JAXB.
But I can completely rationalize running a source code generation *tool*
here.
I have a hard time making that rationalization for running the compiler in
order to see if my code will compile due to sources that are not there :)
> > > > It seems to me the only real option currently is to expect a full
> compile
> > > > prior to import.
> > >
> > > Right. Something I would recommend anyways.
>
I fully understand about needing/recommending some task prior to
importing. Specifically a source-generation task. I just don't think I am
alone in not immediately assuming/grokking a full compilation as the
source-generation task.
> >
> > Dunno here. Often my initial touch point with a project is to check out
> > the code and import it into the IDE. And I think that I am not unusual
> in
> > that sense, so I think there is a ton of value in that working smoothly.
>
> Sure, there is value in making it work smoothly. However, I prefer to
> start the
> command line build first after checking out the code.
>
I am not so sure that is the norm. For sure it is not generally what I do
at least. Projects tend to have such widely differing build assumptions
and requirements. When you first check it out, how do you know what
command line to do?
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:37 p.m.
New subject: ORM build - IDE imports
On Mon, Nov 17, 2014 at 1:11 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
I just tried to import it in Eclipse.
Compiling it once from the command line upfront helped to reduce the
errors.. but I still have 10, and while I suspect one of them relates
to a bug in Eclipse's not-so-smart handling of generics, the others to
me look like it shouldn't compile so I'm going to need some
hand-holding on each of them.
Some examples:
EnhancerTask class not found: seems to be a groovy class. Do I need to
setup the project as Groovy, or get some Groovy SDK installed as well?
Sorry, I do not know how Eclipse works. In IntelliJ there is nothing extra
to do for Groovy sources. As long as the directory is set as a "source
root" it'll work
package-info.java sources in the jpamodelgen module seem to be in the
wrong package - or they are missing the package declaration. They also
have the wrong license header (JBoss instead of Hibernate, Apache
instead of LGPL).
I see package-info.java files that actually have no package statement. Is
that what you mean?
Code snippet "CoreMatchers.<Object>notNullValue()" doesn't compile
as
the method is not generic. Apparently IDEA and javac consider this
acceptable, but Eclipse won't. May I remove the generics usage?
Where do you see this?
6:27 p.m.
New subject: ORM build - IDE imports
On 17 November 2014 21:37, Steve Ebersole <steve(a)hibernate.org> wrote:
On Mon, Nov 17, 2014 at 1:11 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
>
> I just tried to import it in Eclipse.
> Compiling it once from the command line upfront helped to reduce the
> errors.. but I still have 10, and while I suspect one of them relates
> to a bug in Eclipse's not-so-smart handling of generics, the others to
> me look like it shouldn't compile so I'm going to need some
> hand-holding on each of them.
>
> Some examples:
>
> EnhancerTask class not found: seems to be a groovy class. Do I need to
> setup the project as Groovy, or get some Groovy SDK installed as well?
Sorry, I do not know how Eclipse works. In IntelliJ there is nothing extra
to do for Groovy sources. As long as the directory is set as a "source
root" it'll work
It's not a priority as one can simply close that module and have it
built only on command line. This one is the easy to work around, I
only mentioned it as all the small things add up.
> package-info.java sources in the jpamodelgen module seem to be in
the
> wrong package - or they are missing the package declaration. They also
> have the wrong license header (JBoss instead of Hibernate, Apache
> instead of LGPL).
I see package-info.java files that actually have no package statement. Is
that what you mean?
Yes. Eclipse will mark the whole module as "can't compile", and
consequentially stops compiling anything.
> Code snippet
"CoreMatchers.<Object>notNullValue()" doesn't compile as
> the method is not generic. Apparently IDEA and javac consider this
> acceptable, but Eclipse won't. May I remove the generics usage?
Where do you see this?
https://github.com/Sanne/hibernate-orm/commit/9d38cff25aa035ef91c09651b07...
If you agree with that PR #843 is ok I'll create a JIRA for it?
Sanne
3692
days inactive
3700
days old
5 comments
3 participants
participants (3)
-
Hardy Ferentschik -
Sanne Grinovero -
Steve Ebersole