[jira] [Created] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

["Marlon Pierce (JIRA)" <ji...@apache.org>]

The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository. 
--------------------------------------------------------------------------------------------------------------------

                 Key: RAVE-171
                 URL: https://issues.apache.org/jira/browse/RAVE-171
             Project: Rave
          Issue Type: Sub-task
            Reporter: Marlon Pierce


Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

[Ate Douma <at...@douma.nu>]

On 09/16/2011 04:56 PM, Ate Douma wrote:
> I've taken this proposal and stretched it a bit further :)
> Please review the comment I added here:
>
>
> http://issues.apache.org/jira/secure/EditComment!default.jspa?id=12518501&commentId=13106190
Oops, I incorrectly copy/pasted the Edit comment link, please use the following:

 
https://issues.apache.org/jira/browse/RAVE-171?focusedCommentId=13106190#comment-13106190

>
>
> As a summary, what I propose is to split up the rave-portal such that only a
> pom.xml remains to build it.
>
> That then will allow for truly and proper customization for any custom portal
> project you like, as well as allow embedding rave-portal within another/existing
> project if you want.
>
> The most important element (to me) is: splitting off code from (web)
> resources/configurations as combining those in a "final" war module makes it
> very difficult and problematic to extend and/or embed elsewhere.
>
> If this proposal is acceptable, I'd volunteering to "implement" it.
> This will require quite some code/file shuffling, and potentially might hit some
> snags concerning keeping the tests working or working again.
> But other than that, it should not require real code/configuration changes
> (other than for tests and poms).
>
> WDYT?
>
> Ate
>
> On 08/16/2011 04:03 PM, Franklin, Matthew B. wrote:
>> I think we agreed on the following:
>>
>> Rave Project:
>> |
>> |__rave- components
>> | |
>> | |__rave-commons (Generic& common code that is usable in many different
>> contexts, modules and projects)
>> | |
>> | |__rave-core (Core Model, Service& Repository classes that are used by
>> multiple applications) [Widget, Person& related Classes]
>> | |
>> | |__rave-security (Security related classes) [User extends Person, Security
>> Utilities, etc]
>> |
>> |__rave-providers
>> | |
>> | |__rave-opensocial (OpenSocial provider classes)
>> | |
>> | |__rave-w3c (W3C provider classes)
>> |
>> |__rave-portal (Core portal& webapp related features) [Regions, Pages,
>> controllers, etc]
>> |
>> |__rave-shindig
>>
>>> -----Original Message-----
>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>> Sent: Tuesday, August 16, 2011 9:03 AM
>>> To: rave-dev@incubator.apache.org
>>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should
>>> create a jar as well as a war and deploy this jar to the local repository.
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Do we have consensus on this code reorganization?
>>>
>>>
>>> Marlon
>>>
>>>
>>> On 8/12/11 10:02 AM, Ate Douma wrote:
>>>> On 08/12/2011 02:59 PM, Franklin, Matthew B. wrote:
>>>>>> -----Original Message-----
>>>>>> From: Ate Douma [mailto:ate@douma.nu]
>>>>>> Sent: Friday, August 12, 2011 5:57 AM
>>>>>> To: rave-dev@incubator.apache.org
>>>>>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal
>>> should
>>>>>> create a jar as well as a war and deploy this jar to the local repository.
>>>>>>
>>>>>> On 08/12/2011 01:05 AM, Franklin, Matthew B. wrote:
>>>>>>>> -----Original Message-----
>>>>>>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>>>>>>> Sent: Thursday, August 11, 2011 4:53 PM
>>>>>>>> To: rave-dev@incubator.apache.org
>>>>>>>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal
>>> should
>>>>>>>> create a jar as well as a war and deploy this jar to the local repository.
>>>>>>>>
>>>> I tried a quick and dirty separation that worked (that is, code compiled and
>>>> portal ran as expected): I moved all of rave-portal java code except
>>>> org/apache/rave/portal/web/ and org/apache/rave/provider/web/ to a
>>>>>>> new
>>>> module, rave-components (with a 'jar' target) and made rave-portal
>>>> dependent on rave-components.jar.
>>>>
>>>>>>>>
>>>>>>>> If we do have need to expose the subcomponents (sounds like we
>>> do),
>>>>>>> then I think the following structure would better fit the intent of
>>> modularity:
>>>>>>>>
>>>>>>>> Rave Project:
>>>>>>>> |
>>>>>>>> |__rave-modules/components/whatever
>>>>>>>> | |
>>>>>>>> | |__rave-commons (Generic& common code that is usable in
>>> many
>>>>>>> different contexts, modules and projects)
>>>>>>>> | |
>>>>>>>> | |__rave-core (Core Model, Service& Repository classes that are
>>> used
>>>>>>> by multiple applications) [Widget, Person& related Classes]
>>>>>>>> | |
>>>>>>>> | |__rave-security (Security related classes) [User extends Person,
>>>>>>> Security Utilities, etc]
>>>>>>>> |
>>>>>>>> |__rave-providers
>>>>>>>> | |
>>>>>>>> | |__rave-opensocial (OpenSocial provider classes)
>>>>>>>> | |
>>>>>>>> | |__rave-w3c (W3C provider classes)
>>>>>>>> |
>>>>>>>> |__rave-portal (Core portal& webapp related features) [Regions,
>>> Pages,
>>>>>>> controllers, etc]
>>>>>>>> |
>>>>>>>> |__rave-shindig
>>>>>>>>
>>>>>>>> I think this would give us the best breakup of functionality. The biggest
>>>>>>> question in my mind is the providers. I feel like they should be
>>> separable from
>>>>>>> everything with the exception of the javascript. If someone has a good
>>>>>>> strategy for managing this, I think this model would work well.
>>>>>>>>
>>>>>>> I like this.
>>>>>>>
>>>>>>> Not sure though if we need a two level separation for rave-
>>>>>>> modules/components.
>>>>>>> Wouldn't it be easier to either use only rave-components as root
>>> module?
>>>>>>> The only reason I can think of why that wouldn't be good enough if we
>>> ever
>>>>>>> end
>>>>>>> up needed "non-module" components, whatever that would be.
>>>>>>
>>>>>> So you would want to keep rave-commons, core& security under rave-
>>> project directly? Just to be clear what I meant by
>>> modules/components/whatever is that I wasn't sure about the name of that
>>> first level sub-module under rave-project.
>>>>> Ah, sorry my misunderstanding: I took your example too literal :)
>>>>> So, I'm fine with using either rave-modules/ or rave-components.
>>>>
>>>>> Thanks,
>>>>
>>>>> Ate
>>>>>>
>>>>>>>
>>>>>>> Concerning the rave-portal, ideally (from my POV at least) that shouldn't
>>> need
>>>>>>> to have any classes/resources left which might want/need to be
>>> extendable
>>>>>>> or
>>>>>>
>>>>>> I could see this making sense at some point
>>>>>>
>>>>>>> overridable, including even webapp specific features like the controller
>>> logic
>>>>>>> etc. That's maybe a bit far fetched right now, but eventually I'd like to be
>>>>>>> able to "assembly" my own custom portal including customizing the
>>> frontend.
>>>>>>>
>>>>>>
>>>>>> I am hoping you have a strategy for allowing extension (customization) of
>>> the base UI to fit your needs :)
>>>>>>
>>>>>>> It would be nice if for instance Shindig already were more "modular" in
>>> that
>>>>>>> respect so that instead of needing a war overlay with "hacking" our
>>> custom
>>>>>>> usage
>>>>>>> on top. Right now that's still a minor annoyance, but I expect it'll become
>>> more
>>>>>>> so when we need to "push" more features and/or customization within
>>> the
>>>>>>> rave-shindig build. We probably will need to "help" the Shindig project a
>>> bit to
>>>>>>> support us better in this respect.
>>>>>>>
>>>>>>> Anyway, all in due time and in general I prefer to pick a "battle" when
>>> there is
>>>>>>> a concrete use-case for it :) For the rave-components separation that
>>> seems
>>>>>>> to
>>>>>>> start now, further modularization of rave-portal itself (as webapp) can
>>> wait
>>>>>>> until we hit the wall there.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>>
>>>>>>> Ate
>>>>>>>
>>>>>>>>
>>>>
>>>> I don't think we have enough use cases yet to decide on finer grained rave
>>>> component jars, but making one comprehensive rave-components jar
>>>>>>> from
>>>> our current code organization is straightforward.
>>>>
>>>>
>>>>
>>>> Marlon
>>>>
>>>>
>>>>
>>>> On 8/11/11 10:37 AM, Ate Douma wrote:
>>>>>>>>>> On 08/11/2011 03:57 PM, Marlon Pierce wrote:
>>>>>>>>>> Considering the case at hand, I need to extend
>>> DefaultUserService.java
>>>>>>>>>> (and UserService.java), which are in
>>>>>>>>>> rave-portal/src/main/java/org/apache/rave/portal/service/.
>>>>>>>>>>> So, you'll at least need these in your classpath to be able to extend
>>> and
>>>> build, right?
>>>>>>>>>>
>>>>>>>>>>> Using a war overlay like we do with rave-shindig then won't help
>>> you: a
>>>> maven dependency on a war artifact won't expose its classpath.
>>>>>>>>>>
>>>>>>>>>>> This is why I think you'll need a proper separated module to do
>>> this.
>>>>>>>>>>
>>>>>>>>>>> Other than that and I think also mentioned some time before, I'd
>>> prefer
>>>> minimizing usage of war overlays, actually eventually even get rid of the
>>>>>>> rave-
>>>> shindig war overlay. They are just too cumbersome to work with, an easy
>>>> cause of "duplicate jar" hell, and have little or no support at all within
>>>> IDEs.
>>>>>>>>>>
>>>>>>>>>> These will
>>>>>>>>>> have a dependency on the UserRepository, so this will need to be
>>> wired
>>>>>>>>>> up. Other services (including unwritten ones) could also depend on
>>> the
>>>>>>>>>> UserRepository. This could be avoided by just extending the
>>> UserService
>>>>>>>>>> interface, but for my case this is not ideal--I only need to override
>>>>>>>>>> one method in DefaultUserService.
>>>>>>>>>>
>>>>>>>>>> So we may not have enough use cases yet to decide on the optimal
>>>>>>>>>> reorganization of the code.
>>>>>>>>>>
>>>>>>>>>> I'm happy to try Matt's recommended Spring magic in the short
>>> term.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Marlon
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
>>>>>>>>>>>>>> -----Original Message----- From: Ate Douma
>>> [mailto:ate@douma.nu]
>>>>>>>>>>>>>> Sent: Thursday, August 11, 2011 8:38 AM To:
>>>>>>>>>>>>>> rave-dev@incubator.apache.org Subject: [DISCUSS] (RAVE-
>>> 171) The
>>>>>>>>>>>>>> maven install for rave-portal should create a jar as well as a war
>>>>>>>>>>>>>> and deploy this jar to the local repository.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> IMO this is not the way how we should solve extensibility of
>>> the
>>>>>>>>>>>>>> functionality currently within the rave-portal module.
>>>>>>>>>>>>>
>>>>>>>>>>>>> +1
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Producing multiple artifacts from a single Maven module (pom)
>>> is a
>>>>>>>>>>>>>> bad pattern in general, as additional artifacts won't have any
>>>>>>>>>>>>>> meta-data context attached. For example, this additional
>>>>>>>>>>>>>> rave-portal jar artifact from the rave-portal war pom won't
>>> have
>>>>>>>>>>>>>> any transitive dependencies meta-data, nor will you have
>>> (from
>>>>>>>>>>>>>> maven) any "reference" back to its source origin, etc.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think that if we want to be able to make the functionality
>>> within
>>>>>>>>>>>>>> rave-portal extendable/customizable, we better start factoring
>>>>>>>>>>>>>> these out into real "component" or "service" modules. And
>>> add and
>>>>>>>>>>>>>> isolate interfaces and APIs so they can become "pluggable" by
>>>>>>>>>>>>>> themselves. The rave-commons module already represents
>>> one
>>>>>>> type
>>>> of
>>>>>>>>>>>>>> such modularization, but I think we'll need to go much further.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Possibly, but I think there might be a simpler way to handle it for
>>>>>>>>>>>>> now.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> My proposal would be to create a new rave pom module called
>>>>>>>>>>>>>> something like "rave-components" or "rave-services" and a)
>>> move
>>>>>>>>>>>>>> rave-commons under it as a sub module b) initiate a new sub
>>>>>>> module
>>>>>>>>>>>>>> (rave-security?) isolating the functionality currently within
>>>>>>>>>>>>>> rave-portal to be extended upon like by the science-gateway
>>> in the
>>>>>>>>>>>>>> sandbox
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would recommend having the science gateway use an overlay
>>> like
>>>>>>> we
>>>>>>>>>>>>> do with rave-shindig. This way, you can override
>>> implementations in
>>>>>>>>>>>>> rave-portal by injecting beans marked primary in the Spring
>>>>>>>>>>>>> application context. This shouldn't be too difficult to setup.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ate
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
>>>>>>>>>>>>>>> The maven install for rave-portal should create a jar as well as
>>>>>>>>>>>>>>> a war and
>>>>>>>>>>>>>> deploy this jar to the local repository.
>>>>>>>>>>>>>>> ---------------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>> ------
>>>>>>> ----
>>>> --------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>> -----------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Key: RAVE-171 URL:
>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/RAVE-171 Project:
>>> Rave
>>>>>>>>>>>>>>> Issue Type: Sub-task Reporter: Marlon Pierce
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Extension codes not in rave-portal src tree will need to be
>>> able
>>>>>>>>>>>>>>> to compile
>>>>>>>>>>>>>> against that code. This can be done by modifying
>>>>>>>>>>>>>> rave-portal/pom.xml so that it makes both a war and a jar and
>>>>>>>>>>>>>> installs both in the local repository. The extension code should
>>>>>>>>>>>>>> then have the appropriate dependency in its pom.xml
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- This message is automatically generated by JIRA. For more
>>>>>>>>>>>>>>> information on JIRA, see:
>>> http://www.atlassian.com/software/jira
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iQEcBAEBAgAGBQJOSmqEAAoJEEfVXEODPFIDGuoH/RtHsy6PcGnKF/bHpYtMY
>>> 5iE
>>> VIAXFnlDRUKisGkP2/cnW4joBSOFMha9qnkfkUKj5yf161pKl40ZVIvMxVs8NnIi
>>> d6PDkcwytE4MX8VVH6dHLzM/L/s3IUHqK6MGhFX1fh0J6uk4q2x65QopyeRESF
>>> ou
>>> EodwWBUuCxpJGrMpVhxayVcT2DrW98mYk2c5IE+lJFh0G0C8FaQXboWMrd83
>>> /xcZ
>>> WZZVBpHUc0vjv7qsdyaZfadkrO3BhJp2sCKk5FO2N2gjJkEyI1xkDg9YhF8Zonjk
>>> UjF3lYeYsTb4wEdq8LX+N79QzmZ4Qyg9DEuE8Fm6qXPXEyF2A/hXab4CkSuBnl
>>> w=
>>> =Vm4H
>>> -----END PGP SIGNATURE-----
>

Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

[Ate Douma <at...@douma.nu>]

I've taken this proposal and stretched it a bit further :)
Please review the comment I added here:

 
http://issues.apache.org/jira/secure/EditComment!default.jspa?id=12518501&commentId=13106190

As a summary, what I propose is to split up the rave-portal such that only a 
pom.xml remains to build it.

That then will allow for truly and proper customization for any custom portal 
project you like, as well as allow embedding rave-portal within another/existing 
project if you want.

