You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2007/08/08 09:33:24 UTC
Better Jira components
Hi,
I'd like to streamline the Jackrabbit components in Jira (currently
core, xml, query, etc.) to better match the project structure in svn.
This would help us better track changes per release artifact.
See below for a proposed restructuring of the Jira components. In
short this change would lessen the categorization metadata on
jackrabbit-core issues but increase metadata on other components. If
we want to keep the finer granularity, we could use an prefix
mechanism like core:query, core:xml, etc.
BR,
Jukka Zitting
----
contrib
contrib PMs
jackrabbit-api
Jackrabbit API
jackrabbit-classloader
jackrabbit-core
clustering
config
core
locks
xml
xpath
namespace
nodetype
observation
query
security
sql
transactions
versioning
jackrabbit-jca
jca
jackrabbit-jcr-commons
jackrabbit-jcr-rmi
rmi
jackrabbit-jcr-server
jackrabbit-jcr-servlet
jackrabbit-jcr-tests
test
JCR TCK
jackrabbit-site
docs
site
jackrabbit-text-extractors
indexing
jackrabbit-webapp
webapp
jackrabbit-webdav
webdav
There are also a few generic and not yet released components that I
haven't yet figured how to best handle:
JCR 1.0.1
JCR 2.0
JCR API
jcr-mapping
jira
maven
SPI
Re: Better Jira components
Posted by Christophe Lombart <ch...@gmail.com>.
Why not for the jcr-mapping somerthing like :
jcr-mapping
ocm
nodetype-management
annotation
spring
On 8/8/07, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> I'd like to streamline the Jackrabbit components in Jira (currently
> core, xml, query, etc.) to better match the project structure in svn.
> This would help us better track changes per release artifact.
>
> See below for a proposed restructuring of the Jira components. In
> short this change would lessen the categorization metadata on
> jackrabbit-core issues but increase metadata on other components. If
> we want to keep the finer granularity, we could use an prefix
> mechanism like core:query, core:xml, etc.
>
> BR,
>
> Jukka Zitting
>
> ----
>
> contrib
> contrib PMs
>
> jackrabbit-api
> Jackrabbit API
>
> jackrabbit-classloader
>
> jackrabbit-core
> clustering
> config
> core
> locks
> xml
> xpath
> namespace
> nodetype
> observation
> query
> security
> sql
> transactions
> versioning
>
> jackrabbit-jca
> jca
>
> jackrabbit-jcr-commons
>
> jackrabbit-jcr-rmi
> rmi
>
> jackrabbit-jcr-server
>
> jackrabbit-jcr-servlet
>
> jackrabbit-jcr-tests
> test
> JCR TCK
>
> jackrabbit-site
> docs
> site
>
> jackrabbit-text-extractors
> indexing
>
> jackrabbit-webapp
> webapp
>
> jackrabbit-webdav
> webdav
>
> There are also a few generic and not yet released components that I
> haven't yet figured how to best handle:
>
> JCR 1.0.1
> JCR 2.0
> JCR API
> jcr-mapping
> jira
> maven
> SPI
>
Re: Better Jira components
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/8/07, Padraic Hannon <pi...@wasabicowboy.com> wrote:
> Managing releases that span multiple projects does tend to be a pain in
> Jira as the version field is specific to a project. This means you
> cannot query for all tasks for a release across multiple projects unless
> you create a separate release field (at least that has been our
> experience here at Edmunds).
The idea of splitting the Jackrabbit into multiple Jira projects would
be tied to starting independent release cycles for each subproject
that is big enough to warrant it's own Jira project. This way we would
keep a simple mapping between releases and Jira projects.
BR,
Jukka Zitting
Re: Better Jira components
Posted by Padraic Hannon <pi...@wasabicowboy.com>.
Managing releases that span multiple projects does tend to be a pain in
Jira as the version field is specific to a project. This means you
cannot query for all tasks for a release across multiple projects unless
you create a separate release field (at least that has been our
experience here at Edmunds).
-paddy
Jukka Zitting wrote:
> Hi,
>
> On 8/8/07, Stefan Guggisberg <st...@gmail.com> wrote:
>
>> i'd definitely like to keep the finer granularity in core.
>> ideally there should be something like subcomponents
>> but prefixing would be fine with me.
>>
>
> Eventually (perhaps starting with Jackrabbit 2.0) we may want to start
> having separate release cycles for the different subprojects, which
> means that we would also have separate Jira projects and components
> for each Jackrabbit subproject. There's some overhead to doing that,
> so I'd like to do that only when the pain of doing synchronous
> releases (like nobody being able to review too big release candidates)
> gets too big.
>
> BR,
>
> Jukka Zitting
>
Re: Better Jira components
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/8/07, Stefan Guggisberg <st...@gmail.com> wrote:
> i'd definitely like to keep the finer granularity in core.
> ideally there should be something like subcomponents
> but prefixing would be fine with me.
Eventually (perhaps starting with Jackrabbit 2.0) we may want to start
having separate release cycles for the different subprojects, which
means that we would also have separate Jira projects and components
for each Jackrabbit subproject. There's some overhead to doing that,
so I'd like to do that only when the pain of doing synchronous
releases (like nobody being able to review too big release candidates)
gets too big.
BR,
Jukka Zitting
Re: Better Jira components
Posted by Stefan Guggisberg <st...@gmail.com>.
hi jukka
On 8/8/07, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> I'd like to streamline the Jackrabbit components in Jira (currently
> core, xml, query, etc.) to better match the project structure in svn.
> This would help us better track changes per release artifact.
>
> See below for a proposed restructuring of the Jira components. In
> short this change would lessen the categorization metadata on
> jackrabbit-core issues but increase metadata on other components. If
> we want to keep the finer granularity, we could use an prefix
> mechanism like core:query, core:xml, etc.
i'd definitely like to keep the finer granularity in core.
ideally there should be something like subcomponents
but prefixing would be fine with me.
cheers
stefan
>
> BR,
>
> Jukka Zitting
>
> ----
>
> contrib
> contrib PMs
>
> jackrabbit-api
> Jackrabbit API
>
> jackrabbit-classloader
>
> jackrabbit-core
> clustering
> config
> core
> locks
> xml
> xpath
> namespace
> nodetype
> observation
> query
> security
> sql
> transactions
> versioning
>
> jackrabbit-jca
> jca
>
> jackrabbit-jcr-commons
>
> jackrabbit-jcr-rmi
> rmi
>
> jackrabbit-jcr-server
>
> jackrabbit-jcr-servlet
>
> jackrabbit-jcr-tests
> test
> JCR TCK
>
> jackrabbit-site
> docs
> site
>
> jackrabbit-text-extractors
> indexing
>
> jackrabbit-webapp
> webapp
>
> jackrabbit-webdav
> webdav
>
> There are also a few generic and not yet released components that I
> haven't yet figured how to best handle:
>
> JCR 1.0.1
> JCR 2.0
> JCR API
> jcr-mapping
> jira
> maven
> SPI
>
Re: Better Jira components
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Jukka,
Makes sense (incl. Christophe's comments).
Am Mittwoch, den 08.08.2007, 10:33 +0300 schrieb Jukka Zitting:
> Hi,
>
> I'd like to streamline the Jackrabbit components in Jira (currently
> core, xml, query, etc.) to better match the project structure in svn.
> This would help us better track changes per release artifact.
>
> See below for a proposed restructuring of the Jira components. In
> short this change would lessen the categorization metadata on
> jackrabbit-core issues but increase metadata on other components. If
> we want to keep the finer granularity, we could use an prefix
> mechanism like core:query, core:xml, etc.
>
> BR,
>
> Jukka Zitting
>
> ----
>
> contrib
> contrib PMs
>
> jackrabbit-api
> Jackrabbit API
>
> jackrabbit-classloader
>
> jackrabbit-core
> clustering
> config
> core
> locks
> xml
> xpath
> namespace
> nodetype
> observation
> query
> security
> sql
> transactions
> versioning
>
> jackrabbit-jca
> jca
>
> jackrabbit-jcr-commons
>
> jackrabbit-jcr-rmi
> rmi
>
> jackrabbit-jcr-server
>
> jackrabbit-jcr-servlet
>
> jackrabbit-jcr-tests
> test
> JCR TCK
>
> jackrabbit-site
> docs
> site
>
> jackrabbit-text-extractors
> indexing
>
> jackrabbit-webapp
> webapp
>
> jackrabbit-webdav
> webdav
>
> There are also a few generic and not yet released components that I
> haven't yet figured how to best handle:
>
> JCR 1.0.1
> JCR 2.0
> JCR API
> jcr-mapping
> jira
> maven
> SPI