As discussed a little in HHH-8140[1] and on the earlier Eclipse thread, I'd like to look at simplifying the build a bit around making IDE setup easier. One thing that came to mind was looking at source generation. Today we have source generation occur for: * Antlr * JAXB * JPA static metamodel gen * Logging The first 2 rely on specific tools while the other 2 are generated via AnnotationProcessors. For the first 2, there is really not much to discuss aside from possibly to consider adding those outputs to Git. I'd actually be open to considering that for JAXB.

But really it is the AnnotationProcessors I wanted to talk about. Currently we apply the AnnotationProcessors in separate javac task configurations. I cannot remember all the reasons we decided to do it this way originally. But I know that one was wanting to be able to keep the output of each (the generated sources) in dedicated directories[2].

But we could also just lump all the APT output into one single, separate directory (target/generated-src/apt/main, target/generated-src/apt/test, e.g.). What this would gain us is the ability for the IDE to run APT as part of normal javac. It would be one less thing to set up when setting up the IDE project.

On 17 Jan 2013, at 5:32 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > As discussed a little in HHH-8140[1] and on the earlier Eclipse thread, > I'd like to look at simplifying the build a bit around making IDE setup > easier. One thing that came to mind was looking at source generation. > Today we have source generation occur for: > * Antlr > * JAXB > * JPA static metamodel gen > * Logging > > The first 2 rely on specific tools while the other 2 are generated via > AnnotationProcessors. > > For the first 2, there is really not much to discuss aside from possibly > to consider adding those outputs to Git. I'd actually be open to > considering that for JAXB. Personally I would not check them in. In my world generated classes don't belong into the repository. > But really it is the AnnotationProcessors I wanted to talk about. > Currently we apply the AnnotationProcessors in separate javac task > configurations. I cannot remember all the reasons we decided to do it > this way originally. But I know that one was wanting to be able to keep > the output of each (the generated sources) in dedicated directories[2]. This reminds me of not so distant discussion on jboss-dev ;-) I still believe it is nice to have a different output directory for each annotation processor and I also like the idea of keeping things separate in the build. IMO it is completely valid to run the processors separately from the main javac call. I know this creates problems in the IDE setup, but the limiting factor in this case is the IDE. > But we could also just lump all the APT output into one single, separate > directory (target/generated-src/apt/main, target/generated-src/apt/test, > e.g.). What this would gain us is the ability for the IDE to run APT as > part of normal javac. It would be one less thing to set up when setting > up the IDE project. Since I drive the build most of the time from the command line I don't care that the IDE is not doing the APT processing. For me a nicely organised build outweighs simpler IDE setup. --Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 17 Jan 2013, at 6:30 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > AFAIK the reason we originally had a separate phase for annotation > processors was to workaround the following javac bug: > http://bugs.sun.com/view_bug.do?bug_id=6512707 From a Maven perspective (not an ORM issue longer) there is/was also the issue of configuring the annotation processors in the compiler plugin. There are several unresolved Jira issues for that, but according to David they are resolved, even though I cannot see any reference of that in the Maven issue tracker.

> On command line users.. I'd agree with Hardy that we likely all prefer > building from the command line rather than from the IDE, but I don't > expect that to be the majority of users. So what do you do when you are interested in some project and want to check it out? Get the sources and load it directly in your IDE. IMO that is stupid. I first build at least once from the command line and have a look at the generated directories. Does the build work? Can I make sense off things w/o knowing much about the code? Only then I would start using an IDE and I expect that a developer can set up his IDE of choice.