The most important element (to me) is: splitting off code from (web) 
resources/configurations as combining those in a "final" war module makes it 
very difficult and problematic to extend and/or embed elsewhere.

If this proposal is acceptable, I'd volunteering to "implement" it.
This will require quite some code/file shuffling, and potentially might hit some 
snags concerning keeping the tests working or working again.
But other than that, it should not require real code/configuration changes 
(other than for tests and poms).

WDYT?

Ate

On 08/16/2011 04:03 PM, Franklin, Matthew B. wrote:
> I think we agreed on the following:
>
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic&   common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&    Repository classes that are used by multiple applications)  [Widget, Person&    related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&    webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig
>
>> -----Original Message-----
>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>> Sent: Tuesday, August 16, 2011 9:03 AM
>> To: rave-dev@incubator.apache.org
>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should
>> create a jar as well as a war and deploy this jar to the local repository.
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Do we have consensus on this code reorganization?
>>
>>
>> Marlon
>>
>>
>> On 8/12/11 10:02 AM, Ate Douma wrote:
>>> On 08/12/2011 02:59 PM, Franklin, Matthew B. wrote:
>>>>> -----Original Message-----
>>>>> From: Ate Douma [mailto:ate@douma.nu]
>>>>> Sent: Friday, August 12, 2011 5:57 AM
>>>>> To: rave-dev@incubator.apache.org
>>>>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal
>> should
>>>>> create a jar as well as a war and deploy this jar to the local repository.
>>>>>
>>>>> On 08/12/2011 01:05 AM, Franklin, Matthew B. wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>>>>>> Sent: Thursday, August 11, 2011 4:53 PM
>>>>>>> To: rave-dev@incubator.apache.org
>>>>>>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal
>> should
>>>>>>> create a jar as well as a war and deploy this jar to the local repository.
>>>>>>>
>>> I tried a quick and dirty separation that worked (that is, code compiled and
>>> portal ran as expected):  I moved all of rave-portal java code except
>>> org/apache/rave/portal/web/ and org/apache/rave/provider/web/ to a
>>>>>> new
>>> module, rave-components (with a 'jar' target) and made rave-portal
>>> dependent on rave-components.jar.
>>>
>>>>>>>
>>>>>>> If we do have need to expose the subcomponents (sounds like we
>> do),
>>>>>> then I think the following structure would better fit the intent of
>> modularity:
>>>>>>>
>>>>>>> Rave Project:
>>>>>>> |
>>>>>>> |__rave-modules/components/whatever
>>>>>>> |      |
>>>>>>> |      |__rave-commons  (Generic&    common code that is usable in
>> many
>>>>>> different contexts, modules and projects)
>>>>>>> |      |
>>>>>>> |      |__rave-core (Core Model, Service&    Repository classes that are
>> used
>>>>>> by multiple applications)  [Widget, Person&    related Classes]
>>>>>>> |      |
>>>>>>> |      |__rave-security (Security related classes) [User extends Person,
>>>>>> Security Utilities, etc]
>>>>>>> |
>>>>>>> |__rave-providers
>>>>>>> |      |
>>>>>>> |      |__rave-opensocial (OpenSocial provider classes)
>>>>>>> |      |
>>>>>>> |      |__rave-w3c (W3C provider classes)
>>>>>>> |
>>>>>>> |__rave-portal (Core portal&    webapp related features) [Regions,
>> Pages,
>>>>>> controllers, etc]
>>>>>>> |
>>>>>>> |__rave-shindig
>>>>>>>
>>>>>>> I think this would give us the best breakup of functionality.  The biggest
>>>>>> question in my mind is the providers.  I feel like they should be
>> separable from
>>>>>> everything with the exception of the javascript.  If someone has a good
>>>>>> strategy for managing this, I think this model would work well.
>>>>>>>
>>>>>> I like this.
>>>>>>
>>>>>> Not sure though if we need a two level separation for rave-
>>>>>> modules/components.
>>>>>> Wouldn't it be easier to either use only rave-components as root
>> module?
>>>>>> The only reason I can think of why that wouldn't be good enough if we
>> ever
>>>>>> end
>>>>>> up needed "non-module" components, whatever that would be.
>>>>>
>>>>> So you would want to keep rave-commons, core&   security under rave-
>> project directly?  Just to be clear what I meant by
>> modules/components/whatever is that I wasn't sure about the name of that
>> first level sub-module under rave-project.
>>>> Ah, sorry my misunderstanding: I took your example too literal :)
>>>> So, I'm fine with using either rave-modules/ or rave-components.
>>>
>>>> Thanks,
>>>
>>>> Ate
>>>>>
>>>>>>
>>>>>> Concerning the rave-portal, ideally (from my POV at least) that shouldn't
>> need
>>>>>> to have any classes/resources left which might want/need to be
>> extendable
>>>>>> or
>>>>>
>>>>> I could see this making sense at some point
>>>>>
>>>>>> overridable, including even webapp specific features like the controller
>> logic
>>>>>> etc. That's maybe a bit far fetched right now, but eventually I'd like to be
>>>>>> able to "assembly" my own custom portal including customizing the
>> frontend.
>>>>>>
>>>>>
>>>>> I am hoping you have a strategy for allowing extension (customization) of
>> the base UI to fit your needs :)
>>>>>
>>>>>> It would be nice if for instance Shindig already were more "modular" in
>> that
>>>>>> respect so that instead of needing a war overlay with "hacking" our
>> custom
>>>>>> usage
>>>>>> on top. Right now that's still a minor annoyance, but I expect it'll become
>> more
>>>>>> so when we need to "push" more features and/or customization within
>> the
>>>>>> rave-shindig build. We probably will need to "help" the Shindig project a
>> bit to
>>>>>> support us better in this respect.
>>>>>>
>>>>>> Anyway, all in due time and in general I prefer to pick a "battle" when
>> there is
>>>>>> a concrete use-case for it :) For the rave-components separation that
>> seems
>>>>>> to
>>>>>> start now, further modularization of rave-portal itself (as webapp) can
>> wait
>>>>>> until we hit the wall there.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>
>>>>>> Ate
>>>>>>
>>>>>>>
>>>
>>> I don't think we have enough use cases yet to decide on finer grained rave
>>> component jars, but making one comprehensive rave-components jar
>>>>>> from
>>> our current code organization is straightforward.
>>>
>>>
>>>
>>> Marlon
>>>
>>>
>>>
>>> On 8/11/11 10:37 AM, Ate Douma wrote:
>>>>>>>>> On 08/11/2011 03:57 PM, Marlon Pierce wrote:
>>>>>>>>> Considering the case at hand, I need to extend
>> DefaultUserService.java
>>>>>>>>> (and UserService.java), which are in
>>>>>>>>> rave-portal/src/main/java/org/apache/rave/portal/service/.
>>>>>>>>>> So, you'll at least need these in your classpath to be able to extend
>> and
>>> build, right?
>>>>>>>>>
>>>>>>>>>> Using a war overlay like we do with rave-shindig then won't help
>> you: a
>>> maven dependency on a war artifact won't expose its classpath.
>>>>>>>>>
>>>>>>>>>> This is why I think you'll need a proper separated module to do
>> this.
>>>>>>>>>
>>>>>>>>>> Other than that and  I think also mentioned some time before, I'd
>> prefer
>>> minimizing usage of war overlays, actually eventually even get rid of the
>>>>>> rave-
>>> shindig war overlay. They are just too cumbersome to work with, an easy
>>> cause of "duplicate jar" hell, and have little or no support at all within IDEs.
>>>>>>>>>
>>>>>>>>> These will
>>>>>>>>> have a dependency on the UserRepository, so this will need to be
>> wired
>>>>>>>>> up.  Other services (including unwritten ones) could also depend on
>> the
>>>>>>>>> UserRepository. This could be avoided by just extending the
>> UserService
>>>>>>>>> interface, but for my case this is not ideal--I only need to override
>>>>>>>>> one method in DefaultUserService.
>>>>>>>>>
>>>>>>>>> So we may not have enough use cases yet to decide on the optimal
>>>>>>>>> reorganization of the code.
>>>>>>>>>
>>>>>>>>> I'm happy to try Matt's recommended Spring magic in the short
>> term.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Marlon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
>>>>>>>>>>>>> -----Original Message----- From: Ate Douma
>> [mailto:ate@douma.nu]
>>>>>>>>>>>>> Sent: Thursday, August 11, 2011 8:38 AM To:
>>>>>>>>>>>>> rave-dev@incubator.apache.org Subject: [DISCUSS] (RAVE-
>> 171) The
>>>>>>>>>>>>> maven install for rave-portal should create a jar as well as a war
>>>>>>>>>>>>> and deploy this jar to the local repository.
>>>>>>>>>>>>>
>>>>>>>>>>>>> IMO this is not the way how we should solve extensibility of
>> the
>>>>>>>>>>>>> functionality currently within the rave-portal module.
>>>>>>>>>>>>
>>>>>>>>>>>> +1
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Producing multiple artifacts from a single Maven module (pom)
>> is a
>>>>>>>>>>>>> bad pattern in general, as additional artifacts won't have any
>>>>>>>>>>>>> meta-data context attached. For example, this additional
>>>>>>>>>>>>> rave-portal jar artifact from the rave-portal war pom won't
>> have
>>>>>>>>>>>>> any transitive dependencies meta-data, nor will you have
>> (from
>>>>>>>>>>>>> maven) any "reference" back to its source origin, etc.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think that if we want to be able to make the functionality
>> within
>>>>>>>>>>>>> rave-portal extendable/customizable, we better start factoring
>>>>>>>>>>>>> these out into real "component" or "service" modules. And
>> add and
>>>>>>>>>>>>> isolate interfaces and APIs so they can become "pluggable" by
>>>>>>>>>>>>> themselves. The rave-commons module already represents
>> one
>>>>>> type
>>> of
>>>>>>>>>>>>> such modularization, but I think we'll need to go much further.
>>>>>>>>>>>>>
>>>>>>>>>>>> Possibly, but I think there might be a simpler way to handle it for
>>>>>>>>>>>> now.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> My proposal would be to create a new rave pom module called
>>>>>>>>>>>>> something like "rave-components" or "rave-services" and a)
>> move
>>>>>>>>>>>>> rave-commons under it as a sub module b) initiate a new sub
>>>>>> module
>>>>>>>>>>>>> (rave-security?) isolating the functionality currently within
>>>>>>>>>>>>> rave-portal to be extended upon like by the science-gateway
>> in the
>>>>>>>>>>>>> sandbox
>>>>>>>>>>>>
>>>>>>>>>>>> I would recommend having the science gateway use an overlay
>> like
>>>>>> we
>>>>>>>>>>>> do with rave-shindig.  This way, you can override
>> implementations in
>>>>>>>>>>>> rave-portal by injecting beans marked primary in the Spring
>>>>>>>>>>>> application context.  This shouldn't be too difficult to setup.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ate
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
>>>>>>>>>>>>>> The maven install for rave-portal should create a jar as well as
>>>>>>>>>>>>>> a war and
>>>>>>>>>>>>> deploy this jar to the local repository.
>>>>>>>>>>>>>> ---------------------------------------------------------------------------
>> ------
>>>>>> ----
>>> --------
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>> -----------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Key: RAVE-171 URL:
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/RAVE-171 Project:
>> Rave
>>>>>>>>>>>>>> Issue Type: Sub-task Reporter: Marlon Pierce
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Extension codes not in rave-portal src tree will need to be
>> able
>>>>>>>>>>>>>> to compile
>>>>>>>>>>>>> against that code.  This can be done by modifying
>>>>>>>>>>>>> rave-portal/pom.xml so that it makes both a war and a jar and
>>>>>>>>>>>>> installs both in the local repository. The extension code should
>>>>>>>>>>>>> then have the appropriate dependency in its pom.xml
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- This message is automatically generated by JIRA. For more
>>>>>>>>>>>>>> information on JIRA, see:
>> http://www.atlassian.com/software/jira
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJOSmqEAAoJEEfVXEODPFIDGuoH/RtHsy6PcGnKF/bHpYtMY
>> 5iE
>> VIAXFnlDRUKisGkP2/cnW4joBSOFMha9qnkfkUKj5yf161pKl40ZVIvMxVs8NnIi
>> d6PDkcwytE4MX8VVH6dHLzM/L/s3IUHqK6MGhFX1fh0J6uk4q2x65QopyeRESF
>> ou
>> EodwWBUuCxpJGrMpVhxayVcT2DrW98mYk2c5IE+lJFh0G0C8FaQXboWMrd83
>> /xcZ
>> WZZVBpHUc0vjv7qsdyaZfadkrO3BhJp2sCKk5FO2N2gjJkEyI1xkDg9YhF8Zonjk
>> UjF3lYeYsTb4wEdq8LX+N79QzmZ4Qyg9DEuE8Fm6qXPXEyF2A/hXab4CkSuBnl
>> w=
>> =Vm4H
>> -----END PGP SIGNATURE-----

