Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shiro.apache.org
Received-SPF: pass (nike.apache.org: domain of kalle.o.korhonen@gmail.com
 designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAtvD4XAKLm+GokRF-=fB89X_WmVE9-bTvaQBnmwyfBQmCLE5Q@mail.gmail.com>
References: 
 <CAAtvD4XAKLm+GokRF-=fB89X_WmVE9-bTvaQBnmwyfBQmCLE5Q@mail.gmail.com>
Date: Sat, 20 Apr 2013 22:08:59 -0700
Message-ID: 
 <CA+=EWnAbaq-CrGSmkT_qJpRe1PmyQADEymwMczFGN6mzrH-1xw@mail.gmail.com>
Subject: Re: Shiro Spring Cleaning!
From: Kalle Korhonen <kalle.o.korhonen@gmail.com>
To: dev@shiro.apache.org
Content-Type: multipart/alternative; boundary=001a11c361fc2d4d2104dad7f351

--001a11c361fc2d4d2104dad7f351
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Apr 20, 2013 at 12:45 PM, Les Hazlewood <lhazlewood@apache.org>wrote:

> 2)
> First thing's first:  Apache has shut down the Confluence -> HTML ->
> prod server deployment pipeline, so we currently have *no* way to ship
> edited or new content to our website at the moment.  That means we
> need to put something in place asap.  We can't effectively release
> 1.2.2 without updating site content to indicate it has been released.
>

As Ulrich has alrealy mentioned to you, publishing Confluence content via
svnpubsub works fine and at least CXF, Camel, and Tapestry are using it. I
can speak to Tapestry's experiences with it and if anything, both
publishing and the using the website have become faster.

As an alternative, and mostly because I needed something similar for
> work here at Stormpath, I wrote a simple command line program that has
> proven to be pretty powerful.  We are now using it and it has been
> easily usable by non-technical employees (Apache 2.0 licensed):
> https://github.com/lhazlewood/scms
> It basically takes Markdown files (MultiMarkdown dialect mostly),
> renders them to HTML, and then merges that HTML with one or more
> defined HTML templates to control the look and feel.  The templates
> are Velocity templates and has a flexible content model +
> configuration approach.  It's basically the same effect as our
> Confluence-based setup, but even better:  all content is now managed
> and versioned in version control, so we can accept patches, rollback,
> etc.
>

So this is similar to Maven sites with APT although with a different
dialect? It works for some things but it's too clunky for users in general.
Wiki is the best way to include and allow the community to contribute. When
Tapestry made it easier for users to contribute we started getting
significantly more contributions. I think the path of least resistance is
keeping Confluence content and change it to export via svnpubsub.


> 3)
> 1.2.x has been pretty stable for a long time, and there are enough
> architectural inconveniences with Shiro (for devs and users) that I
> think it's time we tackle 2.x in force.
>
> I'd like to create a new branch of of trunk to ensure we keep what is
> there (should be nearly identical to the 1.2.x branch anyway) and use
> that for any related maintenance or 1.3 branch if that ever makes
> sense.  We then start using trunk for 2.0 (alpha).
>

Branch for 1.3.x and update the versions in the trunk to 2.0.0-SNAPSHOT
(mvn release:branch -DbranchName=1.3.x should do it). It doesn't matter
whether 1.3.0 ever gets released or not but release branching strategy with
svn is the only one that makes sense.

For 2.0.0, we probably have different views where we should go with it. At
this point, I've made substantial changes to core shiro classes to
streamline and extend it for Tapestry users and it'd be an interesting
experiment to converge back to the same baseline again. I know Guice and
other modern inversion-of-control frameworks are in the same camp; we could
simplify and reduce the shiro core quite a bit if we assumed Java based
dependency injection. There would be no need for a custom event bus or a
lot of other boiler plate setter code. Being able to implement a CDI SPI
opens up a lot of new possibilities. Not sure how well that aligns with
your plans though. Perhaps we can set some hard requirements first, what do
you see as the required JRE and Servlet spec versions for Shiro 2.0?

Kalle

--001a11c361fc2d4d2104dad7f351--