You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Ate Douma <at...@douma.nu> on 2012/03/28 23:10:58 UTC
[DISCUSS] (RAVE-524) Move Rave-shindig
On 03/22/2012 10:34 PM, Matt Franklin (Created) (JIRA) wrote:
> Move Rave-shindig
> -----------------
>
> Key: RAVE-524
> URL: https://issues.apache.org/jira/browse/RAVE-524
> Project: Rave
> Issue Type: Technical task
> Reporter: Matt Franklin
>
>
> Create the following structure:
>
> rave-opensocial-provider
> |__rave-opensocial-core
> |__rave-opensocial-client
> |__rave-opensocial-server
> |_ rave-shindig
>
This new structure works and technically there is nothing wrong with it either,
but it isn't clear to me why we need rave-opensocial-server and rave-shindig,
nested under rave-opensocial-provider?
At least right now I see no added value (yet) nor a logical/functional reason as
neither the rave-opensocial-provider nor the rave-opensocial-server bring any
(maven/pom) added value.
Maybe I'm missing something obvious here but can't we keep rave-shindig and
rave-portal as sibling root modules? Both are very similar IMO, as pom only war
modules, aggregating everything else in and only needed in the last build phase.
And when overriding/extending rave for custom builds, typically neither
rave-portal nor rave-shindig will be used anymore but replaced with custom war
modules, so from that perspective these are kind of 'example' modules.
Ate
Re: [DISCUSS] (RAVE-524) Move Rave-shindig
Posted by Ate Douma <at...@douma.nu>.
On 03/28/2012 11:57 PM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Wednesday, March 28, 2012 5:11 PM
>> To: rave-dev@incubator.apache.org
>> Subject: [DISCUSS] (RAVE-524) Move Rave-shindig
>>
>> On 03/22/2012 10:34 PM, Matt Franklin (Created) (JIRA) wrote:
>>> Move Rave-shindig
>>> -----------------
>>>
>>> Key: RAVE-524
>>> URL: https://issues.apache.org/jira/browse/RAVE-524
>>> Project: Rave
>>> Issue Type: Technical task
>>> Reporter: Matt Franklin
>>>
>>>
>>> Create the following structure:
>>>
>>> rave-opensocial-provider
>>> |__rave-opensocial-core
>>> |__rave-opensocial-client
>>> |__rave-opensocial-server
>>> |_ rave-shindig
>>>
>> This new structure works and technically there is nothing wrong with it either,
>> but it isn't clear to me why we need rave-opensocial-server and rave-shindig,
>> nested under rave-opensocial-provider?
>>
>> At least right now I see no added value (yet) nor a logical/functional reason as
>> neither the rave-opensocial-provider nor the rave-opensocial-server bring
>> any
>> (maven/pom) added value.
>>
>> Maybe I'm missing something obvious here but can't we keep rave-shindig
>> and
>> rave-portal as sibling root modules? Both are very similar IMO, as pom only
>> war
>> modules, aggregating everything else in and only needed in the last build
>> phase.
>>
>
> IMO, the new structure simplifies the codebase from a logical perspective. Why have a rave-opensocial-provider separate from rave-shindig? Isn't Shindig part of the opensocial provider for Rave?
>
> If we begin expanding on Wookie to have rave customizations, wouldn't it make sense to keep them under the rave-w3c-provider structure?
>
> Another reason I thought it would be a good idea is that when we break shindig into rave-shindig-resources, rave-shindig-dependencies, rave-shindig, it pollutes the top level project structure.
Yeah, I see you point now. I clearly wasn't thinking it through and ahead enough :)
It is probably that I don't fancy too deeply nested module structures, which in
part is 'caused' by me still using Eclipse.
<side note>
IMO maven support in latest Eclipse (m2e) has been going *downhill* [1] and the
Sonatype/Eclipse developers seems to be not inclined to fix it (leaving it up to
maven plugin developers instead)...
So, I might convert (back) to IntelliJ soon
[1] http://wiki.eclipse.org/M2E_plugin_execution_not_covered
</side note>
>
> On the other hand, if there is a different model that makes more sense, I am not opposed to it...
No, I think this is fine/best after all. Sorry for the noise :)
>
>> And when overriding/extending rave for custom builds, typically neither
>> rave-portal nor rave-shindig will be used anymore but replaced with custom
>> war
>> modules, so from that perspective these are kind of 'example' modules.
>>
>> Ate
RE: [DISCUSS] (RAVE-524) Move Rave-shindig
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Wednesday, March 28, 2012 5:11 PM
>To: rave-dev@incubator.apache.org
>Subject: [DISCUSS] (RAVE-524) Move Rave-shindig
>
>On 03/22/2012 10:34 PM, Matt Franklin (Created) (JIRA) wrote:
>> Move Rave-shindig
>> -----------------
>>
>> Key: RAVE-524
>> URL: https://issues.apache.org/jira/browse/RAVE-524
>> Project: Rave
>> Issue Type: Technical task
>> Reporter: Matt Franklin
>>
>>
>> Create the following structure:
>>
>> rave-opensocial-provider
>> |__rave-opensocial-core
>> |__rave-opensocial-client
>> |__rave-opensocial-server
>> |_ rave-shindig
>>
>This new structure works and technically there is nothing wrong with it either,
>but it isn't clear to me why we need rave-opensocial-server and rave-shindig,
>nested under rave-opensocial-provider?
>
>At least right now I see no added value (yet) nor a logical/functional reason as
>neither the rave-opensocial-provider nor the rave-opensocial-server bring
>any
>(maven/pom) added value.
>
>Maybe I'm missing something obvious here but can't we keep rave-shindig
>and
>rave-portal as sibling root modules? Both are very similar IMO, as pom only
>war
>modules, aggregating everything else in and only needed in the last build
>phase.
>
IMO, the new structure simplifies the codebase from a logical perspective. Why have a rave-opensocial-provider separate from rave-shindig? Isn't Shindig part of the opensocial provider for Rave?
If we begin expanding on Wookie to have rave customizations, wouldn't it make sense to keep them under the rave-w3c-provider structure?
Another reason I thought it would be a good idea is that when we break shindig into rave-shindig-resources, rave-shindig-dependencies, rave-shindig, it pollutes the top level project structure.
On the other hand, if there is a different model that makes more sense, I am not opposed to it...
>And when overriding/extending rave for custom builds, typically neither
>rave-portal nor rave-shindig will be used anymore but replaced with custom
>war
>modules, so from that perspective these are kind of 'example' modules.
>
>Ate