RE: [DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

["Franklin, Matthew B." <mf...@mitre.org>]

I think we agreed on the following:

Rave Project:
|
|__rave- components
|      |
|      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
|      |
|      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
|      |
|      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
|
|__rave-providers
|      |
|      |__rave-opensocial (OpenSocial provider classes)
|      |
|      |__rave-w3c (W3C provider classes)
|
|__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
|
|__rave-shindig

>-----Original Message-----
>From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>Sent: Tuesday, August 16, 2011 9:03 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should
>create a jar as well as a war and deploy this jar to the local repository.
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Do we have consensus on this code reorganization?
>
>
>Marlon
>
>
>On 8/12/11 10:02 AM, Ate Douma wrote:
>> On 08/12/2011 02:59 PM, Franklin, Matthew B. wrote:
>>>> -----Original Message-----
>>>> From: Ate Douma [mailto:ate@douma.nu]
>>>> Sent: Friday, August 12, 2011 5:57 AM
>>>> To: rave-dev@incubator.apache.org
>>>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal
>should
>>>> create a jar as well as a war and deploy this jar to the local repository.
>>>>
>>>> On 08/12/2011 01:05 AM, Franklin, Matthew B. wrote:
>>>>>> -----Original Message-----
>>>>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>>>>> Sent: Thursday, August 11, 2011 4:53 PM
>>>>>> To: rave-dev@incubator.apache.org
>>>>>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal
>should
>>>>>> create a jar as well as a war and deploy this jar to the local repository.
>>>>>>
>> I tried a quick and dirty separation that worked (that is, code compiled and
>> portal ran as expected):  I moved all of rave-portal java code except
>> org/apache/rave/portal/web/ and org/apache/rave/provider/web/ to a
>>>>> new
>> module, rave-components (with a 'jar' target) and made rave-portal
>> dependent on rave-components.jar.
>>
>>>>>>
>>>>>> If we do have need to expose the subcomponents (sounds like we
>do),
>>>>> then I think the following structure would better fit the intent of
>modularity:
>>>>>>
>>>>>> Rave Project:
>>>>>> |
>>>>>> |__rave-modules/components/whatever
>>>>>> |      |
>>>>>> |      |__rave-commons  (Generic&   common code that is usable in
>many
>>>>> different contexts, modules and projects)
>>>>>> |      |
>>>>>> |      |__rave-core (Core Model, Service&   Repository classes that are
>used
>>>>> by multiple applications)  [Widget, Person&   related Classes]
>>>>>> |      |
>>>>>> |      |__rave-security (Security related classes) [User extends Person,
>>>>> Security Utilities, etc]
>>>>>> |
>>>>>> |__rave-providers
>>>>>> |      |
>>>>>> |      |__rave-opensocial (OpenSocial provider classes)
>>>>>> |      |
>>>>>> |      |__rave-w3c (W3C provider classes)
>>>>>> |
>>>>>> |__rave-portal (Core portal&   webapp related features) [Regions,
>Pages,
>>>>> controllers, etc]
>>>>>> |
>>>>>> |__rave-shindig
>>>>>>
>>>>>> I think this would give us the best breakup of functionality.  The biggest
>>>>> question in my mind is the providers.  I feel like they should be
>separable from
>>>>> everything with the exception of the javascript.  If someone has a good
>>>>> strategy for managing this, I think this model would work well.
>>>>>>
>>>>> I like this.
>>>>>
>>>>> Not sure though if we need a two level separation for rave-
>>>>> modules/components.
>>>>> Wouldn't it be easier to either use only rave-components as root
>module?
>>>>> The only reason I can think of why that wouldn't be good enough if we
>ever
>>>>> end
>>>>> up needed "non-module" components, whatever that would be.
>>>>
>>>> So you would want to keep rave-commons, core&  security under rave-
>project directly?  Just to be clear what I meant by
>modules/components/whatever is that I wasn't sure about the name of that
>first level sub-module under rave-project.
>>> Ah, sorry my misunderstanding: I took your example too literal :)
>>> So, I'm fine with using either rave-modules/ or rave-components.
>>
>>> Thanks,
>>
>>> Ate
>>>>
>>>>>
>>>>> Concerning the rave-portal, ideally (from my POV at least) that shouldn't
>need
>>>>> to have any classes/resources left which might want/need to be
>extendable
>>>>> or
>>>>
>>>> I could see this making sense at some point
>>>>
>>>>> overridable, including even webapp specific features like the controller
>logic
>>>>> etc. That's maybe a bit far fetched right now, but eventually I'd like to be
>>>>> able to "assembly" my own custom portal including customizing the
>frontend.
>>>>>
>>>>
>>>> I am hoping you have a strategy for allowing extension (customization) of
>the base UI to fit your needs :)
>>>>
>>>>> It would be nice if for instance Shindig already were more "modular" in
>that
>>>>> respect so that instead of needing a war overlay with "hacking" our
>custom
>>>>> usage
>>>>> on top. Right now that's still a minor annoyance, but I expect it'll become
>more
>>>>> so when we need to "push" more features and/or customization within
>the
>>>>> rave-shindig build. We probably will need to "help" the Shindig project a
>bit to
>>>>> support us better in this respect.
>>>>>
>>>>> Anyway, all in due time and in general I prefer to pick a "battle" when
>there is
>>>>> a concrete use-case for it :) For the rave-components separation that
>seems
>>>>> to
>>>>> start now, further modularization of rave-portal itself (as webapp) can
>wait
>>>>> until we hit the wall there.
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Ate
>>>>>
>>>>>>
>>
>> I don't think we have enough use cases yet to decide on finer grained rave
>> component jars, but making one comprehensive rave-components jar
>>>>> from
>> our current code organization is straightforward.
>>
>>
>>
>> Marlon
>>
>>
>>
>> On 8/11/11 10:37 AM, Ate Douma wrote:
>>>>>>>> On 08/11/2011 03:57 PM, Marlon Pierce wrote:
>>>>>>>> Considering the case at hand, I need to extend
>DefaultUserService.java
>>>>>>>> (and UserService.java), which are in
>>>>>>>> rave-portal/src/main/java/org/apache/rave/portal/service/.
>>>>>>>>> So, you'll at least need these in your classpath to be able to extend
>and
>> build, right?
>>>>>>>>
>>>>>>>>> Using a war overlay like we do with rave-shindig then won't help
>you: a
>> maven dependency on a war artifact won't expose its classpath.
>>>>>>>>
>>>>>>>>> This is why I think you'll need a proper separated module to do
>this.
>>>>>>>>
>>>>>>>>> Other than that and  I think also mentioned some time before, I'd
>prefer
>> minimizing usage of war overlays, actually eventually even get rid of the
>>>>> rave-
>> shindig war overlay. They are just too cumbersome to work with, an easy
>> cause of "duplicate jar" hell, and have little or no support at all within IDEs.
>>>>>>>>
>>>>>>>> These will
>>>>>>>> have a dependency on the UserRepository, so this will need to be
>wired
>>>>>>>> up.  Other services (including unwritten ones) could also depend on
>the
>>>>>>>> UserRepository. This could be avoided by just extending the
>UserService
>>>>>>>> interface, but for my case this is not ideal--I only need to override
>>>>>>>> one method in DefaultUserService.
>>>>>>>>
>>>>>>>> So we may not have enough use cases yet to decide on the optimal
>>>>>>>> reorganization of the code.
>>>>>>>>
>>>>>>>> I'm happy to try Matt's recommended Spring magic in the short
>term.
>>>>>>>>
>>>>>>>>
>>>>>>>> Marlon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
>>>>>>>>>>>> -----Original Message----- From: Ate Douma
>[mailto:ate@douma.nu]
>>>>>>>>>>>> Sent: Thursday, August 11, 2011 8:38 AM To:
>>>>>>>>>>>> rave-dev@incubator.apache.org Subject: [DISCUSS] (RAVE-
>171) The
>>>>>>>>>>>> maven install for rave-portal should create a jar as well as a war
>>>>>>>>>>>> and deploy this jar to the local repository.
>>>>>>>>>>>>
>>>>>>>>>>>> IMO this is not the way how we should solve extensibility of
>the
>>>>>>>>>>>> functionality currently within the rave-portal module.
>>>>>>>>>>>
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Producing multiple artifacts from a single Maven module (pom)
>is a
>>>>>>>>>>>> bad pattern in general, as additional artifacts won't have any
>>>>>>>>>>>> meta-data context attached. For example, this additional
>>>>>>>>>>>> rave-portal jar artifact from the rave-portal war pom won't
>have
>>>>>>>>>>>> any transitive dependencies meta-data, nor will you have
>(from
>>>>>>>>>>>> maven) any "reference" back to its source origin, etc.
>>>>>>>>>>>>
>>>>>>>>>>>> I think that if we want to be able to make the functionality
>within
>>>>>>>>>>>> rave-portal extendable/customizable, we better start factoring
>>>>>>>>>>>> these out into real "component" or "service" modules. And
>add and
>>>>>>>>>>>> isolate interfaces and APIs so they can become "pluggable" by
>>>>>>>>>>>> themselves. The rave-commons module already represents
>one
>>>>> type
>> of
>>>>>>>>>>>> such modularization, but I think we'll need to go much further.
>>>>>>>>>>>>
>>>>>>>>>>> Possibly, but I think there might be a simpler way to handle it for
>>>>>>>>>>> now.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> My proposal would be to create a new rave pom module called
>>>>>>>>>>>> something like "rave-components" or "rave-services" and a)
>move
>>>>>>>>>>>> rave-commons under it as a sub module b) initiate a new sub
>>>>> module
>>>>>>>>>>>> (rave-security?) isolating the functionality currently within
>>>>>>>>>>>> rave-portal to be extended upon like by the science-gateway
>in the
>>>>>>>>>>>> sandbox
>>>>>>>>>>>
>>>>>>>>>>> I would recommend having the science gateway use an overlay
>like
>>>>> we
>>>>>>>>>>> do with rave-shindig.  This way, you can override
>implementations in
>>>>>>>>>>> rave-portal by injecting beans marked primary in the Spring
>>>>>>>>>>> application context.  This shouldn't be too difficult to setup.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Ate
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
>>>>>>>>>>>>> The maven install for rave-portal should create a jar as well as
>>>>>>>>>>>>> a war and
>>>>>>>>>>>> deploy this jar to the local repository.
>>>>>>>>>>>>> ---------------------------------------------------------------------------
>------
>>>>> ----
>> --------
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>> -----------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> Key: RAVE-171 URL:
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/RAVE-171 Project:
>Rave
>>>>>>>>>>>>> Issue Type: Sub-task Reporter: Marlon Pierce
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Extension codes not in rave-portal src tree will need to be
>able
>>>>>>>>>>>>> to compile
>>>>>>>>>>>> against that code.  This can be done by modifying
>>>>>>>>>>>> rave-portal/pom.xml so that it makes both a war and a jar and
>>>>>>>>>>>> installs both in the local repository. The extension code should
>>>>>>>>>>>> then have the appropriate dependency in its pom.xml
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- This message is automatically generated by JIRA. For more
>>>>>>>>>>>>> information on JIRA, see:
>http://www.atlassian.com/software/jira
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iQEcBAEBAgAGBQJOSmqEAAoJEEfVXEODPFIDGuoH/RtHsy6PcGnKF/bHpYtMY
>5iE
>VIAXFnlDRUKisGkP2/cnW4joBSOFMha9qnkfkUKj5yf161pKl40ZVIvMxVs8NnIi
>d6PDkcwytE4MX8VVH6dHLzM/L/s3IUHqK6MGhFX1fh0J6uk4q2x65QopyeRESF
>ou
>EodwWBUuCxpJGrMpVhxayVcT2DrW98mYk2c5IE+lJFh0G0C8FaQXboWMrd83
>/xcZ
>WZZVBpHUc0vjv7qsdyaZfadkrO3BhJp2sCKk5FO2N2gjJkEyI1xkDg9YhF8Zonjk
>UjF3lYeYsTb4wEdq8LX+N79QzmZ4Qyg9DEuE8Fm6qXPXEyF2A/hXab4CkSuBnl
>w=
>=Vm4H
>-----END PGP SIGNATURE-----

Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

[Marlon Pierce <mp...@cs.indiana.edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Do we have consensus on this code reorganization?


Marlon


On 8/12/11 10:02 AM, Ate Douma wrote:
> On 08/12/2011 02:59 PM, Franklin, Matthew B. wrote:
>>> -----Original Message-----
>>> From: Ate Douma [mailto:ate@douma.nu]
>>> Sent: Friday, August 12, 2011 5:57 AM
>>> To: rave-dev@incubator.apache.org
>>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should
>>> create a jar as well as a war and deploy this jar to the local repository.
>>>
>>> On 08/12/2011 01:05 AM, Franklin, Matthew B. wrote:
>>>>> -----Original Message-----
>>>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>>>> Sent: Thursday, August 11, 2011 4:53 PM
>>>>> To: rave-dev@incubator.apache.org
>>>>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should
>>>>> create a jar as well as a war and deploy this jar to the local repository.
>>>>>
> I tried a quick and dirty separation that worked (that is, code compiled and
> portal ran as expected):  I moved all of rave-portal java code except
> org/apache/rave/portal/web/ and org/apache/rave/provider/web/ to a
>>>> new
> module, rave-components (with a 'jar' target) and made rave-portal
> dependent on rave-components.jar.
> 
>>>>>
>>>>> If we do have need to expose the subcomponents (sounds like we do),
>>>> then I think the following structure would better fit the intent of modularity:
>>>>>
>>>>> Rave Project:
>>>>> |
>>>>> |__rave-modules/components/whatever
>>>>> |      |
>>>>> |      |__rave-commons  (Generic&   common code that is usable in many
>>>> different contexts, modules and projects)
>>>>> |      |
>>>>> |      |__rave-core (Core Model, Service&   Repository classes that are used
>>>> by multiple applications)  [Widget, Person&   related Classes]
>>>>> |      |
>>>>> |      |__rave-security (Security related classes) [User extends Person,
>>>> Security Utilities, etc]
>>>>> |
>>>>> |__rave-providers
>>>>> |      |
>>>>> |      |__rave-opensocial (OpenSocial provider classes)
>>>>> |      |
>>>>> |      |__rave-w3c (W3C provider classes)
>>>>> |
>>>>> |__rave-portal (Core portal&   webapp related features) [Regions, Pages,
>>>> controllers, etc]
>>>>> |
>>>>> |__rave-shindig
>>>>>
>>>>> I think this would give us the best breakup of functionality.  The biggest
>>>> question in my mind is the providers.  I feel like they should be separable from
>>>> everything with the exception of the javascript.  If someone has a good
>>>> strategy for managing this, I think this model would work well.
>>>>>
>>>> I like this.
>>>>
>>>> Not sure though if we need a two level separation for rave-
>>>> modules/components.
>>>> Wouldn't it be easier to either use only rave-components as root module?
>>>> The only reason I can think of why that wouldn't be good enough if we ever
>>>> end
>>>> up needed "non-module" components, whatever that would be.
>>>
>>> So you would want to keep rave-commons, core&  security under rave-project directly?  Just to be clear what I meant by modules/components/whatever is that I wasn't sure about the name of that first level sub-module under rave-project.
>> Ah, sorry my misunderstanding: I took your example too literal :)
>> So, I'm fine with using either rave-modules/ or rave-components.
> 
>> Thanks,
> 
>> Ate
>>>
>>>>
>>>> Concerning the rave-portal, ideally (from my POV at least) that shouldn't need
>>>> to have any classes/resources left which might want/need to be extendable
>>>> or
>>>
>>> I could see this making sense at some point
>>>
>>>> overridable, including even webapp specific features like the controller logic
>>>> etc. That's maybe a bit far fetched right now, but eventually I'd like to be
>>>> able to "assembly" my own custom portal including customizing the frontend.
>>>>
>>>
>>> I am hoping you have a strategy for allowing extension (customization) of the base UI to fit your needs :)
>>>
>>>> It would be nice if for instance Shindig already were more "modular" in that
>>>> respect so that instead of needing a war overlay with "hacking" our custom
>>>> usage
>>>> on top. Right now that's still a minor annoyance, but I expect it'll become more
>>>> so when we need to "push" more features and/or customization within the
>>>> rave-shindig build. We probably will need to "help" the Shindig project a bit to
>>>> support us better in this respect.
>>>>
>>>> Anyway, all in due time and in general I prefer to pick a "battle" when there is
>>>> a concrete use-case for it :) For the rave-components separation that seems
>>>> to
>>>> start now, further modularization of rave-portal itself (as webapp) can wait
>>>> until we hit the wall there.
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Ate
>>>>
>>>>>
> 
> I don't think we have enough use cases yet to decide on finer grained rave
> component jars, but making one comprehensive rave-components jar
>>>> from
> our current code organization is straightforward.
> 
> 
> 
> Marlon
> 
> 
> 
> On 8/11/11 10:37 AM, Ate Douma wrote:
>>>>>>> On 08/11/2011 03:57 PM, Marlon Pierce wrote:
>>>>>>> Considering the case at hand, I need to extend DefaultUserService.java
>>>>>>> (and UserService.java), which are in
>>>>>>> rave-portal/src/main/java/org/apache/rave/portal/service/.
>>>>>>>> So, you'll at least need these in your classpath to be able to extend and
> build, right?
>>>>>>>
>>>>>>>> Using a war overlay like we do with rave-shindig then won't help you: a
> maven dependency on a war artifact won't expose its classpath.
>>>>>>>
>>>>>>>> This is why I think you'll need a proper separated module to do this.
>>>>>>>
>>>>>>>> Other than that and  I think also mentioned some time before, I'd prefer
> minimizing usage of war overlays, actually eventually even get rid of the
>>>> rave-
> shindig war overlay. They are just too cumbersome to work with, an easy
> cause of "duplicate jar" hell, and have little or no support at all within IDEs.
>>>>>>>
>>>>>>> These will
>>>>>>> have a dependency on the UserRepository, so this will need to be wired
>>>>>>> up.  Other services (including unwritten ones) could also depend on the
>>>>>>> UserRepository. This could be avoided by just extending the UserService
>>>>>>> interface, but for my case this is not ideal--I only need to override
>>>>>>> one method in DefaultUserService.
>>>>>>>
>>>>>>> So we may not have enough use cases yet to decide on the optimal
>>>>>>> reorganization of the code.
>>>>>>>
>>>>>>> I'm happy to try Matt's recommended Spring magic in the short term.
>>>>>>>
>>>>>>>
>>>>>>> Marlon
>>>>>>>
>>>>>>>
>>>>>>> On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
>>>>>>>>>>> -----Original Message----- From: Ate Douma [mailto:ate@douma.nu]
>>>>>>>>>>> Sent: Thursday, August 11, 2011 8:38 AM To:
>>>>>>>>>>> rave-dev@incubator.apache.org Subject: [DISCUSS] (RAVE-171) The
>>>>>>>>>>> maven install for rave-portal should create a jar as well as a war
>>>>>>>>>>> and deploy this jar to the local repository.
>>>>>>>>>>>
>>>>>>>>>>> IMO this is not the way how we should solve extensibility of the
>>>>>>>>>>> functionality currently within the rave-portal module.
>>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Producing multiple artifacts from a single Maven module (pom) is a
>>>>>>>>>>> bad pattern in general, as additional artifacts won't have any
>>>>>>>>>>> meta-data context attached. For example, this additional
>>>>>>>>>>> rave-portal jar artifact from the rave-portal war pom won't have
>>>>>>>>>>> any transitive dependencies meta-data, nor will you have (from
>>>>>>>>>>> maven) any "reference" back to its source origin, etc.
>>>>>>>>>>>
>>>>>>>>>>> I think that if we want to be able to make the functionality within
>>>>>>>>>>> rave-portal extendable/customizable, we better start factoring
>>>>>>>>>>> these out into real "component" or "service" modules. And add and
>>>>>>>>>>> isolate interfaces and APIs so they can become "pluggable" by
>>>>>>>>>>> themselves. The rave-commons module already represents one
>>>> type
> of
>>>>>>>>>>> such modularization, but I think we'll need to go much further.
>>>>>>>>>>>
>>>>>>>>>> Possibly, but I think there might be a simpler way to handle it for
>>>>>>>>>> now.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> My proposal would be to create a new rave pom module called
>>>>>>>>>>> something like "rave-components" or "rave-services" and a) move
>>>>>>>>>>> rave-commons under it as a sub module b) initiate a new sub
>>>> module
>>>>>>>>>>> (rave-security?) isolating the functionality currently within
>>>>>>>>>>> rave-portal to be extended upon like by the science-gateway in the
>>>>>>>>>>> sandbox
>>>>>>>>>>
>>>>>>>>>> I would recommend having the science gateway use an overlay like
>>>> we
>>>>>>>>>> do with rave-shindig.  This way, you can override implementations in
>>>>>>>>>> rave-portal by injecting beans marked primary in the Spring
>>>>>>>>>> application context.  This shouldn't be too difficult to setup.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> WDYT?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Ate
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
>>>>>>>>>>>> The maven install for rave-portal should create a jar as well as
>>>>>>>>>>>> a war and
>>>>>>>>>>> deploy this jar to the local repository.
>>>>>>>>>>>> ---------------------------------------------------------------------------------
>>>> ----
> --------
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> -----------------------
>>>>>>>>>>>>
>>>>>>>>>>>> Key: RAVE-171 URL:
>>>>>>>>>>>> https://issues.apache.org/jira/browse/RAVE-171 Project: Rave
>>>>>>>>>>>> Issue Type: Sub-task Reporter: Marlon Pierce
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Extension codes not in rave-portal src tree will need to be able
>>>>>>>>>>>> to compile
>>>>>>>>>>> against that code.  This can be done by modifying
>>>>>>>>>>> rave-portal/pom.xml so that it makes both a war and a jar and
>>>>>>>>>>> installs both in the local repository. The extension code should
>>>>>>>>>>> then have the appropriate dependency in its pom.xml
>>>>>>>>>>>>
>>>>>>>>>>>> -- This message is automatically generated by JIRA. For more
>>>>>>>>>>>> information on JIRA, see: http://www.atlassian.com/software/jira
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOSmqEAAoJEEfVXEODPFIDGuoH/RtHsy6PcGnKF/bHpYtMY5iE
VIAXFnlDRUKisGkP2/cnW4joBSOFMha9qnkfkUKj5yf161pKl40ZVIvMxVs8NnIi
d6PDkcwytE4MX8VVH6dHLzM/L/s3IUHqK6MGhFX1fh0J6uk4q2x65QopyeRESFou
EodwWBUuCxpJGrMpVhxayVcT2DrW98mYk2c5IE+lJFh0G0C8FaQXboWMrd83/xcZ
WZZVBpHUc0vjv7qsdyaZfadkrO3BhJp2sCKk5FO2N2gjJkEyI1xkDg9YhF8Zonjk
UjF3lYeYsTb4wEdq8LX+N79QzmZ4Qyg9DEuE8Fm6qXPXEyF2A/hXab4CkSuBnlw=
=Vm4H
-----END PGP SIGNATURE-----

Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

