Preparing for 1.0

[Jukka Zitting <ju...@zitting.name>]

Hi,

The JCR API has been final for a few months now and there is clearly much
interest for the Jackrabbit 1.0 release. I propose that we start preparing for
the release and set an informal goal of having the release ready within the
next few months. To set things rolling I suggest that we appoint a release
manager and start the discussion on what should be included in the 1.0 release.

The 1.0 roadmap I set up at Jira some while ago has been shaping up quite well
lately, but unfortunately it just keeps growing as long as a feature freeze for
1.0 is not announced. I just added version labels 1.0.1 and 1.1 to Jira to allow
proper tagging of issues that might not make it for the 1.0 release.

Based on recent discussions and the current Jira issue list it seems that threre
are three main issues to be solved before the 1.0 release (please correct me if
I'm forgetting something essential):

    1. Solve the versioning problems with threading and transactions
    2. Write the installation manual and other basic documentation
    3. Decide which contrib components to include in the release

After appointing the release manager and having a rough consensus on what the
1.0 release should contain, I propose that we make a beta release fairly
quickly (or first an alpha if blocker issues are still open) and allow enough
time for people to try it out and report back any problems before the final
release.

I'm not too familiar with the Apache release procedures, so comments from
someone with more experience would be nice. I'm also not sure of how the
release might be related to graduation from the Incubator.

BR,

Jukka Zitting

Re: Preparing for 1.0

[Marcel Reutegger <ma...@gmail.com>]

Jukka Zitting wrote:
> Another subject to discuss before the 1.0 release is the contents and 
> structure
> of the distribution package. I think the Maven dist goal is a good place to
> start, but what else than the Jackrabbit jar and docs would we want to 
> include
> in the package?
> 
> Edgar already touched this issue in his comment to JCR-227 [1], 
> suggesting that
> we include all the dependencies and modules and add jcr-server scripts for
> running Jackrabbit in server mode. I kind of like this idea, with 
> instructions
> for using just the Jackrabbit jar and dependency libs if you want to run a
> content repository embedded in a container or a standalone application.

I'd like to see two deployments of Jackrabbit:

1) Jackrabbit with all its features and options: rmi, webdav server,
textfilters, etc.

2) Jackrabbit embedded running with just the basics. The goal here
should be to provide a quick and easy way to get started.

The next point is a bit off topic. Equally important to how we package
Jackrabbit is the question what kind of examples we want to provide. IMO
it is very important to include a sample (web-)application that shows
the features and stengths of a content repository. Any ideas on that?

regards
   marcel

Re: Preparing for 1.0

[Jukka Zitting <ju...@zitting.name>]

Hi,

Another subject to discuss before the 1.0 release is the contents and 
structure
of the distribution package. I think the Maven dist goal is a good place to
start, but what else than the Jackrabbit jar and docs would we want to include
in the package?

Edgar already touched this issue in his comment to JCR-227 [1], 
suggesting that
we include all the dependencies and modules and add jcr-server scripts for
running Jackrabbit in server mode. I kind of like this idea, with instructions
for using just the Jackrabbit jar and dependency libs if you want to run a
content repository embedded in a container or a standalone application.

[1] http://issues.apache.org/jira/browse/JCR-227#action_12331599

What do you think? I could setup Maven rules for building such a dist package
and start doing unofficial nightly builds to try out the package structure.

BR,

Jukka Zitting

Re: Preparing for 1.0

[Alexandru Popescu <th...@gmail.com>]

#: Edgar Poce changed the world a bit at a time by saying on  9/30/2005 3:45 AM :#
> hi Alexandru
> 
> Alexandru Popescu wrote:
>> #: Jukka Zitting changed the world a bit at a time by saying on  
>> I am not aware of who are the authors of contrib `modules´
> why would it matter?, AFAIK all the code in the asf is under the ASF 
> license and in can be released at any moment in those terms.
> 

I was not talking about licensing issues ;-). It is a matter of quality and release cycles. Take for 
example Spring, Wicket and many others that decided the modules to have their separate life cycle of 
this 2 reasons: maintainer and quality.

./alex
--
.w( the_mindstorm )p.

> br,
> edgar
> 

Re: Preparing for 1.0

[Edgar Poce <ed...@gmail.com>]

hi Alexandru

Alexandru Popescu wrote:
> #: Jukka Zitting changed the world a bit at a time by saying on  
> I am not aware of who are the authors of contrib `modules´
why would it matter?, AFAIK all the code in the asf is under the ASF 
license and in can be released at any moment in those terms.

br,
edgar

Re: Preparing for 1.0

[Alexandru Popescu <th...@gmail.com>]

#: Jukka Zitting changed the world a bit at a time by saying on  9/30/2005 2:17 AM :#
> Hi,
> [...]
>     3. Decide which contrib components to include in the release
> 

