Continuum 1.1 roadmap

Hi,

I started to define the roadmap of continuum 1.1. It will be
done normally tomorrow.

The major first things to do in this roadmap are:

- Reimplementation of authentication/authorization
management (CONTINUUM-542 and CONTINUUM-513): 
this will be done by carlos with acegi. Carlos will
integrate acegi with plexus. This part must 
secure all requests in continuum and not only don't show
some part of the interface.

- Remove JDO (at least jpox) because it the source of lot of
our issues

- implementation of continuum profiles and installation
screens(CONTINUUM-44,CONTINUUM-59)

- integration of GBuild (CONTINUUM-563)

- implementation of project groups (CONTINUUM-30,
CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, 
CONTINUUM-292)

Other important things I'd want to see in it:

- customization of the add project feature. In this part, I
think to add a multi-project as a 
multiple projects or as a single project, scm connection
string to use, add with a scm url, add all 
modules by a scm connection instead of an url contruction
based on project url provided in the add 
screen

- build on dependencies changes

- add a tests result summary in build results

I'll add missing issues in jira tomorrow when I'll
continue the roadmap.

Emmanuel

On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel Venisse wrote:

> Hi,
>
> I started to define the roadmap of continuum 1.1. It
will be done  
> normally tomorrow.

Are we deciding that these are the things are going to be in
1.1 and  
take as long as we need? I would prefer that myself. Looking
below  
there I think that's a good list.

>
> The major first things to do in this roadmap are:
>
> - Reimplementation of authentication/authorization
management  
> (CONTINUUM-542 and CONTINUUM-513): this will be done by
carlos with  
> acegi. Carlos will integrate acegi with plexus. This
part must  
> secure all requests in continuum and not only don't
show some part  
> of the interface.
>

If a plexus component is made to integrate Acegi that's
cool. As long  
as Continuum itself has an abstraction for security and
Acegi is not  
coupled directly to Continuum that's fine.

> - Remove JDO (at least jpox) because it the source of
lot of our  
> issues
>

+1

> - implementation of continuum profiles and installation
screens 
> (CONTINUUM-44,CONTINUUM-59)
>

+1

> - integration of GBuild (CONTINUUM-563)
>

+1

> - implementation of project groups (CONTINUUM-30,  
> CONTINUUM-289,CONTINUUM-290, CONTINUUM-291,
CONTINUUM-292)
>

+1

> Other important things I'd want to see in it:
>
> - customization of the add project feature. In this
part, I think  
> to add a multi-project as a multiple projects or as a
single  
> project, scm connection string to use, add with a scm
url, add all  
> modules by a scm connection instead of an url
contruction based on  
> project url provided in the add screen
>

+1

> - build on dependencies changes
>

+1

> - add a tests result summary in build results
>

+1

> I'll add missing issues in jira tomorrow when I'll
continue the  
> roadmap.
>

Cool, thanks Emmanuel.

> Emmanuel
>
>

Jason van Zyl
jasonmaven.org

Jason van Zyl a écrit :
> 
> On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel Venisse
wrote:
> 
>> Hi,
>>
>> I started to define the roadmap of continuum 1.1.
It will be done 
>> normally tomorrow.
> 
> Are we deciding that these are the things are going to
be in 1.1 and 
> take as long as we need? I would prefer that myself.
Looking below there 
> I think that's a good list.

I'd prefer too, but depends of the time we spend on each
items. If we need lot of time on each 
items, perhaps we'll do an intermediate release.

> 
>>
>> The major first things to do in this roadmap are:
>>
>> - Reimplementation of authentication/authorization
management 
>> (CONTINUUM-542 and CONTINUUM-513): this will be
done by carlos with 
>> acegi. Carlos will integrate acegi with plexus.
This part must secure 
>> all requests in continuum and not only don't show
some part of the 
>> interface.
>>
> 
> If a plexus component is made to integrate Acegi
that's cool. As long as 
> Continuum itself has an abstraction for security and
Acegi is not 
> coupled directly to Continuum that's fine.