[Ate Douma <at...@douma.nu>]

On 08/12/2011 02:59 PM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Friday, August 12, 2011 5:57 AM
>> To: rave-dev@incubator.apache.org
>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should
>> create a jar as well as a war and deploy this jar to the local repository.
>>
>> On 08/12/2011 01:05 AM, Franklin, Matthew B. wrote:
>>>> -----Original Message-----
>>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>>> Sent: Thursday, August 11, 2011 4:53 PM
>>>> To: rave-dev@incubator.apache.org
>>>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should
>>>> create a jar as well as a war and deploy this jar to the local repository.
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> I tried a quick and dirty separation that worked (that is, code compiled and
>>>> portal ran as expected):  I moved all of rave-portal java code except
>>>> org/apache/rave/portal/web/ and org/apache/rave/provider/web/ to a
>> new
>>>> module, rave-components (with a 'jar' target) and made rave-portal
>>>> dependent on rave-components.jar.
>>>>
>>>
>>> If we do have need to expose the subcomponents (sounds like we do),
>> then I think the following structure would better fit the intent of modularity:
>>>
>>> Rave Project:
>>> |
>>> |__rave-modules/components/whatever
>>> |      |
>>> |      |__rave-commons  (Generic&   common code that is usable in many
>> different contexts, modules and projects)
>>> |      |
>>> |      |__rave-core (Core Model, Service&   Repository classes that are used
>> by multiple applications)  [Widget, Person&   related Classes]
>>> |      |
>>> |      |__rave-security (Security related classes) [User extends Person,
>> Security Utilities, etc]
>>> |
>>> |__rave-providers
>>> |      |
>>> |      |__rave-opensocial (OpenSocial provider classes)
>>> |      |
>>> |      |__rave-w3c (W3C provider classes)
>>> |
>>> |__rave-portal (Core portal&   webapp related features) [Regions, Pages,
>> controllers, etc]
>>> |
>>> |__rave-shindig
>>>
>>> I think this would give us the best breakup of functionality.  The biggest
>> question in my mind is the providers.  I feel like they should be separable from
>> everything with the exception of the javascript.  If someone has a good
>> strategy for managing this, I think this model would work well.
>>>
>> I like this.
>>
>> Not sure though if we need a two level separation for rave-
>> modules/components.
>> Wouldn't it be easier to either use only rave-components as root module?
>> The only reason I can think of why that wouldn't be good enough if we ever
>> end
>> up needed "non-module" components, whatever that would be.
>
> So you would want to keep rave-commons, core&  security under rave-project directly?  Just to be clear what I meant by modules/components/whatever is that I wasn't sure about the name of that first level sub-module under rave-project.
Ah, sorry my misunderstanding: I took your example too literal :)
So, I'm fine with using either rave-modules/ or rave-components.

Thanks,

Ate
>
>>
>> Concerning the rave-portal, ideally (from my POV at least) that shouldn't need
>> to have any classes/resources left which might want/need to be extendable
>> or
>
> I could see this making sense at some point
>
>> overridable, including even webapp specific features like the controller logic
>> etc. That's maybe a bit far fetched right now, but eventually I'd like to be
>> able to "assembly" my own custom portal including customizing the frontend.
>>
>
> I am hoping you have a strategy for allowing extension (customization) of the base UI to fit your needs :)
>
>> It would be nice if for instance Shindig already were more "modular" in that
>> respect so that instead of needing a war overlay with "hacking" our custom
>> usage
>> on top. Right now that's still a minor annoyance, but I expect it'll become more
>> so when we need to "push" more features and/or customization within the
>> rave-shindig build. We probably will need to "help" the Shindig project a bit to
>> support us better in this respect.
>>
>> Anyway, all in due time and in general I prefer to pick a "battle" when there is
>> a concrete use-case for it :) For the rave-components separation that seems
>> to
>> start now, further modularization of rave-portal itself (as webapp) can wait
>> until we hit the wall there.
>>
>> Regards,
>>
>>
>> Ate
>>
>>>
>>>>
>>>> I don't think we have enough use cases yet to decide on finer grained rave
>>>> component jars, but making one comprehensive rave-components jar
>> from
>>>> our current code organization is straightforward.
>>>>
>>>>
>>>>
>>>> Marlon
>>>>
>>>>
>>>>
>>>> On 8/11/11 10:37 AM, Ate Douma wrote:
>>>>> On 08/11/2011 03:57 PM, Marlon Pierce wrote:
>>>>> Considering the case at hand, I need to extend DefaultUserService.java
>>>>> (and UserService.java), which are in
>>>>> rave-portal/src/main/java/org/apache/rave/portal/service/.
>>>>>> So, you'll at least need these in your classpath to be able to extend and
>>>> build, right?
>>>>>
>>>>>> Using a war overlay like we do with rave-shindig then won't help you: a
>>>> maven dependency on a war artifact won't expose its classpath.
>>>>>
>>>>>> This is why I think you'll need a proper separated module to do this.
>>>>>
>>>>>> Other than that and  I think also mentioned some time before, I'd prefer
>>>> minimizing usage of war overlays, actually eventually even get rid of the
>> rave-
>>>> shindig war overlay. They are just too cumbersome to work with, an easy
>>>> cause of "duplicate jar" hell, and have little or no support at all within IDEs.
>>>>>
>>>>> These will
>>>>> have a dependency on the UserRepository, so this will need to be wired
>>>>> up.  Other services (including unwritten ones) could also depend on the
>>>>> UserRepository. This could be avoided by just extending the UserService
>>>>> interface, but for my case this is not ideal--I only need to override
>>>>> one method in DefaultUserService.
>>>>>
>>>>> So we may not have enough use cases yet to decide on the optimal
>>>>> reorganization of the code.
>>>>>
>>>>> I'm happy to try Matt's recommended Spring magic in the short term.
>>>>>
>>>>>
>>>>> Marlon
>>>>>
>>>>>
>>>>> On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
>>>>>>>>> -----Original Message----- From: Ate Douma [mailto:ate@douma.nu]
>>>>>>>>> Sent: Thursday, August 11, 2011 8:38 AM To:
>>>>>>>>> rave-dev@incubator.apache.org Subject: [DISCUSS] (RAVE-171) The
>>>>>>>>> maven install for rave-portal should create a jar as well as a war
>>>>>>>>> and deploy this jar to the local repository.
>>>>>>>>>
>>>>>>>>> IMO this is not the way how we should solve extensibility of the
>>>>>>>>> functionality currently within the rave-portal module.
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Producing multiple artifacts from a single Maven module (pom) is a
>>>>>>>>> bad pattern in general, as additional artifacts won't have any
>>>>>>>>> meta-data context attached. For example, this additional
>>>>>>>>> rave-portal jar artifact from the rave-portal war pom won't have
>>>>>>>>> any transitive dependencies meta-data, nor will you have (from
>>>>>>>>> maven) any "reference" back to its source origin, etc.
>>>>>>>>>
>>>>>>>>> I think that if we want to be able to make the functionality within
>>>>>>>>> rave-portal extendable/customizable, we better start factoring
>>>>>>>>> these out into real "component" or "service" modules. And add and
>>>>>>>>> isolate interfaces and APIs so they can become "pluggable" by
>>>>>>>>> themselves. The rave-commons module already represents one
>> type
>>>> of
>>>>>>>>> such modularization, but I think we'll need to go much further.
>>>>>>>>>
>>>>>>>> Possibly, but I think there might be a simpler way to handle it for
>>>>>>>> now.
>>>>>>>>
>>>>>>>>
>>>>>>>>> My proposal would be to create a new rave pom module called
>>>>>>>>> something like "rave-components" or "rave-services" and a) move
>>>>>>>>> rave-commons under it as a sub module b) initiate a new sub
>> module
>>>>>>>>> (rave-security?) isolating the functionality currently within
>>>>>>>>> rave-portal to be extended upon like by the science-gateway in the
>>>>>>>>> sandbox
>>>>>>>>
>>>>>>>> I would recommend having the science gateway use an overlay like
>> we
>>>>>>>> do with rave-shindig.  This way, you can override implementations in
>>>>>>>> rave-portal by injecting beans marked primary in the Spring
>>>>>>>> application context.  This shouldn't be too difficult to setup.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> WDYT?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Ate
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
>>>>>>>>>> The maven install for rave-portal should create a jar as well as
>>>>>>>>>> a war and
>>>>>>>>> deploy this jar to the local repository.
>>>>>>>>>> ---------------------------------------------------------------------------------
>> ----
>>>> --------
>>>>>>>>>
>>>>>>>>>>
>>>>> -----------------------
>>>>>>>>>>
>>>>>>>>>> Key: RAVE-171 URL:
>>>>>>>>>> https://issues.apache.org/jira/browse/RAVE-171 Project: Rave
>>>>>>>>>> Issue Type: Sub-task Reporter: Marlon Pierce
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Extension codes not in rave-portal src tree will need to be able
>>>>>>>>>> to compile
>>>>>>>>> against that code.  This can be done by modifying
>>>>>>>>> rave-portal/pom.xml so that it makes both a war and a jar and
>>>>>>>>> installs both in the local repository. The extension code should
>>>>>>>>> then have the appropriate dependency in its pom.xml
>>>>>>>>>>
>>>>>>>>>> -- This message is automatically generated by JIRA. For more
>>>>>>>>>> information on JIRA, see: http://www.atlassian.com/software/jira
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>>
>>>>
>> iQEcBAEBAgAGBQJOREFHAAoJEEfVXEODPFIDZ5IH/Rr6pt2CzwwhtULz1TXYsx+
>>>> X
>>>>
>> YjkE0IOH2+lidfFFbuPn69AMe3o+5KYcVdaXWgumI2LgbP9TWfKXSGKFinISRBii
>>>>
>> rzjhKG+VAldASCrSUjwec6TrSMmmhE7px9KVNWQrUyIkzyVi45wMRZlcGmMz
>>>> ki1P
>>>>
>> xlC+YsI5gNjcooRuvTA1r6XjYLZjw9IA9J0ncp6iKHhwIBeBD0UmM0btreqMLekz
>>>>
>> BLCVq9EaqyU9BoeiSMDIWOVlgDwQLXzbG4dQuyJPHw3saS1awBpoTGrM4a1k
>>>> nhdo
>>>>
>> /gFwyr5wkhV3YXJ689BciFmd3bipn9AD3Pa9Lcg/cZGpv2wIAcwZ48kxKTuzfEk=
>>>> =oD3n
>>>> -----END PGP SIGNATURE-----
>

