portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Jetspeed 2 java packages structure (Re: Jetspeed 2 M4 focus: Documentation !)
Date Tue, 07 Jun 2005 07:46:03 GMT
David Sean Taylor wrote:
> Ate Douma wrote:
> 
>>
>> +1
>> But, I don't like to see an artificial package name like 'api'. I much
>> prefer the commonly used separation and distinction of 
>> core/implementation packages using an
>> impl subpackage.
>> And the same rule should apply for distinction of interfaces and 
>> implementations:
>> if an Class is an implementation of an interface we should postfix it 
>> with Impl.
> 
> 
> yes, i don't like api in the package path either
> 
>>
>> A special case may be interfaces defined in the core (portal subproject).
>> Should these (all) be moved to jetspeed-api?
> 
> 
> not if they aren't meant to be public
> otherwise they can remain under impl
> 
>> I would not be very much in favor as it would require exposure of 
>> core/implementation
>> specific api. These interfaces are not meant to be used by 
>> Portal/Portlet users/developers
>> but by integrators needing to configure/adapt the Jetspeed core 
>> features itself.
>> On the other hand, there are maybe some which are quite independent 
>> and as such could be
>> moved into jetspeed-api.
>>
> well, yes, if we find them to be public apis, then move them
> 
>>
>> To get more to the point, do you only want to "cleanup", remove some 
>> package mix ups between
>> different components/core or do you (also) want to define a more 
>> strict separation of the
>> (type of) packages?
>> Something like a restricted set of root packages as below:
>>   o.a.j.portal.
>>   o.a.j.container.
>>   o.a.j.components.
>>   o.a.j.portlets.
>>   o.a.j.applications.
> 
> 
> would o.a.j.portlets be for reusable portlets that are not a part of any 
> application?
Yes, that was what I had in mind: shared/common (base) portlets and portlet utilities maybe.
Stuff like inter-portlet communications might also have to end up there.
Somewhere under Portal Bridges might also be possible although that doesn't "sound" right.
Those kinds of features (J2 agnostic) really don't have a home yet...

> 
> 
>>   o.a.j.utils.
>>   o.a.j.tools. (e.g. deployer)
>>
> overall +1, although see my comments on org.apache.portals.applications 
> in my response to Raphael
> 
>> In my opinion, the above separation would be a great improvement but 
>> also touch almost every
>> class in the whole codebase and an awfull lot of work ...
>>
>> Although I think I would be in favor of this too, I can imagine some 
>> will be strongly against it because then almost all custom 
>> enhancements / integrations will have to be modified as result of it.
>> But, if we would "like" to do this: not doing it now probably means 
>> never doing it...
>>
> All my current installations/integrations run against milestone builds.
> Shouldn't be too much trouble ...
> Im +1 for the refactoring, although I'd like to have a close look at the 
> main refactoring of org.apache.jetspeed.portal and 
> org.apache.jetspeed.container
> 
> Regards,
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message