Normally, they won't be coupled. Carlos, can you add more
informations?

> 
>> - Remove JDO (at least jpox) because it the source
of lot of our issues
>>
> 
> +1
> 
>> - implementation of continuum profiles and
installation 
>> screens(CONTINUUM-44,CONTINUUM-59)
>>
> 
> +1
> 
>> - integration of GBuild (CONTINUUM-563)
>>
> 
> +1
> 
>> - implementation of project groups (CONTINUUM-30, 
>> CONTINUUM-289,CONTINUUM-290, CONTINUUM-291,
CONTINUUM-292)
>>
> 
> +1
> 
>> Other important things I'd want to see in it:
>>
>> - customization of the add project feature. In this
part, I think to 
>> add a multi-project as a multiple projects or as a
single project, scm 
>> connection string to use, add with a scm url, add
all modules by a scm 
>> connection instead of an url contruction based on
project url provided 
>> in the add screen
>>
> 
> +1
> 
>> - build on dependencies changes
>>
> 
> +1
> 
>> - add a tests result summary in build results
>>
> 
> +1
> 
>> I'll add missing issues in jira tomorrow when
I'll continue the roadmap.
>>
> 
> Cool, thanks Emmanuel.
> 
>> Emmanuel
>>
>>
> 
> Jason van Zyl
> jasonmaven.org
> 
> 
> 
> 
> 
> 

On 6/28/06, Emmanuel Venisse <emmanuelvenisse.net> wrote:
>
>
> Jason van Zyl a écrit :
> >
> > On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel
Venisse wrote:
> >
> >> Hi,
> >>
> >> I started to define the roadmap of continuum
1.1. It will be done
> >> normally tomorrow.
> >
> > Are we deciding that these are the things are
going to be in 1.1 and
> > take as long as we need? I would prefer that
myself. Looking below there
> > I think that's a good list.
>
> I'd prefer too, but depends of the time we spend on
each items. If we need lot of time on each
> items, perhaps we'll do an intermediate release.
>
> >
> >>
> >> The major first things to do in this roadmap
are:
> >>
> >> - Reimplementation of
authentication/authorization management
> >> (CONTINUUM-542 and CONTINUUM-513): this will
be done by carlos with
> >> acegi. Carlos will integrate acegi with
plexus. This part must secure
> >> all requests in continuum and not only don't
show some part of the
> >> interface.
> >>
> >
> > If a plexus component is made to integrate Acegi
that's cool. As long as
> > Continuum itself has an abstraction for security
and Acegi is not
> > coupled directly to Continuum that's fine.
>
> Normally, they won't be coupled. Carlos, can you add
more informations?


Acegi is coupled to some classes of Spring IoC to respond to
events
that we'll work around in some way with plexus. Everything
else
related to IoC is just wiring up objects, not tied to
Spring.

We'll need to get a minimal Spring jar with the classes
needed:
exceptions, utils,...


>
> >
> >> - Remove JDO (at least jpox) because it the
source of lot of our issues
> >>
> >
> > +1
> >
> >> - implementation of continuum profiles and
installation
> >> screens(CONTINUUM-44,CONTINUUM-59)
> >>
> >
> > +1
> >
> >> - integration of GBuild (CONTINUUM-563)
> >>
> >
> > +1
> >
> >> - implementation of project groups
(CONTINUUM-30,
> >> CONTINUUM-289,CONTINUUM-290, CONTINUUM-291,
CONTINUUM-292)
> >>
> >
> > +1
> >
> >> Other important things I'd want to see in it:
> >>
> >> - customization of the add project feature. In
this part, I think to
> >> add a multi-project as a multiple projects or
as a single project, scm
> >> connection string to use, add with a scm url,
add all modules by a scm
> >> connection instead of an url contruction based
on project url provided
> >> in the add screen
> >>
> >
> > +1
> >
> >> - build on dependencies changes
> >>
> >
> > +1
> >
> >> - add a tests result summary in build results
> >>
> >
> > +1
> >
> >> I'll add missing issues in jira tomorrow when
I'll continue the roadmap.
> >>
> >
> > Cool, thanks Emmanuel.
> >
> >> Emmanuel
> >>
> >>
> >
> > Jason van Zyl
> > jasonmaven.org
> >
> >
> >
> >
> >
> >
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