RE: [DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

["Franklin, Matthew B." <mf...@mitre.org>]

>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Friday, August 12, 2011 5:57 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should
>create a jar as well as a war and deploy this jar to the local repository.
>
>On 08/12/2011 01:05 AM, Franklin, Matthew B. wrote:
>>> -----Original Message-----
>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>> Sent: Thursday, August 11, 2011 4:53 PM
>>> To: rave-dev@incubator.apache.org
>>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should
>>> create a jar as well as a war and deploy this jar to the local repository.
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> I tried a quick and dirty separation that worked (that is, code compiled and
>>> portal ran as expected):  I moved all of rave-portal java code except
>>> org/apache/rave/portal/web/ and org/apache/rave/provider/web/ to a
>new
>>> module, rave-components (with a 'jar' target) and made rave-portal
>>> dependent on rave-components.jar.
>>>
>>
>> If we do have need to expose the subcomponents (sounds like we do),
>then I think the following structure would better fit the intent of modularity:
>>
>> Rave Project:
>> |
>> |__rave-modules/components/whatever
>> |      |
>> |      |__rave-commons  (Generic&  common code that is usable in many
>different contexts, modules and projects)
>> |      |
>> |      |__rave-core (Core Model, Service&  Repository classes that are used
>by multiple applications)  [Widget, Person&  related Classes]
>> |      |
>> |      |__rave-security (Security related classes) [User extends Person,
>Security Utilities, etc]
>> |
>> |__rave-providers
>> |      |
>> |      |__rave-opensocial (OpenSocial provider classes)
>> |      |
>> |      |__rave-w3c (W3C provider classes)
>> |
>> |__rave-portal (Core portal&  webapp related features) [Regions, Pages,
>controllers, etc]
>> |
>> |__rave-shindig
>>
>> I think this would give us the best breakup of functionality.  The biggest
>question in my mind is the providers.  I feel like they should be separable from
>everything with the exception of the javascript.  If someone has a good
>strategy for managing this, I think this model would work well.
>>
>I like this.
>
>Not sure though if we need a two level separation for rave-
>modules/components.
>Wouldn't it be easier to either use only rave-components as root module?
>The only reason I can think of why that wouldn't be good enough if we ever
>end
>up needed "non-module" components, whatever that would be.

So you would want to keep rave-commons, core & security under rave-project directly?  Just to be clear what I meant by modules/components/whatever is that I wasn't sure about the name of that first level sub-module under rave-project.

>
>Concerning the rave-portal, ideally (from my POV at least) that shouldn't need
>to have any classes/resources left which might want/need to be extendable
>or

I could see this making sense at some point

>overridable, including even webapp specific features like the controller logic
>etc. That's maybe a bit far fetched right now, but eventually I'd like to be
>able to "assembly" my own custom portal including customizing the frontend.
>

I am hoping you have a strategy for allowing extension (customization) of the base UI to fit your needs :) 

>It would be nice if for instance Shindig already were more "modular" in that
>respect so that instead of needing a war overlay with "hacking" our custom
>usage
>on top. Right now that's still a minor annoyance, but I expect it'll become more
>so when we need to "push" more features and/or customization within the
>rave-shindig build. We probably will need to "help" the Shindig project a bit to
>support us better in this respect.
>
>Anyway, all in due time and in general I prefer to pick a "battle" when there is
>a concrete use-case for it :) For the rave-components separation that seems
>to
>start now, further modularization of rave-portal itself (as webapp) can wait
>until we hit the wall there.
>
>Regards,
>
>
>Ate
>
>>
>>>
>>> I don't think we have enough use cases yet to decide on finer grained rave
>>> component jars, but making one comprehensive rave-components jar
>from
>>> our current code organization is straightforward.
>>>
>>>
>>>
>>> Marlon
>>>
>>>
>>>
>>> On 8/11/11 10:37 AM, Ate Douma wrote:
>>>> On 08/11/2011 03:57 PM, Marlon Pierce wrote:
>>>> Considering the case at hand, I need to extend DefaultUserService.java
>>>> (and UserService.java), which are in
>>>> rave-portal/src/main/java/org/apache/rave/portal/service/.
>>>>> So, you'll at least need these in your classpath to be able to extend and
>>> build, right?
>>>>
>>>>> Using a war overlay like we do with rave-shindig then won't help you: a
>>> maven dependency on a war artifact won't expose its classpath.
>>>>
>>>>> This is why I think you'll need a proper separated module to do this.
>>>>
>>>>> Other than that and  I think also mentioned some time before, I'd prefer
>>> minimizing usage of war overlays, actually eventually even get rid of the
>rave-
>>> shindig war overlay. They are just too cumbersome to work with, an easy
>>> cause of "duplicate jar" hell, and have little or no support at all within IDEs.
>>>>
>>>> These will
>>>> have a dependency on the UserRepository, so this will need to be wired
>>>> up.  Other services (including unwritten ones) could also depend on the
>>>> UserRepository. This could be avoided by just extending the UserService
>>>> interface, but for my case this is not ideal--I only need to override
>>>> one method in DefaultUserService.
>>>>
>>>> So we may not have enough use cases yet to decide on the optimal
>>>> reorganization of the code.
>>>>
>>>> I'm happy to try Matt's recommended Spring magic in the short term.
>>>>
>>>>
>>>> Marlon
>>>>
>>>>
>>>> On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
>>>>>>>> -----Original Message----- From: Ate Douma [mailto:ate@douma.nu]
>>>>>>>> Sent: Thursday, August 11, 2011 8:38 AM To:
>>>>>>>> rave-dev@incubator.apache.org Subject: [DISCUSS] (RAVE-171) The
>>>>>>>> maven install for rave-portal should create a jar as well as a war
>>>>>>>> and deploy this jar to the local repository.
>>>>>>>>
>>>>>>>> IMO this is not the way how we should solve extensibility of the
>>>>>>>> functionality currently within the rave-portal module.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>>
>>>>>>>> Producing multiple artifacts from a single Maven module (pom) is a
>>>>>>>> bad pattern in general, as additional artifacts won't have any
>>>>>>>> meta-data context attached. For example, this additional
>>>>>>>> rave-portal jar artifact from the rave-portal war pom won't have
>>>>>>>> any transitive dependencies meta-data, nor will you have (from
>>>>>>>> maven) any "reference" back to its source origin, etc.
>>>>>>>>
>>>>>>>> I think that if we want to be able to make the functionality within
>>>>>>>> rave-portal extendable/customizable, we better start factoring
>>>>>>>> these out into real "component" or "service" modules. And add and
>>>>>>>> isolate interfaces and APIs so they can become "pluggable" by
>>>>>>>> themselves. The rave-commons module already represents one
>type
>>> of
>>>>>>>> such modularization, but I think we'll need to go much further.
>>>>>>>>
>>>>>>> Possibly, but I think there might be a simpler way to handle it for
>>>>>>> now.
>>>>>>>
>>>>>>>
>>>>>>>> My proposal would be to create a new rave pom module called
>>>>>>>> something like "rave-components" or "rave-services" and a) move
>>>>>>>> rave-commons under it as a sub module b) initiate a new sub
>module
>>>>>>>> (rave-security?) isolating the functionality currently within
>>>>>>>> rave-portal to be extended upon like by the science-gateway in the
>>>>>>>> sandbox
>>>>>>>
>>>>>>> I would recommend having the science gateway use an overlay like
>we
>>>>>>> do with rave-shindig.  This way, you can override implementations in
>>>>>>> rave-portal by injecting beans marked primary in the Spring
>>>>>>> application context.  This shouldn't be too difficult to setup.
>>>>>>>
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Ate
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
>>>>>>>>> The maven install for rave-portal should create a jar as well as
>>>>>>>>> a war and
>>>>>>>> deploy this jar to the local repository.
>>>>>>>>> ---------------------------------------------------------------------------------
>----
>>> --------
>>>>>>>>
>>>>>>>>>
>>>> -----------------------
>>>>>>>>>
>>>>>>>>> Key: RAVE-171 URL:
>>>>>>>>> https://issues.apache.org/jira/browse/RAVE-171 Project: Rave
>>>>>>>>> Issue Type: Sub-task Reporter: Marlon Pierce
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Extension codes not in rave-portal src tree will need to be able
>>>>>>>>> to compile
>>>>>>>> against that code.  This can be done by modifying
>>>>>>>> rave-portal/pom.xml so that it makes both a war and a jar and
>>>>>>>> installs both in the local repository. The extension code should
>>>>>>>> then have the appropriate dependency in its pom.xml
>>>>>>>>>
>>>>>>>>> -- This message is automatically generated by JIRA. For more
>>>>>>>>> information on JIRA, see: http://www.atlassian.com/software/jira
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>>
>iQEcBAEBAgAGBQJOREFHAAoJEEfVXEODPFIDZ5IH/Rr6pt2CzwwhtULz1TXYsx+
>>> X
>>>
>YjkE0IOH2+lidfFFbuPn69AMe3o+5KYcVdaXWgumI2LgbP9TWfKXSGKFinISRBii
>>>
>rzjhKG+VAldASCrSUjwec6TrSMmmhE7px9KVNWQrUyIkzyVi45wMRZlcGmMz
>>> ki1P
>>>
>xlC+YsI5gNjcooRuvTA1r6XjYLZjw9IA9J0ncp6iKHhwIBeBD0UmM0btreqMLekz
>>>
>BLCVq9EaqyU9BoeiSMDIWOVlgDwQLXzbG4dQuyJPHw3saS1awBpoTGrM4a1k
>>> nhdo
>>>
>/gFwyr5wkhV3YXJ689BciFmd3bipn9AD3Pa9Lcg/cZGpv2wIAcwZ48kxKTuzfEk=
>>> =oD3n
>>> -----END PGP SIGNATURE-----

Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

[Ate Douma <at...@douma.nu>]

On 08/12/2011 01:05 AM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>> Sent: Thursday, August 11, 2011 4:53 PM
>> To: rave-dev@incubator.apache.org
>> Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should
>> create a jar as well as a war and deploy this jar to the local repository.
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I tried a quick and dirty separation that worked (that is, code compiled and
>> portal ran as expected):  I moved all of rave-portal java code except
>> org/apache/rave/portal/web/ and org/apache/rave/provider/web/ to a new
>> module, rave-components (with a 'jar' target) and made rave-portal
>> dependent on rave-components.jar.
>>
>
> If we do have need to expose the subcomponents (sounds like we do), then I think the following structure would better fit the intent of modularity:
>
> Rave Project:
> |
> |__rave-modules/components/whatever
> |      |
> |      |__rave-commons  (Generic&  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&  Repository classes that are used by multiple applications)  [Widget, Person&  related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&  webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig
>
> I think this would give us the best breakup of functionality.  The biggest question in my mind is the providers.  I feel like they should be separable from everything with the exception of the javascript.  If someone has a good strategy for managing this, I think this model would work well.
>
I like this.

Not sure though if we need a two level separation for rave-modules/components. 
Wouldn't it be easier to either use only rave-components as root module?
The only reason I can think of why that wouldn't be good enough if we ever end 
up needed "non-module" components, whatever that would be.

Concerning the rave-portal, ideally (from my POV at least) that shouldn't need 
to have any classes/resources left which might want/need to be extendable or 
overridable, including even webapp specific features like the controller logic 
etc. That's maybe a bit far fetched right now, but eventually I'd like to be 
able to "assembly" my own custom portal including customizing the frontend.

It would be nice if for instance Shindig already were more "modular" in that 
respect so that instead of needing a war overlay with "hacking" our custom usage 
on top. Right now that's still a minor annoyance, but I expect it'll become more 
so when we need to "push" more features and/or customization within the 
rave-shindig build. We probably will need to "help" the Shindig project a bit to 
support us better in this respect.

Anyway, all in due time and in general I prefer to pick a "battle" when there is 
a concrete use-case for it :) For the rave-components separation that seems to 
start now, further modularization of rave-portal itself (as webapp) can wait 
until we hit the wall there.

Regards,


Ate

>
>>
>> I don't think we have enough use cases yet to decide on finer grained rave
>> component jars, but making one comprehensive rave-components jar from
>> our current code organization is straightforward.
>>
>>
>>
>> Marlon
>>
>>
>>
>> On 8/11/11 10:37 AM, Ate Douma wrote:
>>> On 08/11/2011 03:57 PM, Marlon Pierce wrote:
>>> Considering the case at hand, I need to extend DefaultUserService.java
>>> (and UserService.java), which are in
>>> rave-portal/src/main/java/org/apache/rave/portal/service/.
>>>> So, you'll at least need these in your classpath to be able to extend and
>> build, right?
>>>
>>>> Using a war overlay like we do with rave-shindig then won't help you: a
>> maven dependency on a war artifact won't expose its classpath.
>>>
>>>> This is why I think you'll need a proper separated module to do this.
>>>
>>>> Other than that and  I think also mentioned some time before, I'd prefer
>> minimizing usage of war overlays, actually eventually even get rid of the rave-
>> shindig war overlay. They are just too cumbersome to work with, an easy
>> cause of "duplicate jar" hell, and have little or no support at all within IDEs.
>>>
>>> These will
>>> have a dependency on the UserRepository, so this will need to be wired
>>> up.  Other services (including unwritten ones) could also depend on the
>>> UserRepository. This could be avoided by just extending the UserService
>>> interface, but for my case this is not ideal--I only need to override
>>> one method in DefaultUserService.
>>>
>>> So we may not have enough use cases yet to decide on the optimal
>>> reorganization of the code.
>>>
>>> I'm happy to try Matt's recommended Spring magic in the short term.
>>>
>>>
>>> Marlon
>>>
>>>
>>> On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
>>>>>>> -----Original Message----- From: Ate Douma [mailto:ate@douma.nu]
>>>>>>> Sent: Thursday, August 11, 2011 8:38 AM To:
>>>>>>> rave-dev@incubator.apache.org Subject: [DISCUSS] (RAVE-171) The
>>>>>>> maven install for rave-portal should create a jar as well as a war
>>>>>>> and deploy this jar to the local repository.
>>>>>>>
>>>>>>> IMO this is not the way how we should solve extensibility of the
>>>>>>> functionality currently within the rave-portal module.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>>
>>>>>>> Producing multiple artifacts from a single Maven module (pom) is a
>>>>>>> bad pattern in general, as additional artifacts won't have any
>>>>>>> meta-data context attached. For example, this additional
>>>>>>> rave-portal jar artifact from the rave-portal war pom won't have
>>>>>>> any transitive dependencies meta-data, nor will you have (from
>>>>>>> maven) any "reference" back to its source origin, etc.
>>>>>>>
>>>>>>> I think that if we want to be able to make the functionality within
>>>>>>> rave-portal extendable/customizable, we better start factoring
>>>>>>> these out into real "component" or "service" modules. And add and
>>>>>>> isolate interfaces and APIs so they can become "pluggable" by
>>>>>>> themselves. The rave-commons module already represents one type
>> of
>>>>>>> such modularization, but I think we'll need to go much further.
>>>>>>>
>>>>>> Possibly, but I think there might be a simpler way to handle it for
>>>>>> now.
>>>>>>
>>>>>>
>>>>>>> My proposal would be to create a new rave pom module called
>>>>>>> something like "rave-components" or "rave-services" and a) move
>>>>>>> rave-commons under it as a sub module b) initiate a new sub module
>>>>>>> (rave-security?) isolating the functionality currently within
>>>>>>> rave-portal to be extended upon like by the science-gateway in the
>>>>>>> sandbox
>>>>>>
>>>>>> I would recommend having the science gateway use an overlay like we
>>>>>> do with rave-shindig.  This way, you can override implementations in
>>>>>> rave-portal by injecting beans marked primary in the Spring
>>>>>> application context.  This shouldn't be too difficult to setup.
>>>>>>
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Ate
>>>>>>>
>>>>>>>
>>>>>>> On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
>>>>>>>> The maven install for rave-portal should create a jar as well as
>>>>>>>> a war and
>>>>>>> deploy this jar to the local repository.
>>>>>>>> -------------------------------------------------------------------------------------
>> --------
>>>>>>>
>>>>>>>>
>>> -----------------------
>>>>>>>>
>>>>>>>> Key: RAVE-171 URL:
>>>>>>>> https://issues.apache.org/jira/browse/RAVE-171 Project: Rave
>>>>>>>> Issue Type: Sub-task Reporter: Marlon Pierce
>>>>>>>>
>>>>>>>>
>>>>>>>> Extension codes not in rave-portal src tree will need to be able
>>>>>>>> to compile
>>>>>>> against that code.  This can be done by modifying
>>>>>>> rave-portal/pom.xml so that it makes both a war and a jar and
>>>>>>> installs both in the local repository. The extension code should
>>>>>>> then have the appropriate dependency in its pom.xml
>>>>>>>>
>>>>>>>> -- This message is automatically generated by JIRA. For more
>>>>>>>> information on JIRA, see: http://www.atlassian.com/software/jira
>>>>>>>>
>>>>>>>>
>>>>>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJOREFHAAoJEEfVXEODPFIDZ5IH/Rr6pt2CzwwhtULz1TXYsx+
>> X
>> YjkE0IOH2+lidfFFbuPn69AMe3o+5KYcVdaXWgumI2LgbP9TWfKXSGKFinISRBii
>> rzjhKG+VAldASCrSUjwec6TrSMmmhE7px9KVNWQrUyIkzyVi45wMRZlcGmMz
>> ki1P
>> xlC+YsI5gNjcooRuvTA1r6XjYLZjw9IA9J0ncp6iKHhwIBeBD0UmM0btreqMLekz
>> BLCVq9EaqyU9BoeiSMDIWOVlgDwQLXzbG4dQuyJPHw3saS1awBpoTGrM4a1k
>> nhdo
>> /gFwyr5wkhV3YXJ689BciFmd3bipn9AD3Pa9Lcg/cZGpv2wIAcwZ48kxKTuzfEk=
>> =oD3n
>> -----END PGP SIGNATURE-----

