I believe Eclipse will pick these up with the m2Eclipse plugin if you right click on the project and "Maven > Update Project Configuration".
For whatever reason, it does not add extra source directories that are generated by plugins when the project is imported. On 8/4/11 10:32 AM, "Alejandro Abdelnur" <[email protected]> wrote: >Are the concerns about generated code not addressed already with the >latest >trunk? > >The generated code is created under target/generated-sources/ and >target/generated-test-sources/ > >IntelliJ and Netbeans pick up those directories automatically at project >import time (if the existed - you run 'mvn test -DskipTests' before >importing) > >Eclipse seems to have a bug and does not add these directories >automatically >(you have to add them as source roots manually). > >Thanks. > >Alejandro > >On Thu, Aug 4, 2011 at 10:09 AM, Andrew Bayer ><[email protected]>wrote: > >> +1, for what it's worth - that seems like the right way to handle this >>sort >> of thing to me. >> >> A. >> >> On Thu, Aug 4, 2011 at 6:33 AM, Robert Evans <[email protected]> >>wrote: >> >> > Can we make it a separate maven project. Not a separate tar but >> something >> > closer to the hadoop-annotations. That way if nothing has changed or >>the >> > developer does not have the tools to rebuild protocol buffers then >>maven >> can >> > download the jar/source from the maven repo. If the developer does >> change >> > it then they can rebuild and install it as needed. >> > >> > --Bobby Evans >> > >> > On 8/4/11 6:38 AM, "Steve Loughran" <[email protected]> wrote: >> > >> > On 03/08/11 02:41, Ted Dunning wrote: >> > > (the following discusses religious practices ... please don't break >> into >> > > flames) >> > > >> > > In the past, the simplest approach I have seen for dealing with >>this is >> > to >> > > simply put the generated code under the normal source dir and check >>it >> > in. >> > > This is particularly handy with Thrift since it is common for >>users >> of >> > the >> > > code to not have a working version of the Thrift compiler. I then >>have >> > an >> > > optional profile that does the code generation. In my cases, I made >> that >> > > profile conditional on a thrift compiler being found, but there are >> other >> > > reasonable strategies. I did the code generation by generating >>into a >> > temp >> > > dir and then copying the code into the source tree so that if the >> > generation >> > > failed, no code was changed. >> > > >> > > The nice side effect is that IDE's see the generated code as first >> class >> > > code. >> > > >> > > Many consider various aspects of this style to be bad practice. >>Some >> > > condemn checking in generated code as akin to checking in jars. I >> kind >> > of >> > > agree, but lack of thrift or javacc is common enough that it really >>has >> > to >> > > be dealt with by checking these in somewhere. Only if your code >> > generator >> > > really is ubiquitous is it feasible not to check in generated code. >> > >> > The problem with this approach is that SVN will often say "it's >>changed" >> > when it hasn't. You can do some tricks with Ant using the <copy> >> > operation and only copy if they really are different, though once the >> > generator adds a timestamp to the header you are in trouble, and you >> > have to look at the diffs to see if anything really has changed. I've >> > had this problem in the past with Hibernate generated stuff. >> > >> > >> > > Others consider the commingling of generated an "real" code in the >>same >> > > directory tree to be a mortal sin. I agree, but in a lesser form. >>I >> > > strongly condemn the use of a single directory for generated and >> > > non-generated code, but if all directories avoid such miscegenation, >> then >> > I >> > > don't see this as much of a problem. Most people recognize that a >> > package >> > > with a name "generated" will contain generated code. >> > > >> > >> > I'd prefer to generate the stuff in the same tree, in a subdir, with >> > .svnignore set up to never commit the source. That way it's all in the >> > same tree, but you can't check it in. This keeps the source there even >> > when you rm -rf build, but keep it out of SCM >> > >> > >>
