Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Hadoop >> mail # general >> getting started building Mavenized hadoop common


+
Alejandro Abdelnur 2011-08-02, 21:13
+
Jeffrey Naisbitt 2011-08-02, 21:55
+
Alejandro Abdelnur 2011-08-02, 22:21
+
Jeffrey Naisbitt 2011-08-02, 22:47
+
Tom White 2011-08-03, 00:44
+
Ted Dunning 2011-08-03, 01:41
+
Milind.Bhandarkar@... 2011-08-03, 22:33
+
Scott Carey 2011-08-04, 00:35
+
Steve Loughran 2011-08-04, 11:38
+
Robert Evans 2011-08-04, 13:33
+
Rottinghuis, Joep 2011-08-04, 13:58
Copy link to this message
-
Re: getting started building Mavenized hadoop common
That is a nice answer.

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
>
>
+
Andrew Bayer 2011-08-04, 17:09
+
Alejandro Abdelnur 2011-08-04, 17:32
+
Scott Carey 2011-08-04, 18:14
+
Eli Collins 2011-08-04, 20:38
+
Eli Collins 2011-08-04, 20:40
+
Rottinghuis, Joep 2011-08-05, 16:43
+
Alejandro Abdelnur 2011-08-05, 16:53
+
Scott Carey 2011-08-08, 21:59
+
Luke Lu 2011-08-03, 02:09
+
Alejandro Abdelnur 2011-08-03, 04:34