RE: [DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

["Franklin, Matthew B." <mf...@mitre.org>]

>-----Original Message-----
>From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>Sent: Thursday, August 11, 2011 4:53 PM
>To: rave-dev@incubator.apache.org
>Subject: Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should
>create a jar as well as a war and deploy this jar to the local repository.
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I tried a quick and dirty separation that worked (that is, code compiled and
>portal ran as expected):  I moved all of rave-portal java code except
>org/apache/rave/portal/web/ and org/apache/rave/provider/web/ to a new
>module, rave-components (with a 'jar' target) and made rave-portal
>dependent on rave-components.jar.
>

If we do have need to expose the subcomponents (sounds like we do), then I think the following structure would better fit the intent of modularity:

Rave Project:
|
|__rave-modules/components/whatever
|      |
|      |__rave-commons  (Generic & common code that is usable in many different contexts, modules and projects)
|      |
|      |__rave-core (Core Model, Service & Repository classes that are used by multiple applications)  [Widget, Person & related Classes]
|      |
|      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc] 
|
|__rave-providers
|      |
|      |__rave-opensocial (OpenSocial provider classes)
|      |
|      |__rave-w3c (W3C provider classes)
|      
|__rave-portal (Core portal & webapp related features) [Regions, Pages, controllers, etc]
|
|__rave-shindig    

I think this would give us the best breakup of functionality.  The biggest question in my mind is the providers.  I feel like they should be separable from everything with the exception of the javascript.  If someone has a good strategy for managing this, I think this model would work well.


>
>I don't think we have enough use cases yet to decide on finer grained rave
>component jars, but making one comprehensive rave-components jar from
>our current code organization is straightforward.
>
>
>
>Marlon
>
>
>
>On 8/11/11 10:37 AM, Ate Douma wrote:
>> On 08/11/2011 03:57 PM, Marlon Pierce wrote:
>> Considering the case at hand, I need to extend DefaultUserService.java
>> (and UserService.java), which are in
>> rave-portal/src/main/java/org/apache/rave/portal/service/.
>>> So, you'll at least need these in your classpath to be able to extend and
>build, right?
>>
>>> Using a war overlay like we do with rave-shindig then won't help you: a
>maven dependency on a war artifact won't expose its classpath.
>>
>>> This is why I think you'll need a proper separated module to do this.
>>
>>> Other than that and  I think also mentioned some time before, I'd prefer
>minimizing usage of war overlays, actually eventually even get rid of the rave-
>shindig war overlay. They are just too cumbersome to work with, an easy
>cause of "duplicate jar" hell, and have little or no support at all within IDEs.
>>
>> These will
>> have a dependency on the UserRepository, so this will need to be wired
>> up.  Other services (including unwritten ones) could also depend on the
>> UserRepository. This could be avoided by just extending the UserService
>> interface, but for my case this is not ideal--I only need to override
>> one method in DefaultUserService.
>>
>> So we may not have enough use cases yet to decide on the optimal
>> reorganization of the code.
>>
>> I'm happy to try Matt's recommended Spring magic in the short term.
>>
>>
>> Marlon
>>
>>
>> On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
>>>>>> -----Original Message----- From: Ate Douma [mailto:ate@douma.nu]
>>>>>> Sent: Thursday, August 11, 2011 8:38 AM To:
>>>>>> rave-dev@incubator.apache.org Subject: [DISCUSS] (RAVE-171) The
>>>>>> maven install for rave-portal should create a jar as well as a war
>>>>>> and deploy this jar to the local repository.
>>>>>>
>>>>>> IMO this is not the way how we should solve extensibility of the
>>>>>> functionality currently within the rave-portal module.
>>>>>
>>>>> +1
>>>>>
>>>>>>
>>>>>> Producing multiple artifacts from a single Maven module (pom) is a
>>>>>> bad pattern in general, as additional artifacts won't have any
>>>>>> meta-data context attached. For example, this additional
>>>>>> rave-portal jar artifact from the rave-portal war pom won't have
>>>>>> any transitive dependencies meta-data, nor will you have (from
>>>>>> maven) any "reference" back to its source origin, etc.
>>>>>>
>>>>>> I think that if we want to be able to make the functionality within
>>>>>> rave-portal extendable/customizable, we better start factoring
>>>>>> these out into real "component" or "service" modules. And add and
>>>>>> isolate interfaces and APIs so they can become "pluggable" by
>>>>>> themselves. The rave-commons module already represents one type
>of
>>>>>> such modularization, but I think we'll need to go much further.
>>>>>>
>>>>> Possibly, but I think there might be a simpler way to handle it for
>>>>> now.
>>>>>
>>>>>
>>>>>> My proposal would be to create a new rave pom module called
>>>>>> something like "rave-components" or "rave-services" and a) move
>>>>>> rave-commons under it as a sub module b) initiate a new sub module
>>>>>> (rave-security?) isolating the functionality currently within
>>>>>> rave-portal to be extended upon like by the science-gateway in the
>>>>>> sandbox
>>>>>
>>>>> I would recommend having the science gateway use an overlay like we
>>>>> do with rave-shindig.  This way, you can override implementations in
>>>>> rave-portal by injecting beans marked primary in the Spring
>>>>> application context.  This shouldn't be too difficult to setup.
>>>>>
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Ate
>>>>>>
>>>>>>
>>>>>> On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
>>>>>>> The maven install for rave-portal should create a jar as well as
>>>>>>> a war and
>>>>>> deploy this jar to the local repository.
>>>>>>> -------------------------------------------------------------------------------------
>--------
>>>>>>
>>>>>>>
>> -----------------------
>>>>>>>
>>>>>>> Key: RAVE-171 URL:
>>>>>>> https://issues.apache.org/jira/browse/RAVE-171 Project: Rave
>>>>>>> Issue Type: Sub-task Reporter: Marlon Pierce
>>>>>>>
>>>>>>>
>>>>>>> Extension codes not in rave-portal src tree will need to be able
>>>>>>> to compile
>>>>>> against that code.  This can be done by modifying
>>>>>> rave-portal/pom.xml so that it makes both a war and a jar and
>>>>>> installs both in the local repository. The extension code should
>>>>>> then have the appropriate dependency in its pom.xml
>>>>>>>
>>>>>>> -- This message is automatically generated by JIRA. For more
>>>>>>> information on JIRA, see: http://www.atlassian.com/software/jira
>>>>>>>
>>>>>>>
>>>>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iQEcBAEBAgAGBQJOREFHAAoJEEfVXEODPFIDZ5IH/Rr6pt2CzwwhtULz1TXYsx+
>X
>YjkE0IOH2+lidfFFbuPn69AMe3o+5KYcVdaXWgumI2LgbP9TWfKXSGKFinISRBii
>rzjhKG+VAldASCrSUjwec6TrSMmmhE7px9KVNWQrUyIkzyVi45wMRZlcGmMz
>ki1P
>xlC+YsI5gNjcooRuvTA1r6XjYLZjw9IA9J0ncp6iKHhwIBeBD0UmM0btreqMLekz
>BLCVq9EaqyU9BoeiSMDIWOVlgDwQLXzbG4dQuyJPHw3saS1awBpoTGrM4a1k
>nhdo
>/gFwyr5wkhV3YXJ689BciFmd3bipn9AD3Pa9Lcg/cZGpv2wIAcwZ48kxKTuzfEk=
>=oD3n
>-----END PGP SIGNATURE-----

Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

[Marlon Pierce <mp...@cs.indiana.edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I tried a quick and dirty separation that worked (that is, code compiled and portal ran as expected):  I moved all of rave-portal java code except org/apache/rave/portal/web/ and org/apache/rave/provider/web/ to a new module, rave-components (with a 'jar' target) and made rave-portal dependent on rave-components.jar.  


I don't think we have enough use cases yet to decide on finer grained rave component jars, but making one comprehensive rave-components jar from our current code organization is straightforward. 



Marlon



On 8/11/11 10:37 AM, Ate Douma wrote:
> On 08/11/2011 03:57 PM, Marlon Pierce wrote:
> Considering the case at hand, I need to extend DefaultUserService.java
> (and UserService.java), which are in
> rave-portal/src/main/java/org/apache/rave/portal/service/.
>> So, you'll at least need these in your classpath to be able to extend and build, right?
> 
>> Using a war overlay like we do with rave-shindig then won't help you: a maven dependency on a war artifact won't expose its classpath.
> 
>> This is why I think you'll need a proper separated module to do this.
> 
>> Other than that and  I think also mentioned some time before, I'd prefer minimizing usage of war overlays, actually eventually even get rid of the rave-shindig war overlay. They are just too cumbersome to work with, an easy cause of "duplicate jar" hell, and have little or no support at all within IDEs.
> 
> These will
> have a dependency on the UserRepository, so this will need to be wired
> up.  Other services (including unwritten ones) could also depend on the
> UserRepository. This could be avoided by just extending the UserService
> interface, but for my case this is not ideal--I only need to override
> one method in DefaultUserService.
> 
> So we may not have enough use cases yet to decide on the optimal
> reorganization of the code.
> 
> I'm happy to try Matt's recommended Spring magic in the short term.
> 
> 
> Marlon
> 
> 
> On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
>>>>> -----Original Message----- From: Ate Douma [mailto:ate@douma.nu]
>>>>> Sent: Thursday, August 11, 2011 8:38 AM To:
>>>>> rave-dev@incubator.apache.org Subject: [DISCUSS] (RAVE-171) The
>>>>> maven install for rave-portal should create a jar as well as a war
>>>>> and deploy this jar to the local repository.
>>>>>
>>>>> IMO this is not the way how we should solve extensibility of the
>>>>> functionality currently within the rave-portal module.
>>>>
>>>> +1
>>>>
>>>>>
>>>>> Producing multiple artifacts from a single Maven module (pom) is a
>>>>> bad pattern in general, as additional artifacts won't have any
>>>>> meta-data context attached. For example, this additional
>>>>> rave-portal jar artifact from the rave-portal war pom won't have
>>>>> any transitive dependencies meta-data, nor will you have (from
>>>>> maven) any "reference" back to its source origin, etc.
>>>>>
>>>>> I think that if we want to be able to make the functionality within
>>>>> rave-portal extendable/customizable, we better start factoring
>>>>> these out into real "component" or "service" modules. And add and
>>>>> isolate interfaces and APIs so they can become "pluggable" by
>>>>> themselves. The rave-commons module already represents one type of
>>>>> such modularization, but I think we'll need to go much further.
>>>>>
>>>> Possibly, but I think there might be a simpler way to handle it for
>>>> now.
>>>>
>>>>
>>>>> My proposal would be to create a new rave pom module called
>>>>> something like "rave-components" or "rave-services" and a) move
>>>>> rave-commons under it as a sub module b) initiate a new sub module
>>>>> (rave-security?) isolating the functionality currently within
>>>>> rave-portal to be extended upon like by the science-gateway in the
>>>>> sandbox
>>>>
>>>> I would recommend having the science gateway use an overlay like we
>>>> do with rave-shindig.  This way, you can override implementations in
>>>> rave-portal by injecting beans marked primary in the Spring
>>>> application context.  This shouldn't be too difficult to setup.
>>>>
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Ate
>>>>>
>>>>>
>>>>> On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
>>>>>> The maven install for rave-portal should create a jar as well as
>>>>>> a war and
>>>>> deploy this jar to the local repository.
>>>>>> ---------------------------------------------------------------------------------------------
>>>>>
>>>>>>
> -----------------------
>>>>>>
>>>>>> Key: RAVE-171 URL:
>>>>>> https://issues.apache.org/jira/browse/RAVE-171 Project: Rave
>>>>>> Issue Type: Sub-task Reporter: Marlon Pierce
>>>>>>
>>>>>>
>>>>>> Extension codes not in rave-portal src tree will need to be able
>>>>>> to compile
>>>>> against that code.  This can be done by modifying
>>>>> rave-portal/pom.xml so that it makes both a war and a jar and
>>>>> installs both in the local repository. The extension code should
>>>>> then have the appropriate dependency in its pom.xml
>>>>>>
>>>>>> -- This message is automatically generated by JIRA. For more
>>>>>> information on JIRA, see: http://www.atlassian.com/software/jira
>>>>>>
>>>>>>
>>>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOREFHAAoJEEfVXEODPFIDZ5IH/Rr6pt2CzwwhtULz1TXYsx+X
YjkE0IOH2+lidfFFbuPn69AMe3o+5KYcVdaXWgumI2LgbP9TWfKXSGKFinISRBii
rzjhKG+VAldASCrSUjwec6TrSMmmhE7px9KVNWQrUyIkzyVi45wMRZlcGmMzki1P
xlC+YsI5gNjcooRuvTA1r6XjYLZjw9IA9J0ncp6iKHhwIBeBD0UmM0btreqMLekz
BLCVq9EaqyU9BoeiSMDIWOVlgDwQLXzbG4dQuyJPHw3saS1awBpoTGrM4a1knhdo
/gFwyr5wkhV3YXJ689BciFmd3bipn9AD3Pa9Lcg/cZGpv2wIAcwZ48kxKTuzfEk=
=oD3n
-----END PGP SIGNATURE-----

Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

[Ate Douma <at...@douma.nu>]

On 08/11/2011 03:57 PM, Marlon Pierce wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Considering the case at hand, I need to extend DefaultUserService.java
> (and UserService.java), which are in
> rave-portal/src/main/java/org/apache/rave/portal/service/.
So, you'll at least need these in your classpath to be able to extend and build, 
right?

Using a war overlay like we do with rave-shindig then won't help you: a maven 
dependency on a war artifact won't expose its classpath.

This is why I think you'll need a proper separated module to do this.

Other than that and  I think also mentioned some time before, I'd prefer 
minimizing usage of war overlays, actually eventually even get rid of the 
rave-shindig war overlay. They are just too cumbersome to work with, an easy 
cause of "duplicate jar" hell, and have little or no support at all within IDEs.

