hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Carey <sc...@richrelevance.com>
Subject Re: getting started building Mavenized hadoop common
Date Thu, 04 Aug 2011 18:14:13 GMT
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" <tucu@cloudera.com> 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
><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
>> >
>> >
>>


Mime
View raw message