You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mahout.apache.org by Benson Margulies <bi...@gmail.com> on 2009/12/19 03:09:32 UTC

An last-ditch argument against checking in generated sources...

Let me describe the scenario I start with, just in case by some chance
you all decide that it's not too bad.

There's a maven plugin that reads templates and writes sources.

We configure it to write them to target/generated-sources/...

The plugin automatically adds that directory to the compilation.

So, whenever you type maven, the sources are generated and compiled.
So you have the sources from typing maven, and you don't have to worry
about checking them in after changing a template, and you don't have
to worry about someone changing a generated source and not changing
the underlying template.

If this doesn't persuade, here's plan b.

the output of the generator goes into src/main/java, but the generator
is only put into operation with -Pregenerate, so that those
unconcerned with these templates don't see a lot of M's on these
files. You might say, 'what M's? the new version will be textually
identical, and svn is smarter than that.' If that's the consensus
view, I'll just run it that way.

Re: An last-ditch argument against checking in generated sources...

Posted by Benson Margulies <bi...@gmail.com>.
OK, that's one vote. Aside from the mistake you found, that's a good
reason to pull the patch back for a bit.

On Fri, Dec 18, 2009 at 9:38 PM, Ted Dunning <te...@gmail.com> wrote:
> The only situation that I know of where checking in the generated sources is
> a good thing is where not everybody has the capability to generate them.
>
> My best example is thrift.  Compiling and installing thrift can be a pain in
> the ** on some platforms because there are lots of package dependencies and
> some take a Looong time to compile (libboost for instance).  Checking in
> thrift generated sources is a nice thing because of this and it is easy to
> have a profile that can detect whether thrift is available.
>
> With velocity or similar java based generators, I would expect full
> integration with maven and transparent source generation.  In that case, my
> needle swings back to the "don't check in generated source" side of the
> dial.
>
> On Fri, Dec 18, 2009 at 6:09 PM, Benson Margulies <bi...@gmail.com>wrote:
>
>> Let me describe the scenario I start with, just in case by some chance
>> you all decide that it's not too bad.
>>
>> There's a maven plugin that reads templates and writes sources.
>>
>> We configure it to write them to target/generated-sources/...
>>
>> The plugin automatically adds that directory to the compilation.
>>
>> So, whenever you type maven, the sources are generated and compiled.
>> So you have the sources from typing maven, and you don't have to worry
>> about checking them in after changing a template, and you don't have
>> to worry about someone changing a generated source and not changing
>> the underlying template.
>>
>> If this doesn't persuade, here's plan b.
>>
>> the output of the generator goes into src/main/java, but the generator
>> is only put into operation with -Pregenerate, so that those
>> unconcerned with these templates don't see a lot of M's on these
>> files. You might say, 'what M's? the new version will be textually
>> identical, and svn is smarter than that.' If that's the consensus
>> view, I'll just run it that way.
>>
>
>
>
> --
> Ted Dunning, CTO
> DeepDyve
>

Re: An last-ditch argument against checking in generated sources...

Posted by Ted Dunning <te...@gmail.com>.
The only situation that I know of where checking in the generated sources is
a good thing is where not everybody has the capability to generate them.

My best example is thrift.  Compiling and installing thrift can be a pain in
the ** on some platforms because there are lots of package dependencies and
some take a Looong time to compile (libboost for instance).  Checking in
thrift generated sources is a nice thing because of this and it is easy to
have a profile that can detect whether thrift is available.

With velocity or similar java based generators, I would expect full
integration with maven and transparent source generation.  In that case, my
needle swings back to the "don't check in generated source" side of the
dial.

On Fri, Dec 18, 2009 at 6:09 PM, Benson Margulies <bi...@gmail.com>wrote:

> Let me describe the scenario I start with, just in case by some chance
> you all decide that it's not too bad.
>
> There's a maven plugin that reads templates and writes sources.
>
> We configure it to write them to target/generated-sources/...
>
> The plugin automatically adds that directory to the compilation.
>
> So, whenever you type maven, the sources are generated and compiled.
> So you have the sources from typing maven, and you don't have to worry
> about checking them in after changing a template, and you don't have
> to worry about someone changing a generated source and not changing
> the underlying template.
>
> If this doesn't persuade, here's plan b.
>
> the output of the generator goes into src/main/java, but the generator
> is only put into operation with -Pregenerate, so that those
> unconcerned with these templates don't see a lot of M's on these
> files. You might say, 'what M's? the new version will be textually
> identical, and svn is smarter than that.' If that's the consensus
> view, I'll just run it that way.
>



