You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@streams.apache.org by Chris Geer <ch...@cxtsoftware.com> on 2013/03/15 04:26:56 UTC
Master POM
Would anyone object to removing the remote-resources plugin from the master
pom file? I understand why it's there but it keeps putting all
those boilerplate files in places they don't need to be. It would probably
make sense to have a plugin that verified the files were present in any
generated jars.
Chris
Re: Master POM
Posted by Jason Letourneau <jl...@gmail.com>.
+1 I'll admit that I went for overkill for fear of the backlash in
missing one location on a release or in our repo. Any refinement and
appropriate placement of those files is very welcomed.
Jason
On Fri, Mar 15, 2013 at 3:34 AM, Ate Douma <at...@douma.nu> wrote:
> IMO the problems isn't the remote-resources-plugin itself, but only the
> configuration of the outputDirectory, which shouldn't be needed, and
> certainly not point within the source directory.
>
> All those generated files are intended to be packaged during build-time
> only.
> So I'm +1 on removing those earlier generated files from the source trees as
> well as dropping the outputDirectory from the plugin. The plugin itself
> however should stay IMO.
>
> I'm willing to do a bit of cleaning of this this weekend if nobody beats me
> to it.
>
>
> On 03/15/2013 04:26 AM, Chris Geer wrote:
>>
>> Would anyone object to removing the remote-resources plugin from the
>> master
>> pom file? I understand why it's there but it keeps putting all
>> those boilerplate files in places they don't need to be. It would probably
>> make sense to have a plugin that verified the files were present in any
>> generated jars.
>>
>> Chris
>>
>
Re: Master POM
Posted by Ate Douma <at...@douma.nu>.
On 03/15/2013 02:36 PM, Chris Geer wrote:
> On Fri, Mar 15, 2013 at 12:34 AM, Ate Douma <at...@douma.nu> wrote:
>
>> IMO the problems isn't the remote-resources-plugin itself, but only the
>> configuration of the outputDirectory, which shouldn't be needed, and
>> certainly not point within the source directory.
>>
>> All those generated files are intended to be packaged during build-time
>> only.
>> So I'm +1 on removing those earlier generated files from the source trees
>> as well as dropping the outputDirectory from the plugin. The plugin itself
>> however should stay IMO.
>>
>
> Ate, your solution sounds perfect. If it can be made to inject them into
> the packages without adding to source we'll be good. We should also
> probably consider removing the existing one's from the source tree if we
> want the generated ones to be consistent.
>
Done.
Please do a thorough review and testing. I haven't done beyond just building.
On thing to maybe watch out for is that I 'connected' serveral poms to their
parent pom, where before they didn't have a parent.
>>
>> I'm willing to do a bit of cleaning of this this weekend if nobody beats
>> me to it.
>>
>>
>> On 03/15/2013 04:26 AM, Chris Geer wrote:
>>
>>> Would anyone object to removing the remote-resources plugin from the
>>> master
>>> pom file? I understand why it's there but it keeps putting all
>>> those boilerplate files in places they don't need to be. It would probably
>>> make sense to have a plugin that verified the files were present in any
>>> generated jars.
>>>
>>> Chris
>>>
>>>
>>
>
Re: Master POM
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Fri, Mar 15, 2013 at 12:34 AM, Ate Douma <at...@douma.nu> wrote:
> IMO the problems isn't the remote-resources-plugin itself, but only the
> configuration of the outputDirectory, which shouldn't be needed, and
> certainly not point within the source directory.
>
> All those generated files are intended to be packaged during build-time
> only.
> So I'm +1 on removing those earlier generated files from the source trees
> as well as dropping the outputDirectory from the plugin. The plugin itself
> however should stay IMO.
>
Ate, your solution sounds perfect. If it can be made to inject them into
the packages without adding to source we'll be good. We should also
probably consider removing the existing one's from the source tree if we
want the generated ones to be consistent.
>
> I'm willing to do a bit of cleaning of this this weekend if nobody beats
> me to it.
>
>
> On 03/15/2013 04:26 AM, Chris Geer wrote:
>
>> Would anyone object to removing the remote-resources plugin from the
>> master
>> pom file? I understand why it's there but it keeps putting all
>> those boilerplate files in places they don't need to be. It would probably
>> make sense to have a plugin that verified the files were present in any
>> generated jars.
>>
>> Chris
>>
>>
>
Re: Master POM
Posted by Ate Douma <at...@douma.nu>.
IMO the problems isn't the remote-resources-plugin itself, but only the
configuration of the outputDirectory, which shouldn't be needed, and certainly
not point within the source directory.
All those generated files are intended to be packaged during build-time only.
So I'm +1 on removing those earlier generated files from the source trees as
well as dropping the outputDirectory from the plugin. The plugin itself however
should stay IMO.
I'm willing to do a bit of cleaning of this this weekend if nobody beats me to it.
On 03/15/2013 04:26 AM, Chris Geer wrote:
> Would anyone object to removing the remote-resources plugin from the master
> pom file? I understand why it's there but it keeps putting all
> those boilerplate files in places they don't need to be. It would probably
> make sense to have a plugin that verified the files were present in any
> generated jars.
>
> Chris
>