Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of tucu@cloudera.com designates
 209.85.161.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAPbPdOaxrk-85A951EUtM0URVegaMxu2guj4sT1vJyum=eE9Eg@mail.gmail.com>
References: <4E3A84BA.80904@apache.org> <CA6009CA.271AE%evans@yahoo-inc.com>
 <CAPbPdOaxrk-85A951EUtM0URVegaMxu2guj4sT1vJyum=eE9Eg@mail.gmail.com>
From: Alejandro Abdelnur <tucu@cloudera.com>
Date: Thu, 4 Aug 2011 10:32:59 -0700
Message-ID: 
 <CAJs-t7M=dpMjaVWFNCc7KDNnSaLW4SZar-qEYLJU8mvx9DtgwA@mail.gmail.com>
Subject: Re: getting started building Mavenized hadoop common
To: general@hadoop.apache.org
Content-Type: multipart/alternative; boundary=000325559b920a738f04a9b161ad

--000325559b920a738f04a9b161ad
Content-Type: text/plain; charset=ISO-8859-1

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 <andrew.bayer@gmail.com>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 <evans@yahoo-inc.com> 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" <stevel@apache.org> 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
> >
> >
>

--000325559b920a738f04a9b161ad--