-- 
Ted Dunning, CTO
DeepDyve

Re: An last-ditch argument against checking in generated sources...

Posted by Benson Margulies <bi...@gmail.com>.
OK, patch take 2 coming up.

On Sat, Dec 19, 2009 at 6:21 AM, Grant Ingersoll <gs...@gmail.com> wrote:
>
> On Dec 18, 2009, at 11:22 PM, Drew Farris wrote:
>
>> +1 for not checking in generated sources. Maven is more than capable of
>> handling the process in a way that is transparent to the end user, and this
>> is the established convention for maven builds.
>
> Why don't we start with this and if it proves problematic, we can check in the gen. sources?  As long as Maven automates it, that should be fine.
>
>
>>
>> On Dec 18, 2009 9:10 PM, "Benson Margulies" <bi...@gmail.com> wrote:
>>
>> Let me describe the scenario I start with, just in case by some chance
>> you all decide that it's not too bad.
>>
>> There's a maven plugin that reads templates and writes sources.
>>
>> We configure it to write them to target/generated-sources/...
>>
>> The plugin automatically adds that directory to the compilation.
>>
>> So, whenever you type maven, the sources are generated and compiled.
>> So you have the sources from typing maven, and you don't have to worry
>> about checking them in after changing a template, and you don't have
>> to worry about someone changing a generated source and not changing
>> the underlying template.
>>
>> If this doesn't persuade, here's plan b.
>>
>> the output of the generator goes into src/main/java, but the generator
>> is only put into operation with -Pregenerate, so that those
>> unconcerned with these templates don't see a lot of M's on these
>> files. You might say, 'what M's? the new version will be textually
>> identical, and svn is smarter than that.' If that's the consensus
>> view, I'll just run it that way.
>
>

Re: An last-ditch argument against checking in generated sources...

Posted by Grant Ingersoll <gs...@gmail.com>.
On Dec 18, 2009, at 11:22 PM, Drew Farris wrote:

> +1 for not checking in generated sources. Maven is more than capable of
> handling the process in a way that is transparent to the end user, and this
> is the established convention for maven builds.

Why don't we start with this and if it proves problematic, we can check in the gen. sources?  As long as Maven automates it, that should be fine.


> 
> On Dec 18, 2009 9:10 PM, "Benson Margulies" <bi...@gmail.com> wrote:
> 
> Let me describe the scenario I start with, just in case by some chance
> you all decide that it's not too bad.
> 
> There's a maven plugin that reads templates and writes sources.
> 
> We configure it to write them to target/generated-sources/...
> 
> The plugin automatically adds that directory to the compilation.
> 
> So, whenever you type maven, the sources are generated and compiled.
> So you have the sources from typing maven, and you don't have to worry
> about checking them in after changing a template, and you don't have
> to worry about someone changing a generated source and not changing
> the underlying template.
> 
> If this doesn't persuade, here's plan b.
> 
> the output of the generator goes into src/main/java, but the generator
> is only put into operation with -Pregenerate, so that those
> unconcerned with these templates don't see a lot of M's on these
> files. You might say, 'what M's? the new version will be textually
> identical, and svn is smarter than that.' If that's the consensus
> view, I'll just run it that way.


Re: An last-ditch argument against checking in generated sources...

Posted by Drew Farris <dr...@gmail.com>.
+1 for not checking in generated sources. Maven is more than capable of
handling the process in a way that is transparent to the end user, and this
is the established convention for maven builds.

On Dec 18, 2009 9:10 PM, "Benson Margulies" <bi...@gmail.com> wrote:

Let me describe the scenario I start with, just in case by some chance
you all decide that it's not too bad.

There's a maven plugin that reads templates and writes sources.

We configure it to write them to target/generated-sources/...

The plugin automatically adds that directory to the compilation.

So, whenever you type maven, the sources are generated and compiled.
So you have the sources from typing maven, and you don't have to worry
about checking them in after changing a template, and you don't have
to worry about someone changing a generated source and not changing
the underlying template.

If this doesn't persuade, here's plan b.

the output of the generator goes into src/main/java, but the generator
is only put into operation with -Pregenerate, so that those
unconcerned with these templates don't see a lot of M's on these
files. You might say, 'what M's? the new version will be textually
identical, and svn is smarter than that.' If that's the consensus
view, I'll just run it that way.