I am not aware of who are the authors of contrib `modules´, but my approach would be:

1/ if the core jackrabbit developers are the owners of those modules, than they should be raised to 
the level of jackrabbit. Another thing that must be considered is if they will have the same release 
cycles as the core.

2/ if somebody else is the author, than separate them completely and make them have their own 
release cycles


just my .2c

./alex
--
.w( the_mindstorm )p.

Re: Preparing for 1.0

[Jukka Zitting <ju...@zitting.name>]

Hi,

Edgar Poce wrote:
> On 10/7/05, Jukka Zitting <ju...@zitting.name> wrote:
>> Some of the contribs (like db-persistence and
>> textfilters) wouldn't even need their own module directories as they 
>> should be fully integrated with Jackrabbit.
>
> In order to keep jackrabbit lightweighted I'd rather put them in a
> separate directory. Textfilters would include many dependencies only
> useful for those who need to index binary formats.

I don't have a strong preference about this, so having textfilters as an
optional module is OK with me. I was just thinking about the installation
manual I've been drafting. From that perspective it would be somewhat nicer to
have support for indexing the main binary formats built-in rather than as an
additional deployment option.

BR,

Jukka Zitting

Re: Preparing for 1.0

[Edgar Poce <ed...@gmail.com>]

Hi jukka

On 10/7/05, Jukka Zitting <ju...@zitting.name> wrote:
> Some of the contribs (like db-persistence and
> textfilters) wouldn't even need their own module directories as they should be
> fully integrated with Jackrabbit.

In order to keep jackrabbit lightweighted I'd rather put them in a
separate directory. Textfilters would include many dependencies only
useful for those who need to index binary formats.

br,
edgar

Re: Preparing for 1.0

[Jukka Zitting <ju...@zitting.name>]

Hi,

Edgar Poce wrote:
> Regarding the contrib projects I think that the first thing to do is 
> to rename the folder to sandbox and promote the candidates to be 
> included in the release, I think that jcr-rmi and textfilters should 
> be included.

Agreed. In addition to jcr-rmi and textfilters I think we should consider also
the jdbc pm, the jca connector, the webdav layer and jcr-server.

> We could also update the site and svn tree to something like
> /jackrabbit (or ri or impl)
> /subprojects (or ???)
> /sandbox
> If there's consensus I volunteer to play with the multiproject maven 
> plugin and try to get a nice site out of it.

After experimenting with multiproject in the summer I believe it would 
be easier
and cleaner to work with one main project and use subprojects only when
necessary. It seems like the multiproject model makes best sense for projects
like Maven that contain a large number of independent components that share a
common code and documentation layout.

I'd also prefer having all the released stuff contained in one 
directory so that
it'll be easy and clean to eventually just copy that into the JACKRABBIT_1_0
tag. We should therefore probably move the graduated contrib projects to the
existing modules directory. Some of the contribs (like db-persistence and
textfilters) wouldn't even need their own module directories as they should be
fully integrated with Jackrabbit. Other modules could either keep their
separate source trees or get their code moved within the main source tree and
use a mechanism like the commons module to optionally build an independent jar
artifact.

BR,

Jukka Zitting

Re: Preparing for 1.0

[Edgar Poce <ed...@gmail.com>]

hi

Jukka Zitting wrote:
> The 1.0 roadmap I set up at Jira some while ago has been shaping up quite well
> lately, but unfortunately it just keeps growing as long as a feature freeze for
> 1.0 is not announced. I just added version labels 1.0.1 and 1.1 to Jira to allow
> proper tagging of issues that might not make it for the 1.0 release.
good idea

> Based on recent discussions and the current Jira issue list it seems that threre
> are three main issues to be solved before the 1.0 release (please correct me if
> I'm forgetting something essential):
> 
>     1. Solve the versioning problems with threading and transactions
>     2. Write the installation manual and other basic documentation
>     3. Decide which contrib components to include in the release
> 
I think the only blocker is the versioning issue, see below. Regarding 
the contrib projects I think that the first thing to do is to rename the 
folder to sandbox and promote the candidates to be included in the 
release, I think that jcr-rmi and textfilters should be included. We 
could also update the site and svn tree to something like
/jackrabbit (or ri or impl)
/subprojects (or ???)
/sandbox
If there's consensus I volunteer to play with the multiproject maven 
plugin and try to get a nice site out of it.

> After appointing the release manager and having a rough consensus on what the
> 1.0 release should contain, I propose that we make a beta release fairly
> quickly (or first an alpha if blocker issues are still open) and allow enough
> time for people to try it out and report back any problems before the final
> release.
> 
hmm..., I don't think it's a good idea to release anything if there are 
blocker issues, i.e. versioning issues. I've been a user of apache 
products for many years mainly because of the high standards of its 
products. Many times I didn't read the release notes and I used beta 
projects in production without major problems, at least that I'm aware 
of, so I'm happy anyway ;). From a user perspective I wouldn't like to 
download a released project from apache which has known major bugs, it 
would hurt a long time relationship ;).

br,
edgar

> 
> BR,
> 
> Jukka Zitting
>