> These will
> have a dependency on the UserRepository, so this will need to be wired
> up.  Other services (including unwritten ones) could also depend on the
> UserRepository. This could be avoided by just extending the UserService
> interface, but for my case this is not ideal--I only need to override
> one method in DefaultUserService.
>
> So we may not have enough use cases yet to decide on the optimal
> reorganization of the code.
>
> I'm happy to try Matt's recommended Spring magic in the short term.
>
>
> Marlon
>
>
> On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
>>> -----Original Message----- From: Ate Douma [mailto:ate@douma.nu]
>>> Sent: Thursday, August 11, 2011 8:38 AM To:
>>> rave-dev@incubator.apache.org Subject: [DISCUSS] (RAVE-171) The
>>> maven install for rave-portal should create a jar as well as a war
>>> and deploy this jar to the local repository.
>>>
>>> IMO this is not the way how we should solve extensibility of the
>>> functionality currently within the rave-portal module.
>>
>> +1
>>
>>>
>>> Producing multiple artifacts from a single Maven module (pom) is a
>>> bad pattern in general, as additional artifacts won't have any
>>> meta-data context attached. For example, this additional
>>> rave-portal jar artifact from the rave-portal war pom won't have
>>> any transitive dependencies meta-data, nor will you have (from
>>> maven) any "reference" back to its source origin, etc.
>>>
>>> I think that if we want to be able to make the functionality within
>>> rave-portal extendable/customizable, we better start factoring
>>> these out into real "component" or "service" modules. And add and
>>> isolate interfaces and APIs so they can become "pluggable" by
>>> themselves. The rave-commons module already represents one type of
>>> such modularization, but I think we'll need to go much further.
>>>
>> Possibly, but I think there might be a simpler way to handle it for
>> now.
>>
>>
>>> My proposal would be to create a new rave pom module called
>>> something like "rave-components" or "rave-services" and a) move
>>> rave-commons under it as a sub module b) initiate a new sub module
>>> (rave-security?) isolating the functionality currently within
>>> rave-portal to be extended upon like by the science-gateway in the
>>> sandbox
>>
>> I would recommend having the science gateway use an overlay like we
>> do with rave-shindig.  This way, you can override implementations in
>> rave-portal by injecting beans marked primary in the Spring
>> application context.  This shouldn't be too difficult to setup.
>>
>>>
>>> WDYT?
>>>
>>> Regards,
>>>
>>> Ate
>>>
>>>
>>> On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
>>>> The maven install for rave-portal should create a jar as well as
>>>> a war and
>>> deploy this jar to the local repository.
>>>> ---------------------------------------------------------------------------------------------
>>>
>>>>
> - -----------------------
>>>>
>>>> Key: RAVE-171 URL:
>>>> https://issues.apache.org/jira/browse/RAVE-171 Project: Rave
>>>> Issue Type: Sub-task Reporter: Marlon Pierce
>>>>
>>>>
>>>> Extension codes not in rave-portal src tree will need to be able
>>>> to compile
>>> against that code.  This can be done by modifying
>>> rave-portal/pom.xml so that it makes both a war and a jar and
>>> installs both in the local repository. The extension code should
>>> then have the appropriate dependency in its pom.xml
>>>>
>>>> -- This message is automatically generated by JIRA. For more
>>>> information on JIRA, see: http://www.atlassian.com/software/jira
>>>>
>>>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOQ9/mAAoJEEfVXEODPFIDVqwH/0zOWIxXQfKP4avJS+qmNQjL
> rfurBDxCXWbCJrS0n4JL3oXoY6w8LQlXqtgXHTeVBSrLjFDAPIrzMk/NxDKM0DvZ
> yQA+FVi4FbU4W8rTaVDaG61T8zoNVTkQ04HRIAr4Zoa253U54RRZm4//99LH/LfW
> BPq6M2hIItziVORzbrhOPJXp8006rLpyrLJq0r7ora42VlH4dtIi3pIouclPrYau
> iRBQ2QLeZ/MSIwzH4+apMmVswXzfKDuCwVWX0/M6mq69MWCmVdvr8W1ucAceYJ+9
> RbiuvQzTK/THCiUmFt4/wtWUB21kqoJwfqnuOl/hNhDcPg/B13LqSXCt1rxQcm0=
> =9fhF
> -----END PGP SIGNATURE-----

Re: [DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

[Marlon Pierce <mp...@cs.indiana.edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Considering the case at hand, I need to extend DefaultUserService.java
(and UserService.java), which are in
rave-portal/src/main/java/org/apache/rave/portal/service/.  These will
have a dependency on the UserRepository, so this will need to be wired
up.  Other services (including unwritten ones) could also depend on the
UserRepository. This could be avoided by just extending the UserService
interface, but for my case this is not ideal--I only need to override
one method in DefaultUserService.

So we may not have enough use cases yet to decide on the optimal
reorganization of the code.

I'm happy to try Matt's recommended Spring magic in the short term.


Marlon


On 8/11/11 9:16 AM, Franklin, Matthew B. wrote:
>> -----Original Message----- From: Ate Douma [mailto:ate@douma.nu] 
>> Sent: Thursday, August 11, 2011 8:38 AM To:
>> rave-dev@incubator.apache.org Subject: [DISCUSS] (RAVE-171) The
>> maven install for rave-portal should create a jar as well as a war
>> and deploy this jar to the local repository.
>> 
>> IMO this is not the way how we should solve extensibility of the
>> functionality currently within the rave-portal module.
> 
> +1
> 
>> 
>> Producing multiple artifacts from a single Maven module (pom) is a
>> bad pattern in general, as additional artifacts won't have any
>> meta-data context attached. For example, this additional
>> rave-portal jar artifact from the rave-portal war pom won't have
>> any transitive dependencies meta-data, nor will you have (from 
>> maven) any "reference" back to its source origin, etc.
>> 
>> I think that if we want to be able to make the functionality within
>> rave-portal extendable/customizable, we better start factoring
>> these out into real "component" or "service" modules. And add and
>> isolate interfaces and APIs so they can become "pluggable" by 
>> themselves. The rave-commons module already represents one type of
>> such modularization, but I think we'll need to go much further.
>> 
> Possibly, but I think there might be a simpler way to handle it for
> now.
> 
> 
>> My proposal would be to create a new rave pom module called
>> something like "rave-components" or "rave-services" and a) move
>> rave-commons under it as a sub module b) initiate a new sub module
>> (rave-security?) isolating the functionality currently within
>> rave-portal to be extended upon like by the science-gateway in the
>> sandbox
> 
> I would recommend having the science gateway use an overlay like we
> do with rave-shindig.  This way, you can override implementations in
> rave-portal by injecting beans marked primary in the Spring
> application context.  This shouldn't be too difficult to setup.
> 
>> 
>> WDYT?
>> 
>> Regards,
>> 
>> Ate
>> 
>> 
>> On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
>>> The maven install for rave-portal should create a jar as well as
>>> a war and
>> deploy this jar to the local repository.
>>> ---------------------------------------------------------------------------------------------
>>
>>> 
- -----------------------
>>> 
>>> Key: RAVE-171 URL:
>>> https://issues.apache.org/jira/browse/RAVE-171 Project: Rave 
>>> Issue Type: Sub-task Reporter: Marlon Pierce
>>> 
>>> 
>>> Extension codes not in rave-portal src tree will need to be able
>>> to compile
>> against that code.  This can be done by modifying
>> rave-portal/pom.xml so that it makes both a war and a jar and
>> installs both in the local repository. The extension code should
>> then have the appropriate dependency in its pom.xml
>>> 
>>> -- This message is automatically generated by JIRA. For more
>>> information on JIRA, see: http://www.atlassian.com/software/jira
>>> 
>>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOQ9/mAAoJEEfVXEODPFIDVqwH/0zOWIxXQfKP4avJS+qmNQjL
rfurBDxCXWbCJrS0n4JL3oXoY6w8LQlXqtgXHTeVBSrLjFDAPIrzMk/NxDKM0DvZ
yQA+FVi4FbU4W8rTaVDaG61T8zoNVTkQ04HRIAr4Zoa253U54RRZm4//99LH/LfW
BPq6M2hIItziVORzbrhOPJXp8006rLpyrLJq0r7ora42VlH4dtIi3pIouclPrYau
iRBQ2QLeZ/MSIwzH4+apMmVswXzfKDuCwVWX0/M6mq69MWCmVdvr8W1ucAceYJ+9
RbiuvQzTK/THCiUmFt4/wtWUB21kqoJwfqnuOl/hNhDcPg/B13LqSXCt1rxQcm0=
=9fhF
-----END PGP SIGNATURE-----

RE: [DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

["Franklin, Matthew B." <mf...@mitre.org>]

>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Thursday, August 11, 2011 8:38 AM
>To: rave-dev@incubator.apache.org
>Subject: [DISCUSS] (RAVE-171) The maven install for rave-portal should create
>a jar as well as a war and deploy this jar to the local repository.
>
>IMO this is not the way how we should solve extensibility of the functionality
>currently within the rave-portal module.

+1

>
>Producing multiple artifacts from a single Maven module (pom) is a bad
>pattern
>in general, as additional artifacts won't have any meta-data context attached.
>For example, this additional rave-portal jar artifact from the rave-portal war
>pom won't have any transitive dependencies meta-data, nor will you have
>(from
>maven) any "reference" back to its source origin, etc.
>
>I think that if we want to be able to make the functionality within rave-portal
>extendable/customizable, we better start factoring these out into real
>"component" or "service" modules.
>And add and isolate interfaces and APIs so they can become "pluggable" by
>themselves.
>The rave-commons module already represents one type of such
>modularization, but
>I think we'll need to go much further.
>
Possibly, but I think there might be a simpler way to handle it for now.


>My proposal would be to create a new rave pom module called something like
>"rave-components" or "rave-services" and
>a) move rave-commons under it as a sub module
>b) initiate a new sub module (rave-security?) isolating the functionality
>currently within rave-portal to be extended upon like by the science-gateway
>in
>the sandbox

I would recommend having the science gateway use an overlay like we do with rave-shindig.  This way, you can override implementations in rave-portal by injecting beans marked primary in the Spring application context.  This shouldn't be too difficult to setup.    

>
>WDYT?
>
>Regards,
>
>Ate
>
>
>On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
>> The maven install for rave-portal should create a jar as well as a war and
>deploy this jar to the local repository.
>> ---------------------------------------------------------------------------------------------
>-----------------------
>>
>>                   Key: RAVE-171
>>                   URL: https://issues.apache.org/jira/browse/RAVE-171
>>               Project: Rave
>>            Issue Type: Sub-task
>>              Reporter: Marlon Pierce
>>
>>
>> Extension codes not in rave-portal src tree will need to be able to compile
>against that code.  This can be done by modifying rave-portal/pom.xml so that
>it makes both a war and a jar and installs both in the local repository. The
>extension code should then have the appropriate dependency in its pom.xml
>>
>> --
>> This message is automatically generated by JIRA.
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>

[DISCUSS] (RAVE-171) The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.

[Ate Douma <at...@douma.nu>]

IMO this is not the way how we should solve extensibility of the functionality 
currently within the rave-portal module.

Producing multiple artifacts from a single Maven module (pom) is a bad pattern 
in general, as additional artifacts won't have any meta-data context attached.
For example, this additional rave-portal jar artifact from the rave-portal war 
pom won't have any transitive dependencies meta-data, nor will you have (from 
maven) any "reference" back to its source origin, etc.

I think that if we want to be able to make the functionality within rave-portal 
extendable/customizable, we better start factoring these out into real 
"component" or "service" modules.
And add and isolate interfaces and APIs so they can become "pluggable" by 
themselves.
The rave-commons module already represents one type of such modularization, but 
I think we'll need to go much further.

My proposal would be to create a new rave pom module called something like 
"rave-components" or "rave-services" and
a) move rave-commons under it as a sub module
b) initiate a new sub module (rave-security?) isolating the functionality 
currently within rave-portal to be extended upon like by the science-gateway in 
the sandbox

WDYT?

Regards,

Ate


On 08/10/2011 08:58 PM, Marlon Pierce (JIRA) wrote:
> The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository.
> --------------------------------------------------------------------------------------------------------------------
>
>                   Key: RAVE-171
>                   URL: https://issues.apache.org/jira/browse/RAVE-171
>               Project: Rave
>            Issue Type: Sub-task
>              Reporter: Marlon Pierce
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Matt Franklin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108313#comment-13108313 ] 

Matt Franklin commented on RAVE-171:
------------------------------------

Should be all set.  I am still working on RAVE-99 but have the enough in place that I could remove the cross-package dependency.

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106190#comment-13106190 ] 

Ate Douma commented on RAVE-171:
--------------------------------

While I agree with Jasha that at some time (soon?) we might need to split off (some) interfaces into an separate api module, I'd like to postpone that as long as possible :)

Having interfaces separated will especially be useful for modules which provide a specific and separate implementation which makes no sense to extend. Most likely candidate for these are providers and persistence modules (like using a noSQL or JCR backend instead of JPA). The current JPA annotations in the rave/shindig model beans might give us some problems in this regard, but that has already been discussed before.
As long as we don't have a concrete use-case for this though, I don't want to deal with this upfront.
Site note: I expect we (Hippo) very likely will be the first to "hit" on this issue ourselves :)  

For commonly used services and alike, having access to the API *and* a default (or abstract) base implementation to easily extend, I'd rather keep them together as long as possible.

What I strongly agree with though is that we should cleanly separate our "components" such that portal extensions like currently in the sandbox can properly depend on these components and *not* rely on a custom jar produced from the main portal war pom. That solution is IMO fundamentally broken and a bad (Maven) pattern.

Instead, I'd actually would like to see the current rave-portal (and possibly rave-shindig as well) be "broken up" such that *no* java code remains ... (except for integration tests etc.)
One new component I therefore propose is: rave-portal-web, pulling out all o.a.r.portal.web.* classes (note: I propose this rave-portal-web and not rave-web for obvious reasons)
Which then only leaves (currently) the o.a.r.portal.util.LocalizationUtils class and related o.a.r.portal.module.util classes which I propose to move to the rave-commons module
 
What remains then only concerns the war resources: web.xml, Spring assemblies, css, jsp, etc. and test classes and configurations...

And then I'd like to stretch this proposal one bit further for truly and proper customization:
- split off a new rave-portal-dependencies pom module (under components) which aggregates all (default) portal dependencies
- split off all remaining test code and configurations in a new war module called rave-portal-test, which will use the above rave-portal-dependencies as dependencies, 
  optionally adding some additional test only dependencies, and finally *extend* the below specified rave-portal-resources war module as war overlay (see next),
  so it will by itself will become a proper (test only) rave-portal instance 
- move the remaining "shallow" rave-portal war module also under components, renaming it to rave-portal-resources and having *no* dependencies (meaining a shallow/abstract war module which cannot be deployed) 
- finally, create a new rave-portal war module which:
  a) extends (without further ado) the rave-portal-resources war
  b) depends *only* on rave-portal-dependencies 

The end result of the above restructuring proposal then will look something like:

