Raphael Luta wrote:
> Tomorrow morning (when I have a good permanent connectivity), I'll land
> in the CVS trunk a couple of changes and clen-up I've done over the
> week-end:
>
> Initialization:
> ===============
> I've fixed the initialization system so that it's not found anymore
> in the layout system.
>
> Rationale:
> When the Turbine templating system is incorporated, you'll want to use
> any Turbine layout and not only special Jetspeed-modified ones.
>
> How:
> you can now find a new servlet org.apache.jetspeed.Jetspeed which
> subclasses the Turbine servlet and adds its own initialization code
> there. I've removed the JetspeedInitializer class which has no more
> uses.
>
> Consequences:
> All the documentation on the setup of Jetspeed must be changed since
> the configuration should now use org.apache.jetspeed.Jetspeed rather
> than Turbine.
> Extract for my web.xml:
> <servlet>
> <servlet-name>jetspeed</servlet-name>
> <servlet-class>org.apache.jetspeed.Jetspeed</servlet-class>
> <init-param>
> <param-name>properties</param-name>
> <param-value>WEB-INF/config/TurbineResources.properties</param-value>
> </init-param>
> </servlet>
>
> The EngineContext class was using a rundata object for its initialization.
> Since this class was broken anyway (it's the cause for wrong URLs in
> case of multi-homed hosts), I temporarily fixed it with a servlet2.2
> only patch (which also solves the webapp relative links issue as an
> additional bonus). We need to implement a workaround for servlet2.1
> and 2.0 but I only had the servlet2.2 API with me...
>
> Most of the initialization work done in the Jetspeed servlet could
> actually be done by Turbine directly if the daemons, pools, etc...
> were implemented as TurbineServices. I'm definitely +1 for
> reimplementing all these packages as Turbine services.
>
> Properties system
> =================
> I've basically removed JetspeedResources which was just a copy of
> TurbineResources.
>
> Rationale:
> Why use 2 identic but distinct mechanisms for retrieving properties ?
>
> How:
> I've kept the JetspeedResources class but it's now just a collection
> of static key identifiers.
> All the work is done through TurbineResources.
>
> Consequences:
> The TurbineResources.properties has changed a little in order to
> include JetspeedResources.properties (with the include statement
> of ExtendedProperties). Don't forget to update this file if you
> want to check out the new build.
>
> I had to touch a lot of files to make this change.
>
It compiled without a glitch. I need to test the configuration to make it go,
though.
>
> Miscellanous:
> =============
> * I've removed several bogus import statements in some files as well
> as using class import statements rather than using package import.
> This makes it easier to track dependencies between classes. This
> would need to be done for a lot more files...
>
+1 on that, as the error gives a clear idea of the missing file. If you import
several packages, a missing class is reported as: "(unqualified)Xxx is not
defined", while with class level imports you get "class not found:
org.apache....", that can be tracked quickly.
>
> * I've removed the multiple @author and @version tags found in most
> source files I modified this week-end because :
> - the "@author/@version on each method" convention was not respected
> for all methods in all classes
> - it does not bring any real advantage to keep them
> - it makes the CVS diffs easier to read
>
It is even worse: The vast majority of conflicts I got during merge was due to
$version$ CVS tags differing in different versions of the files, even when the
only real difference was a misspelling in a comment. I got one conflict for
each method, instead of a global conflict.
For proper tracking, the @author tags are less troublesome WRT cvs, and allow
finer grain attribution of responsibilities. In any case, authorship should be
tracked at the file level, in this case, putting any new name together with
the task done (and maybe the date, to have historic ownership reflected).
>
> --
> Rapha�l Luta - [EMAIL PROTECTED]
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