On 28 Jun 06, at 10:52 AM 28 Jun 06, Emmanuel Venisse wrote:

>
>
> Jason van Zyl a écrit :
>> On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel
Venisse wrote:
>>> Hi,
>>>
>>> I started to define the roadmap of continuum
1.1. It will be done  
>>> normally tomorrow.
>> Are we deciding that these are the things are going
to be in 1.1  
>> and take as long as we need? I would prefer that
myself. Looking  
>> below there I think that's a good list.
>
> I'd prefer too, but depends of the time we spend on
each items. If  
> we need lot of time on each items, perhaps we'll do an
intermediate  
> release.

I assume for this we are going to release a series of
alphas? How  
about for each major feature implemented we release an
alpha?

>
>>>
>>> The major first things to do in this roadmap
are:
>>>
>>> - Reimplementation of
authentication/authorization management  
>>> (CONTINUUM-542 and CONTINUUM-513): this will be
done by carlos  
>>> with acegi. Carlos will integrate acegi with
plexus. This part  
>>> must secure all requests in continuum and not
only don't show  
>>> some part of the interface.
>>>
>> If a plexus component is made to integrate Acegi
that's cool. As  
>> long as Continuum itself has an abstraction for
security and Acegi  
>> is not coupled directly to Continuum that's fine.
>
> Normally, they won't be coupled. Carlos, can you add
more  
> informations?

If the work is done in a branch we can just comment as the
work  
commences. I'm sure I won't find the time but I would
still like to  
try SASS which Patrick has been working on if I can.

>
>>> - Remove JDO (at least jpox) because it the
source of lot of our  
>>> issues
>>>
>> +1
>>> - implementation of continuum profiles and
installation screens 
>>> (CONTINUUM-44,CONTINUUM-59)
>>>
>> +1
>>> - integration of GBuild (CONTINUUM-563)
>>>
>> +1
>>> - implementation of project groups
(CONTINUUM-30,  
>>> CONTINUUM-289,CONTINUUM-290, CONTINUUM-291,
CONTINUUM-292)
>>>
>> +1
>>> Other important things I'd want to see in it:
>>>
>>> - customization of the add project feature. In
this part, I think  
>>> to add a multi-project as a multiple projects
or as a single  
>>> project, scm connection string to use, add with
a scm url, add  
>>> all modules by a scm connection instead of an
url contruction  
>>> based on project url provided in the add screen
>>>
>> +1
>>> - build on dependencies changes
>>>
>> +1
>>> - add a tests result summary in build results
>>>
>> +1
>>> I'll add missing issues in jira tomorrow when
I'll continue the  
>>> roadmap.
>>>
>> Cool, thanks Emmanuel.
>>> Emmanuel
>>>
>>>
>> Jason van Zyl
>> jasonmaven.org
>
>

Jason van Zyl
jasonmaven.org

On 28/06/2006 8:01 PM, Jason van Zyl wrote:
> I assume for this we are going to release a series of
alphas? How about 
> for each major feature implemented we release an alpha?