Rave Project:
|
|__rave-components:pom
| |
| |__rave-commons:jar (Generic & common code that is usable in many different contexts, modules and projects)
| |
| |__rave-core:jar (Core Model, Service& Repository classes that are used by multiple applications) [Widget, Person& related Classes]
| |
| |__rave-security:jar (Security related classes) [User extends Person, Security Utilities, etc]
| |
| |__rave-portal-web:jar (Portal web/frontend related classes) [rest/rpc api, controller, renderer, etc]
| |
| |__rave-portal-dependencies:pom (aggregates all and only the rave-portal runtime dependencies) 
| |
| |__rave-portal-resources:war (shallow war having zero dependencies and all and only needed web resources for the rave-portal) 
| |
| |__rave-portal-test:war (rave test portal containing all the portal level test code and configurations) 
|
|__rave-providers:pom
| |
| |__rave-opensocial:jar (OpenSocial provider classes)
| |
| |__rave-w3c:jar (W3C provider classes)
|
|__rave-portal:war (pom.xml which only merges/overlays rave-portal-resources.war and depends on rave-portal-dependencies)   
|
|__rave-shindig:war 
 
WDYT?

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (RAVE-171) Reorganize project to support better extension

["Matt Franklin (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Franklin updated RAVE-171:
-------------------------------

    Fix Version/s: 0.4-INCUBATING

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Marlon Pierce (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106638#comment-13106638 ] 

Marlon Pierce commented on RAVE-171:
------------------------------------

Here's a list of common use cases that I can think of that involve a developer who would make a lot of local customizations.  I assume this developer would create a Maven project structure and depend upon the above jars, wars, and poms (following the template in the SVN sandbox and http://incubator.apache.org/rave/documentation/index.html). I think Ate's organization will support these, but it is a good idea to enumerate the cases as a sanity check.

1) Developer needs to override default authentication by extending existing Rave User and other classes.  This developer would depend upon rave-security.jar and override rave-portal-resources.war.  For example, the developer may want to use LDAP.

2) Override, customize home.jsp and other "view" pages, CSS, javascript, etc. This developer would override rave-portal-web and rave-portal-resources (?).  

3) Override default lightweight DB with a production quality one.   

4) Add additional fields to the User object and customize the backend DB.

5) Populate the portal with a large initial set of users. 

6) Use only some part of Rave, such as user management, but develop all web interfaces as standard web apps (ie no gadgets or widgets).


> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108712#comment-13108712 ] 

Ate Douma commented on RAVE-171:
--------------------------------

Thanks Matt.
I'll check it out and integrate it in my local version first to ensure the intended separation actually works :)

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Jasha Joachimsthal (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107746#comment-13107746 ] 

Jasha Joachimsthal commented on RAVE-171:
-----------------------------------------

Nice work Ate! I don't have outstanding changes.
I still don't get the difference between rave-common and rave-core. If it's common for multiple modules, isn't it a part of the core then?

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Matt Franklin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107915#comment-13107915 ] 

Matt Franklin commented on RAVE-171:
------------------------------------

I think o.a.r.portal.web.renderer should be moved to somewhere in rave.core.  

Personally, I am OK with anything in rave-provider depending on rave-components.  I just don't think it is good to have classes in rave.components depend on rave.provider.

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Assigned] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma reassigned RAVE-171:
------------------------------

    Assignee: Ate Douma

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>            Assignee: Ate Douma
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (RAVE-171) Reorganize project to support better extension

["Matt Franklin (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Franklin updated RAVE-171:
-------------------------------

    Description: 
Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml

Re-organize rave project in the following manner to support simpler extension by downstream integrators:

Rave Project:
|
|__rave- components
|      |
|      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
|      |
|      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
|      |
|      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
|
|__rave-providers
|      |
|      |__rave-opensocial (OpenSocial provider classes)
|      |
|      |__rave-w3c (W3C provider classes)
|
|__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
|
|__rave-shindig


  was:Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml

        Summary: Reorganize project to support better extension  (was: The maven install for rave-portal should create a jar as well as a war and deploy this jar to the local repository. )

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107928#comment-13107928 ] 

Ate Douma commented on RAVE-171:
--------------------------------

OK, that should be doable.
FYI: I already did move o.a.r.portal.web.renderer.* into rave-core.

What remains then indeed is the dependency of rave-portal-web (PageController) on rave-opensocial.
The PageController should be independent on any type of provider, e.g. only "get" one through dependency injection.

There is also the RenderServiceIntegrationTest.java, which I currently have kept in rave-portal-web but then can/need to move back to rave-portal as it depends on rave-portal-web, rave-opensocial and rave-w3c.

If you can resolve the PageController dependency from opensocial provider to take runtime dependency injection instead, I'll wait with my restructuring and then keep the rave-providers separate from rave-components.
I won't have time left then anymore today, but can pick this up by tomorrow (afternoon).


> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106832#comment-13106832 ] 

Ate Douma commented on RAVE-171:
--------------------------------

Concerning the customization use-cases from Marlon: I too think all those can or should be supported by the restructuring.

For use-case 2) I think the developer then would only need to override the rave-portal-resources (war), not the rave-portal-web (jar) as long as it only concerns client side resources and not server side objects (Java).

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107885#comment-13107885 ] 

Ate Douma commented on RAVE-171:
--------------------------------

@Jasha, agree with Matt rave-core being service layer and below.

Note: *current* exception on this is o.a.r.portal.web.renderer.* which might not be OK to keep or maybe the package (web) is wrong/too specific.

When I said rave-core being for rave-portal (components) I actually meant it *not* being targeted at rave-shindig as rave-common is.
But it could/should very well be usable without rave-portal-*, like writing your own "rave portal" embedded in a desktop application. 

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107740#comment-13107740 ] 

Ate Douma commented on RAVE-171:
--------------------------------

I went ahead and made a local fork of the rave project to prototype and test the proposed reorganization.
All in all it went pretty smoothly and I've got everything working again as before (note though: I did *not* pick up adjusting the sandbox projects, those *will* need fixing after this is done).

I did (had to) a few extra changes like splitting up the Spring applicationContext configurations and move them in properly namespaced classpath resources, like /org/apache/rave/core-ApplicationContext.xml.

Another thing to note is, that with the current implementation the rave-portal-web has a compile time dependency on rave-opensocial (provider) as its currently directly used from PageController (!).
A consequence of this is that the rave-providers:pom with submodules rave-opensocial and rave-w3c will have to be submodules of rave-components themselves, they cannot be separated out because neither side would build (rave-providers themselves depend on rave-commons & rave-core).

And I didn't (yet) know how to "split off" a rave-security component. It really depends how we want to partition that functionality, so I leave that out for now. Once the new structure is in place, it should become much more obvious if/how this might be done thereafter.

So, as a result I now have the following modules under new rave-components:pom:

rave-components:pom
 -- rave-common:jar
 -- rave-core:jar
 -- rave-providers:pom
    -- rave-opensocial:jar
    -- rave-w3c:jar
 -- rave-portal-web:jar
 -- rave-portal-resources:war
 -- rave-portal-dependencies:pom
  
And the rave-portal module remaining contents are only its pom.xml and the folders: main/dist, main/assembly, main/appended-resources and test/selenium 

I'm inclined to go ahead and "replay" my changes on trunk if there are no further objections.
Please note that this will take me an hour or so, during which its probably best not to have outstanding changes (or do intermediate commits) while the project structure is changing under your feet...

I'll hold off until I get at least a few (>1) +1 on this. And if/when I start, I'll send a heads-up on the list first to please hold back intermediate commits until I'm done.

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Jasha Joachimsthal (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107764#comment-13107764 ] 

Jasha Joachimsthal commented on RAVE-171:
-----------------------------------------

+0.95 
if rave-core is for the portal, shouldn't it be rave-portal-core then?

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Matt Franklin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107769#comment-13107769 ] 

Matt Franklin commented on RAVE-171:
------------------------------------

Two comments:

1)  I think that the rave-providers module needs to be directly under the rave-project, not under components.  This will ensure that we use the providers in a more modular way.  The dependency in the Page controller needs to go.  If you want, I can come up with a generic strategy and commit it before you reorganize today.

2) (To Jasha's last ?)  Rave-core in my opinion is everything at the service layer and below.  The rest belongs in rave-portal-web

After #1 is taken care of, I am +1 :)

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109031#comment-13109031 ] 

Ate Douma commented on RAVE-171:
--------------------------------

I'm almost there :)

The build including tests all work again, with the rave-providers separated out.
The only thing remaining to fix is some dependency tree changes which causes the rave-portal a startup failure (missing/incorrect commons-collections jar or something).
I'm very tempted to continue until done, which should be about 30 min ~ 1 hour, but alas my time is up, wife's calling ;)

So, tomorrow morning (CEST) I intend to wrap this up and do the final commit... which probably will end up being one-big-bang.
Splitting the changes in separate commits really isn't going to make much sense, and will for sure cause intermediate build errors.
FTR: I maintain as much as possible the original sources + svn history (using move/rename, not copy/paste), but of course there also are please new files/folders.



> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109347#comment-13109347 ] 

Ate Douma commented on RAVE-171:
--------------------------------

OK, commit will be coming in shortly.

The resulting new structure is largely as described above, but with a few changes I'll explain below:

Rave Project:
|
|__rave-components:pom
| |
| |__rave-commons:jar (Generic & common code that is usable in many different contexts, modules and projects)
| |
| |__rave-core:jar (Core Model, Service& Repository classes that are used by multiple applications) [Widget, Person& related Classes]
| |
| |__rave-web:jar (Portal web/frontend related classes) [rest/rpc api, controller, renderer, etc]
| 
|__rave-providers:pom
| |
| |__rave-opensocial-provider:jar (OpenSocial provider classes)
| |
| |__rave-w3c-provider:jar (W3C provider classes)
|
| __rave-portal-dependencies:pom (aggregates all and only the rave-portal runtime dependencies)
|
| __rave-portal-resources:war (shallow war having zero dependencies and all and only needed web resources for the rave-portal)
|
|__rave-portal:war (pom.xml which only merges/overlays rave-portal-resources.war and depends on rave-portal-dependencies)
|
|__rave-shindig:war 
|
|__rave-demo-gadgets:war 

Changes:
a) I moved/kept rave-portal-resources and rave-portal-dependencies outside rave-components as they clearly are related to and meant to be used for (a) rave-portal, not as just a rave-component.
    Furthermore, these both have references/dependencies to (default/example) rave-providers (opensocial, w3c), so anyway needed to be ordered as (later) sibling of rave-providers to prevent cyclic build dependencies.
a) I named rave-portal-web (back) to rave-web to better indicate its not directly or only rave-portal related, but should be seen as the "frontend" component. 
c) I named the rave-providers with a -provider postfix to clearly indicate and namespace their usages, e.g. rave-opensocial seemed to "generic" to my taste

Prominent remaining issue for which I shall create a new JIRA issue: so far we use a single mesages.properties file which contains messages (now) used across multiple modules.
For the time being I only kept this single file within rave-portal-resources, but this won't do for other use-cases which leverage the rave-components without rave-portal-resources.


> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Issue Comment Edited] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109409#comment-13109409 ] 

Ate Douma edited comment on RAVE-171 at 9/21/11 11:06 AM:
----------------------------------------------------------

The proposed project reorganization has been implemented.
Two minor follow up sub tasks have been identified: RAVE-273 and RAVE-274

      was (Author: adouma):
    The proposed project reorganization has been implemented.
Two minor follow up sub tasks have been identified: RAVE-173 and RAVE-174
  
> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>            Assignee: Ate Douma
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Resolved] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma resolved RAVE-171.
----------------------------

    Resolution: Fixed

The proposed project reorganization has been implemented.
Two minor follow up sub tasks have been identified: RAVE-173 and RAVE-174

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>            Assignee: Ate Douma
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma updated RAVE-171:
---------------------------

    Comment: was deleted

(was: Oh, forgot to add: if anyone has current pending changes, please do hold onto them until after I wrapped this up within the next 12 hours...)

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107761#comment-13107761 ] 

Ate Douma commented on RAVE-171:
--------------------------------

Hi Jasha, I gather that counts for a +1 :) ?

Concerning rave-common, the "common" part is that it can be used both by provider engines (e.g. shindig, read: rave-shindig) as well as the portal (components) themselves.
The rave-core really is only meant for rave-portal (components).
If/when we further centralize/generalize the persistence model it is my expectation this will then be done in/moved to rave-common.

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107869#comment-13107869 ] 

Ate Douma commented on RAVE-171:
--------------------------------

Matt, 

Its not just that rave-portal-web depends on rave-opensocial, the rave-providers also depend on both rave-common and rave-core (e.g. o.a.r.portal.model.* and o.a.r.web.renderer.*)
If you want rave-providers to be "independent", rave-common and (large) part of rave-core, or at least the interfaces thereof, need to be kept "independent" as well.
Either move all that to rave-common (but then also expose that to rave-shindig) and keep rave-common outside rave-components, or introduce a new module like rave-api (interfaces only?) which can be shared by anyone.

I'm willing to wait for you to do all that, but I suspect it'll cost you more than a few hours doable today...
Or, I can commit my changes first and we'll get a much clearer view on the situation than we have now and take it from there.



> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Jasha Joachimsthal (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105145#comment-13105145 ] 

Jasha Joachimsthal commented on RAVE-171:
-----------------------------------------

We should indeed split up the current structure, but then in a clean way:
- interfaces in an api module to enable a new project without using the default implementations
- implementations (JPA repositories, default services, possibly controllers) in a separate module that only produces a jar so it is possible to extend them but to have your own rendering
- rendering (jsp, css, Spring configuration) in a war (which can be overlayed)

This may also mean we have to split up the current rave-portal beans into interfaces and implementations because they are now annotated for JPA. (Most of) the beans in rave-shindig beans are implementations of Shindig interfaces.

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106827#comment-13106827 ] 

Ate Douma commented on RAVE-171:
--------------------------------

Creating the portal-test war isn't critical for this proposal, I'm also fine with leaving (only) the test code and configuration with the rave-portal war project itself.

The one benefit a separate portal-test war module brings: it can provide additional/custom frontend UI and/or configurations to be build/packaged with a runtime war for integration tests (e.g. like for Selenium and alike), without having to worry about these to pollute the "real" (end user) portal.  As long as we don't have any of that (yet), I'm fine without a separate portal-test war.

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109035#comment-13109035 ] 

Ate Douma commented on RAVE-171:
--------------------------------

Oh, forgot to add: if anyone has current pending changes, please do hold onto them until after I wrapped this up within the next 12 hours...

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RAVE-171) Reorganize project to support better extension

["Matt Franklin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAVE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106787#comment-13106787 ] 

Matt Franklin commented on RAVE-171:
------------------------------------

I agree with everything except the separate test war.  Do we really need to create a whole new war for just executing the tests?

> Reorganize project to support better extension
> ----------------------------------------------
>
>                 Key: RAVE-171
>                 URL: https://issues.apache.org/jira/browse/RAVE-171
>             Project: Rave
>          Issue Type: Sub-task
>            Reporter: Marlon Pierce
>             Fix For: 0.4-INCUBATING
>
>
> Extension codes not in rave-portal src tree will need to be able to compile against that code.  This can be done by modifying rave-portal/pom.xml so that it makes both a war and a jar and installs both in the local repository. The extension code should then have the appropriate dependency in its pom.xml
> Re-organize rave project in the following manner to support simpler extension by downstream integrators:
> Rave Project:
> |
> |__rave- components
> |      |
> |      |__rave-commons  (Generic &  common code that is usable in many different contexts, modules and projects)
> |      |
> |      |__rave-core (Core Model, Service&   Repository classes that are used by multiple applications)  [Widget, Person&   related Classes]
> |      |
> |      |__rave-security (Security related classes) [User extends Person, Security Utilities, etc]
> |
> |__rave-providers
> |      |
> |      |__rave-opensocial (OpenSocial provider classes)
> |      |
> |      |__rave-w3c (W3C provider classes)
> |
> |__rave-portal (Core portal&   webapp related features) [Regions, Pages, controllers, etc]
> |
> |__rave-shindig

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira