Matt Raible wrote:
Why are the themes at the support project and not a part of the core? We should talk to JavaLobby and see if they'll contribute their add-on
themes.

I think the big reason for this is because it shouldn't be the responsibility of the the core software developers to maintain a large set of addons. We are already in a position where the current themes are old and poorly maintained and I believe that has happened in part because there are so many themes in the core project. Moving the themes outside the core project allows the core developers to stay focused on the software itself and just worry about maintaining a few themes.

The other advantage of moving the themes, plugins, editors, etc, to the support project is that we can then invite more people to be part of that project and maintain any components that they want. It's a lot easier if we let our users maintain the addons and share them, rather than have the core developers have to maintain all that stuff.


If we move the themes to another location, I'd advocate we add a way
to easy download and install them.  Doing it from the admin UI would
be awesome.

Themes and templates is something I plan to focus on a bit in the 3.x development of Roller. There are a number of important changes we need to make for theme support, but a few that I would like to see are ...

1. make themes completely self contained and ideally packaged somehow, like in a jar file rather than just a directory like we have now. a theme package should contain all templates and resources (images, css, js, etc).

2. allow externalization of the themes from the application core. this allows someone to download and deploy the app without worrying about adding/removing themes to the built app and eventually the WAR file.

3. add some kind of metadata descriptor for themes. most likely an xml file that describes what the components of the theme are and some info about them. it's possible we don't need this, but we'll see.

4. dynamically add/remove/modify themes. so that you don't need to redeploy to make theme changes.

5. allow users (not only admins) to download and install a theme to their blog. admins would be able to add to the site wide selection of themes, but users would simply be importing all the elements of a theme into their custom theme.

-- Allen



Matt

On 5/7/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:


David M Johnson wrote:
> Thanks Allen.
>
> Based on Allen's feedback, I think the Roller Support project should offer:
>
> These required components (with docs)
>    Required Webapp Jars for Roller - for Webapp only
>    Required Source Jars for Roller - for building from source only
>
> And these optional components (with docs)
>    Optional page-plugins for Roller (JSPWiki page plugin)
>    Optional editor add-ins for Roller (Ekit and JavaScript enhanced
> plugins)
>    Optional themes for Roller (Ocadia and Spring)

I think that sounds good.

I also suggest that for Roller 3.0 we move some of the current themes
and plugins out to the support project and just make sure and tell our
users that during their upgrade if they want to keep those addons they
need to add them back on.  I suppose we could do that now if it makes
more sense to do it all in one pass.

I think the biggest reasoning for this is that the core project should
be focused on the software and not have to maintain lots of addons.  So
I think we should only maintain a few themes and a couple plugins.

-- Allen


>
>
> And as a result the Roller docs will changes as follows.
>
> The install guide installation docs will explain only:
> - How to get and install the missing Hibernate jars from the Hibernate
> project
> - The Roller Support project exists and has helpful downloads for
> installers
>
> The Install Guide upgrading Roller section will explain only that:
> - The JSPWiki plugin, Ekit editor and  JavaScript enhanced editor have
> been removed
> - The Roller Support project exists and has helpful downloads for upgraders
>
>
> I'll make these changes and prepare RC2, hopefully by sometime Monday.
>
> Anybody else want to weigh in?
>
> - Dave
>
>
> On May 6, 2006, at 12:46 PM, Allen Gilliland wrote:
>> David M Johnson wrote:
>>> On May 5, 2006, at 11:54 PM, Allen Gilliland wrote:
>>>> Just a little nit pick, but I think we can find a better way to
>>>> describe the extra downloads than "unshippables".  Maybe the Roller
>>>> "required libraries" and "optional libraries" or something like
>>>> that.  I think that is a little easier to understand to a first
>>>> time user trying to get the files.
>>> That's good feedback.
>>> If you read the Installation Guide you'll see that I explain how to
>>> get the Hibernate and other jars from the original "vendors" and not
>>> from the "Roller Support" project. I *do* reference the Roller
>>> Support project, but I never say specifically that you can getting
>>> all of the missing jars there.
>>> If you read the text on the Roller Support project (a project that
>>> is  supposed to be separate and independent from Roller) you'll see
>>> that  there are two "unshippable" downloads:
>>> ** Webapp Unshippables for Roller - all of the missing files
>>> (Hibernate, JSPWiki, XMLP JavaScript XML parser, etc.) arranged in
>>> Roller webapp directory structure, so that you can just unzip them
>>> ontop of a Roller install.
>>> ** Source Code Unshippables for Roller - all of the missing files
>>> (Hibernate, JSPWiki, XMLP JavaScript XML parser, etc.) arranged in
>>> Roller source directory structure, so that you can just unzip them
>>> ontop of a Roller install.
>>
>> yes, i understood all of that, but what i am saying is that to me
>> "unshippables" as a term doesn't mean anything.  i think that is a
>> confusing way of labeling that download and i think we can come up
>> with something better.
>>
>>
>>> So "required libraries" isn't correct, since the downloads contain
>>> both required and optional files and not just libraries. And
>>> "optional libraries" isn't quite right either.
>>
>> okay, then we just need to pick better terms, but there has to be a
>> way to separate out the required elements from the optional ones.
>>
>>
>>> I considered breaking everything up into separate optional and
>>> required downloads (listed below), but that defeats the purpose of
>>> the unshippables downloads, which is to make installation as easy as
>>> possible. Eventually, I'd like to move the optional parts to the
>>> Roller Support project entirely with build scripts that package them
>>> up as add-ins (and try to make that process easy), but for now, I
>>> think two unshippables downloads is the easier route to support
>>> Roller users.
>>> - Hibernate jars (required)
>>> - EJB 1.1 jar (required at buildtime)
>>> - JSPWiki plugin and jars (optional)
>>> - text-js editor and associated JavaScript classes (optional)
>>
>> personally, i don't like the idea of packaging the required and
>> optional stuff together so that the user just gets everything.  i
>> definitely want to make it as easy for the user as possible, but the
>> whole point of something being "optional" is that users are supposed
>> to choose to use it.  what you have now means that someone could
>> download the package just to get at the Hibernate jars which are
>> required, and they end up with the wiki and editor stuff that they
>> don't even want.
>>
>> so i still think required vs. optional packages makes some sense.  it
>> sounds like the required webapp addons is just the Hibernate jars, and
>> the required source addons are Hibernate + EJB 1.1.  everything else
>> is optional.
>>
>> i also think it is ideal that for the optional package we don't set it
>> up to automatically overlay a Roller build and dump everything into
>> the distribution.  assuming we want the optional package to contain
>> lots of stuff, like a whole set of plugins, themes, editors, etc.
>> either that, or we should be *very* vocal about the fact that
>> overlaying the optional package will add lots of things to the
>> standard distribution and users may want to add them individually
>> instead.
>>
>> -- Allen
>>
>>
>>> And one other point, perhaps we should have the "unshippables"
>>> discussion on the Roller Support project mailing list, since this is
>>> really not Apache business.
>>> - Dave
>>>>
>>>> -- Allen
>>>>
>>>>
>>>> Dave Johnson wrote:
>>>>
>>>>> I've put together a first release candidate (RC1) for Roller 2.3
>>>>> and  updated the user and installation docs. Please take a look.
>>>>> Here's a  summary of what's available for 2.3:
>>>>> *What's new*
>>>>> I updated the Roller 2.3 what's new page to include the 2.2
>>>>> features  and to mention that the release no longer includes the
>>>>> Hibernate  jars, the spell checker and the text-js editor.
>>>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Roller_2.3_WhatsNew
>>>>> *The release files*
>>>>> Roller is now distributed as two files:
>>>>> 1) the webapp download named apache-roller-X.Y-incubating.tar.gz and
>>>>> 2) the source code download named apache-roller-src-X.Y.tar.gz
>>>>> You can get those files for Roller 2.3 RC1 here:
>>>>> http://people.apache.org/~snoopdave/roller-2.3-rc/
>>>>> *The documentation*
>>>>> I updated the Roller Installation Guide to explain how to get the
>>>>> missing HIbernate and other jars. The User Guide has also been
>>>>> updated for 2.3. You can get both of these docs here:
>>>>> http://people.apache.org/~snoopdave/roller-2.3-rc/
>>>>> *The Roller Support project*
>>>>> I'm going to re-purpose Roller's former Java.Net home as the
>>>>> "Roller  Support" project, which will be devoted to supporting
>>>>> Roller. It will  host new plugins, themes and add-ons that we're
>>>>> not ready to support  in Roller or cannot distribute in Roller due
>>>>> to licensing issues. It  also hosts the "unshippables" -- a couple
>>>>> of downloads helpful when  installing Roller.
>>>>> https://roller.dev.java.net/
>

Reply via email to