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 > > > > >