When we last discussed it on the development process, we
talked about 
instead doing regular promotion of the automated builds (eg,
roughly 
once a week we say "this is a stable build with
something new/a good 
fix/etc, let's ask people to test it").

I'd really like to try that (and add anything to continuum
to make it 
easier 

> If the work is done in a branch we can just comment as
the work 
> commences. I'm sure I won't find the time but I would
still like to try 
> SASS which Patrick has been working on if I can.

Carlos' work is on trunk now and he seems committed to
getting it 
started next week, so maybe the best thing is for him to
work on trunk 
and doing sass on a branch if it's just going to be a spare
time thing?

>>>> - Remove JDO (at least jpox) because it the
source of lot of our issues
>>>>
>>> +1

My only opinion on this is to think about it, but save the
work until we 
bump into the next big problem that is going to require a
lot of effort 
to fix. It seems stable enough in 1.0.3 and if it remains
that way 
through 1.1 it can buy us some time.

I'm interested in seeing how JPA progresses as a
replacement for this 
(even if it requires Java 5, which it would be nice to move
to anyway  
There should be a better choice of implementations and the
API is 
similar I think.

It's a shame we're having so many problems, as the jdo api
is actually 
quite nice.

BTW, have we done much trials with databases other than
hsqldb and 
derby? Maybe the problem isn't JDO 

>>>> - customization of the add project feature.
In this part, I think to 
>>>> add a multi-project as a multiple projects
or as a single project, 
>>>> scm connection string to use, add with a
scm url, add all modules by 
>>>> a scm connection instead of an url
contruction based on project url 
>>>> provided in the add screen

Absolutely. We should talk through this one a bit more, as
maybe the 
solution is to have it better understand module
relationships. This also 
relates to something I'd like to see happen where we have
the checkout 
in the normal layout instead of isolated directories (to
avoid checking 
out the modules twice - once in the parent and once for each
module).

- Brett

-- 
Brett Porter <brettapache.org>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.co
m/

On 28 Jun 06, at 11:25 AM 28 Jun 06, Brett Porter wrote:

> On 28/06/2006 8:01 PM, Jason van Zyl wrote:
>> I assume for this we are going to release a series
of alphas? How  
>> about for each major feature implemented we release
an alpha?
>
> When we last discussed it on the development process,
we talked  
> about instead doing regular promotion of the automated
builds (eg,  
> roughly once a week we say "this is a stable
build with something  
> new/a good fix/etc, let's ask people to test
it").
>
> I'd really like to try that (and add anything to
continuum to make  
> it easier 

Yes, but we still have to make some official public
releases. I don't  
think we can just release Continuum generated builds and
then just  
release 1.1? Or do I misunderstand what you're talking
about.

>
>> If the work is done in a branch we can just comment
as the work  
>> commences. I'm sure I won't find the time but I
would still like  
>> to try SASS which Patrick has been working on if I
can.
>
> Carlos' work is on trunk now and he seems committed to
getting it  
> started next week, so maybe the best thing is for him
to work on  
> trunk and doing sass on a branch if it's just going to
be a spare  
> time thing?

No, I would prefer them both to be done on the branch. I'm
honestly  
+0 on using Acegi and I want to see fully how it might be
done before  
passing judgement but I don't want it on the trunk as I
honestly feel  
that it's just so complicated. Carlos will have to show
it's not and  
that's just as easy to do on a branch.

>
>>>>> - Remove JDO (at least jpox) because it
the source of lot of  
>>>>> our issues
>>>>>
>>>> +1
>
> My only opinion on this is to think about it, but save
the work  
> until we bump into the next big problem that is going
to require a  
> lot of effort to fix. It seems stable enough in 1.0.3
and if it  
> remains that way through 1.1 it can buy us some time.
>
> I'm interested in seeing how JPA progresses as a
replacement for  
> this (even if it requires Java 5, which it would be
nice to move to  
> anyway  There
should be a better choice of implementations and  
> the API is similar I think.
>
> It's a shame we're having so many problems, as the
jdo api is  
> actually quite nice.
>
> BTW, have we done much trials with databases other than
hsqldb and  
> derby? Maybe the problem isn't JDO 
>
>>>>> - customization of the add project
feature. In this part, I  
>>>>> think to add a multi-project as a
multiple projects or as a  
>>>>> single project, scm connection string
to use, add with a scm  
>>>>> url, add all modules by a scm
connection instead of an url  
>>>>> contruction based on project url
provided in the add screen
>
> Absolutely. We should talk through this one a bit more,
as maybe  
> the solution is to have it better understand module
relationships.  
> This also relates to something I'd like to see happen
where we have  
> the checkout in the normal layout instead of isolated
directories  
> (to avoid checking out the modules twice - once in the
parent and  
> once for each module).
>
> - Brett
>
> -- 
> Brett Porter <brettapache.org>
> Apache Maven - http://maven.apache.org/
> Better Builds with Maven - http://library.mergere.co
m/
>

Jason van Zyl
jasonmaven.org

>>>>> - Remove JDO (at least jpox) because it
the source of lot of our 
>>>>> issues
>>>>>
>>>> +1
> 
> My only opinion on this is to think about it, but save
the work until we 
> bump into the next big problem that is going to require
a lot of effort 
> to fix. It seems stable enough in 1.0.3 and if it
remains that way 
> through 1.1 it can buy us some time.
> 
> I'm interested in seeing how JPA progresses as a
replacement for this 
> (even if it requires Java 5, which it would be nice to
move to anyway  
> There should be a better choice of implementations and
the API is 
> similar I think.
> 
> It's a shame we're having so many problems, as the
jdo api is actually 
> quite nice.
> 
> BTW, have we done much trials with databases other than
hsqldb and 
> derby? Maybe the problem isn't JDO 
> 
I open an issue for the replacement of it (CONTINUUM-740).
Actually, it's planned for 1.1 and we'll 
can move it to another version if we think it isn't
necessary to spend lot of time on it.

Some users use Continuum with posgres, mysql or mssql and I
don't know if they have issues (except 
for database schema).

Emmanuel

ok, I think the roadmap is done now. We have 159 issues.

I'll be happy if we can include all these issues in 1.1


Emmanuel

Emmanuel Venisse a écrit :
> Hi,
> 
> I started to define the roadmap of continuum 1.1. It
will be done 
> normally tomorrow.
> 
> The major first things to do in this roadmap are:
> 
> - Reimplementation of authentication/authorization
management 
> (CONTINUUM-542 and CONTINUUM-513): this will be done by
carlos with 
> acegi. Carlos will integrate acegi with plexus. This
part must secure 
> all requests in continuum and not only don't show some
part of the 
> interface.
> 
> - Remove JDO (at least jpox) because it the source of
lot of our issues
> 
> - implementation of continuum profiles and installation

> screens(CONTINUUM-44,CONTINUUM-59)
> 
> - integration of GBuild (CONTINUUM-563)
> 
> - implementation of project groups (CONTINUUM-30, 
> CONTINUUM-289,CONTINUUM-290, CONTINUUM-291,
CONTINUUM-292)
> 
> Other important things I'd want to see in it:
> 
> - customization of the add project feature. In this
part, I think to add 
> a multi-project as a multiple projects or as a single
project, scm 
> connection string to use, add with a scm url, add all
modules by a scm 
> connection instead of an url contruction based on
project url provided 
> in the add screen
> 
> - build on dependencies changes
> 
> - add a tests result summary in build results
> 
> I'll add missing issues in jira tomorrow when I'll
continue the roadmap.
> 
> Emmanuel
> 
> 
> 
> 

>>>>> - customization of the add project
feature. In this part, I think 
>>>>> to add a multi-project as a multiple
projects or as a single 
>>>>> project, scm connection string to use,
add with a scm url, add all 
>>>>> modules by a scm connection instead of
an url contruction based on 
>>>>> project url provided in the add screen
> 
> Absolutely. We should talk through this one a bit more,
as maybe the 
> solution is to have it better understand module
relationships. This also 
> relates to something I'd like to see happen where we
have the checkout 
> in the normal layout instead of isolated directories
(to avoid checking 
> out the modules twice - once in the parent and once for
each module).
> 

I created a new issue (CONTINUUM-741)

Emmanuel