Just to chime in on the IDE use. While hibernate is on the significantly complex side of things for OSS projects go most projects I deal with that are using Maven or Gradle I do just checkout in my IDE and expect to work. For 99% of maven projects this is the case, I checkout/clone the project, import it as a maven project in Eclipse and I'm done. All code and resources required to build are correctly setup on the classpath and I'm good to go. For 99% of gradle project I do something similar but before the import I just run the gradle eclipse command on the CLI. Unless I'm going to be doing active development or patching on a project I don't care about a CLI build, I care about a functional IDE experience so I can run unit tests and debug code to verify some behavior/problem/bug. I don't have much to say specifically on the annotation processors stuff. Right now all the jasig projects use a combination of the maven-processor-plugin and the build-helper-maven-plugin to get the meta-model built and added to the classpath. Honestly I don't care how that happens as long as I can end up with the same final result of maven knowing about a generated-sources directory and code getting placed there during the generate-sources build phase. https://github.com/UW-Madison-DoIT/BlackboardVCPortlet/blob/uw-master/bla... -Eric On 04/17/2013 11:58 AM, Steve Ebersole wrote: > On Wed 17 Apr 2013 11:44:18 AM CDT, Hardy Ferentschik wrote: >> On 17 Jan 2013, at 6:30 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: >> >>> AFAIK the reason we originally had a separate phase for annotation >>> processors was to workaround the following javac bug: >>> http://bugs.sun.com/view_bug.do?bug_id=6512707 >> From a Maven perspective (not an ORM issue longer) there is/was also >> the issue of configuring the annotation processors in the compiler plugin. >> There are several unresolved Jira issues for that, but according to David >> they are resolved, even though I cannot see any reference of that in the >> Maven issue tracker. > Right, would not affect ORM anyway. > > >>> On command line users.. I'd agree with Hardy that we likely all prefer >>> building from the command line rather than from the IDE, but I don't >>> expect that to be the majority of users. >> So what do you do when you are interested in some project and want to check it out? >> Get the sources and load it directly in your IDE. IMO that is stupid. I first build at least >> once from the command line and have a look at the generated directories. Does the >> build work? Can I make sense off things w/o knowing much about the code? >> Only then I would start using an IDE and I expect that a developer can set up his >> IDE of choice. > So when someone does something different than you they are stupid... > nice :) > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

"Get the sources and load it directly in your IDE. IMO that is stupid." Honestly, that's always been the absolute *first* thing I do. I'd argue that most contributing developers are interested in the src, first and foremost. My intentions for working on the Eclipse generation was to make IDE setup as painless as possible. Is it important to have a well-developed build process? Of course. But it's also important to balance that with removing as many roadblocks as possible that might detract contributors. Brett Meyer Red Hat Software Engineer, Hibernate ----- Original Message ----- From: "Steve Ebersole" <steve(a)hibernate.org&gt; To: "Hardy Ferentschik" <hardy(a)hibernate.org&gt; Cc: "hibernate-dev" <hibernate-dev(a)lists.jboss.org&gt; Sent: Wednesday, April 17, 2013 12:58:19 PM Subject: Re: [hibernate-dev] Build and AnnotationProcessors On Wed 17 Apr 2013 11:44:18 AM CDT, Hardy Ferentschik wrote: > > On 17 Jan 2013, at 6:30 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > >> AFAIK the reason we originally had a separate phase for annotation >> processors was to workaround the following javac bug: >> http://bugs.sun.com/view_bug.do?bug_id=6512707 > > From a Maven perspective (not an ORM issue longer) there is/was also > the issue of configuring the annotation processors in the compiler plugin. > There are several unresolved Jira issues for that, but according to David > they are resolved, even though I cannot see any reference of that in the > Maven issue tracker. Right, would not affect ORM anyway. >> On command line users.. I'd agree with Hardy that we likely all prefer >> building from the command line rather than from the IDE, but I don't >> expect that to be the majority of users. > > So what do you do when you are interested in some project and want to check it out? > Get the sources and load it directly in your IDE. IMO that is stupid. I first build at least > once from the command line and have a look at the generated directories. Does the > build work? Can I make sense off things w/o knowing much about the code? > Only then I would start using an IDE and I expect that a developer can set up his > IDE of choice. So when someone does something different than you they are stupid... nice :) _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

"Get the sources and load it directly in your IDE. IMO that is stupid." Honestly, that's always been the absolute *first* thing I do. I'd argue that most contributing developers are interested in the src, first and foremost.

My intentions for working on the Eclipse generation was to make IDE setup as painless as possible. Is it important to have a well-developed build process? Of course. But it's also important to balance that with removing as many roadblocks as possible that might detract contributors.