Continuum 1.2 Roadmap

[Emmanuel Venisse]

Hi,

We are near the end of 1.1, it's time to discuss of 1.2 roadmap :)

For this new version, my vision is:

- Rewrite all the UI with a full GWT site. I want to migrate to GWT
because we need better performance on the UI even if it is correct now.
The second point is that with GWT (and Ajax in general)
we'll can add nice features (maybe not in 1.2) to users like auto-refresh
of small part of pages, users spaces, dynamic chart... And the last point
of the GWT choice is all the code is written in java
with a verification of all parts by the compiler (properties undeclared or
unused, css style doesn't exist,...) so we'll reduce typo errors that we
got sometimes.

- Externalization of all the configuration. In this version, I want to
move all the conf that is actually embedded in application.xml to a file
more visible by the user. We can use plexus-registry for
this.

- Better support of XML-RPC and other remote access (XFire, ...). For this
point, I think it would be good to share the code with the GWT part with
some services classes that will embed all the
"remote" code with security checks

- Better support of maven projects. Actually, we detect if a build is
required by looking at scm changes and dependencies changes. The problem
is in dependencies changes. We look only at dependencies
that are a continuum project too, it would be good to check repositories
to find if a new version exists like maven do it. An other problem with
dependencies changes is we don't really check if a new
version exists but only if a new build result was created, it's a problem
in case of projects with more than one build definition (for example
"clean install" and "site"). If a site is generated, a
new build result is created and continuum consider it as a dependency
change so it rebuild all dependent projects in the next step.

About GWT, I found few guys (6) that want to spend some time to do the
migration and investigate on some new UI features.

This roadmap is short because I don't want to wait a new time a long wait
before to release a new 1.x version and I'd like to attract new users. I'd
like to release 1.2 betfore the end of the year.

I'll send a new mail in few weeks about 2.0 roadmap that will require more
work.

wdyt?

Emmanuel

[Wendy Smoak-3]

On 10/3/07, Emmanuel Venisse <emmanuel@...> wrote:

> We are near the end of 1.1, it's time to discuss of 1.2 roadmap :)
>
> For this new version, my vision is:

Sounds good in general.

I'm not thrilled with GWT-- I'm suspicious of code generation-- but
since I'm not doing the work I'm not going to complain (too much)
(until it breaks).

If you're going to completely change the UI, then this is going to
feel like a "2.0" even if not much changes behind the scenes
functionality wise.

We've talked about Continuum being distributed-- having a master
server that farms out builds to others, or at least consolidates the
build results from all of the others.  That might be something for 2.0
(or 3.0, see above. :) though ).

Thanks!
--
Wendy

[Emmanuel Venisse]

> On 10/3/07, Emmanuel Venisse <emmanuel@...> wrote:
>
>> We are near the end of 1.1, it's time to discuss of 1.2 roadmap :)
>>
>> For this new version, my vision is:
>
> Sounds good in general.
>
> I'm not thrilled with GWT-- I'm suspicious of code generation-- but
> since I'm not doing the work I'm not going to complain (too much)
> (until it breaks).

GWT seems to be good and easy to use. All GWT users I met don't want to
change now and they work on some very big applications

>
> If you're going to completely change the UI, then this is going to
> feel like a "2.0" even if not much changes behind the scenes
> functionality wise.

I don't think to change completely the UI in 1.2, only the web framework
and some new UI features but pages will be approximatively the same we
have actually.

Big UI changes will be for 2.0, if we need to do big changes.

>
> We've talked about Continuum being distributed-- having a master
> server that farms out builds to others, or at least consolidates the
> build results from all of the others.  That might be something for 2.0
> (or 3.0, see above. :) though ).

About the consolidation/dashboard, maybe we'll can add it in 1.2 but I
don't think. But I'm sure distributed builds will be in 2.0, we'll can't
wait 3.0 ;)

Emmanuel

[Christian Edward Gruber-2]

Heh.  Not going to happen, but I'd recommend going with Tapestry 5.  
It's beautiful, and a much healthier model of development than JSP/
Struts/Struts2/etc. in my own view.

It's also a work in progress (the 5 branch) but it's so much cleaner  
and more elegant than so much out there, and they're currently  
discussing decoupling the javascript stuff so that components would  
delegate the JS/AJAX to your framework of choice (to avoid JS lock-in  
the way a lot of JSF frameworks do it).

Anyway, just throwing things at the wall to see what sticks. ;)

Christian

On 3-Oct-07, at 4:04 PM, Emmanuel Venisse wrote:

> Hi,
>
> We are near the end of 1.1, it's time to discuss of 1.2 roadmap :)
>
> For this new version, my vision is:
>
> - Rewrite all the UI with a full GWT site. I want to migrate to GWT
> because we need better performance on the UI even if it is correct  
> now.
> The second point is that with GWT (and Ajax in general)
> we'll can add nice features (maybe not in 1.2) to users like auto-
> refresh
> of small part of pages, users spaces, dynamic chart... And the last  
> point
> of the GWT choice is all the code is written in java
> with a verification of all parts by the compiler (properties  
> undeclared or
> unused, css style doesn't exist,...) so we'll reduce typo errors  
> that we
> got sometimes.
>
> - Externalization of all the configuration. In this version, I want to
> move all the conf that is actually embedded in application.xml to a  
> file
> more visible by the user. We can use plexus-registry for
> this.
>
> - Better support of XML-RPC and other remote access (XFire, ...).  
> For this
> point, I think it would be good to share the code with the GWT part  
> with
> some services classes that will embed all the
> "remote" code with security checks
>
> - Better support of maven projects. Actually, we detect if a build is
> required by looking at scm changes and dependencies changes. The  
> problem
> is in dependencies changes. We look only at dependencies
> that are a continuum project too, it would be good to check  
> repositories
> to find if a new version exists like maven do it. An other problem  
> with
> dependencies changes is we don't really check if a new
> version exists but only if a new build result was created, it's a  
> problem
> in case of projects with more than one build definition (for example
> "clean install" and "site"). If a site is generated, a
> new build result is created and continuum consider it as a dependency
> change so it rebuild all dependent projects in the next step.
>
> About GWT, I found few guys (6) that want to spend some time to do the
> migration and investigate on some new UI features.
>
> This roadmap is short because I don't want to wait a new time a long  
> wait
> before to release a new 1.x version and I'd like to attract new  
> users. I'd
> like to release 1.2 betfore the end of the year.
>
> I'll send a new mail in few weeks about 2.0 roadmap that will  
> require more
> work.
>
> wdyt?
>
> Emmanuel
>
>
>
>
>

[Christophe Lechenne-2]

Slt Emmanuel,

Vous commencez quand  la version 1.2 ?
Comment vous répartissez-vous la tâche ?
Y-a-t-il un ptit morceau de l'UI en GWT ?

Si tu cherches des mains, je suis ton homme.

a+

2007/10/3, Emmanuel Venisse <emmanuel@...>:

>
> Hi,
>
> We are near the end of 1.1, it's time to discuss of 1.2 roadmap :)
>
> For this new version, my vision is:
>
> - Rewrite all the UI with a full GWT site. I want to migrate to GWT
> because we need better performance on the UI even if it is correct now.
> The second point is that with GWT (and Ajax in general)
> we'll can add nice features (maybe not in 1.2) to users like auto-refresh
> of small part of pages, users spaces, dynamic chart... And the last point
> of the GWT choice is all the code is written in java
> with a verification of all parts by the compiler (properties undeclared or
> unused, css style doesn't exist,...) so we'll reduce typo errors that we
> got sometimes.
>
> - Externalization of all the configuration. In this version, I want to
> move all the conf that is actually embedded in application.xml to a file
> more visible by the user. We can use plexus-registry for
> this.
>
> - Better support of XML-RPC and other remote access (XFire, ...). For this
> point, I think it would be good to share the code with the GWT part with
> some services classes that will embed all the
> "remote" code with security checks
>
> - Better support of maven projects. Actually, we detect if a build is
> required by looking at scm changes and dependencies changes. The problem
> is in dependencies changes. We look only at dependencies
> that are a continuum project too, it would be good to check repositories
> to find if a new version exists like maven do it. An other problem with
> dependencies changes is we don't really check if a new
> version exists but only if a new build result was created, it's a problem
> in case of projects with more than one build definition (for example
> "clean install" and "site"). If a site is generated, a
> new build result is created and continuum consider it as a dependency
> change so it rebuild all dependent projects in the next step.
>
> About GWT, I found few guys (6) that want to spend some time to do the
> migration and investigate on some new UI features.
>
> This roadmap is short because I don't want to wait a new time a long wait
> before to release a new 1.x version and I'd like to attract new users. I'd
> like to release 1.2 betfore the end of the year.
>
> I'll send a new mail in few weeks about 2.0 roadmap that will require more
> work.
>
> wdyt?
>
> Emmanuel
>
>
>
>
>
>

[olamy-2]

Hi,
Inline

2007/10/3, Emmanuel Venisse <emmanuel@...>:

>Hi,
>We are near the end of 1.1, it's time to discuss of 1.2 roadmap :)
>
>For this new version, my vision is:
>
>- Rewrite all the UI with a full GWT site. I want to migrate to GWT
>because we need better performance on the UI even if it is correct now.
>The second point is that with GWT (and Ajax in general)
>we'll can add nice features (maybe not in 1.2) to users like auto-refresh
>of small part of pages, users spaces, dynamic chart... And the last point>
>of the GWT choice is all the code is written in java>
>with a verification of all parts by the compiler (properties undeclared or>
>unused, css style doesn't exist,...) so we'll reduce typo errors that we
>got sometimes.

GWT looks fun (even if the webapp part is now enough fast) (IMHO the ui part
is not the most important it's just marketing :-))
We can already use ajax with Ajax./*Periodical*/Updater which is included in
prototype and easy to use.

>- Externalization of all the configuration. In this version, I want to
>move all the conf that is actually embedded in application.xml to a file
>more visible by the user. We can use plexus-registry for
>this.
Agree.

>- Better support of XML-RPC and other remote access (XFire, ...). For this
>point, I think it would be good to share the code with the GWT part with
>some services classes that will embed all the
>"remote" code with security checks
 In the next days, I will try starting some work on the xfire support.

>- Better support of maven projects. Actually, we detect if a build is
>required by looking at scm changes and dependencies changes. The problem
>is in dependencies changes. We look only at dependencies
>that are a continuum project too, it would be good to check repositories
>to find if a new version exists like maven do it. An other problem with
>dependencies changes is we don't really check if a new
>version exists but only if a new build result was created, it's a problem
>in case of projects with more than one build definition (for example
>"clean install" and "site"). If a site is generated, a
>new build result is created and continuum consider it as a dependency
>change so it rebuild all dependent projects in the next step.

Sure will be a nice feature.

>About GWT, I found few guys (6) that want to spend some time to do the
>migration and investigate on some new UI features.This roadmap is short
because I don't want to wait a new time a long wait
>before to release a new 1.x version and I'd like to attract new users. I'd
>like to release 1.2 betfore the end of the year.

I'd like we start to think about plugins/extensions (other ci have this)
maybe starting with a builderListener (pre/post build) (this could be a
plexus component and we could provide archetype for users)

>I'll send a new mail in few weeks about 2.0 roadmap that will require more
work.
>wdyt?


>Emmanuel




--
Olivier

[Wendy Smoak-3]

On 10/3/07, Emmanuel Venisse <emmanuel@...> wrote:

> GWT seems to be good and easy to use. All GWT users I met don't want to
> change now and they work on some very big applications

I'm sure the brain trust at Google has it all under control. :)  I'll
wait and see how it turns out...

--
Wendy

[ossi petz-2]

Hallo there

roadmaps are a good thing!

Emmanuel Venisse schrieb:
> - Rewrite all the UI with a full GWT site. I want to migrate to GWT
> because we need better performance on the UI even if it is correct now.
> The second point is that with GWT (and Ajax in general)
 >
i dont know that much about gwt. i would recommend to stuck with a web
framework found at apache.org. wicket, tapestry or one of the other 120?
i dont see license trouble but well: political correctness? :)

in the end i have preferred framework.

some tweaks on the gui may not be that wrong. it looks nice but it has
some 'search and try and click' tendency. but as mentioned thats more
marketing. i vote for stronger more stable build support (see below).


> - Better support of XML-RPC and other remote access (XFire, ...). For this
> point, I think it would be good to share the code with the GWT part with
> some services classes that will embed all the
> "remote" code with security checks
>

sounds good too. at some point some eclipse integration / plugin would
be something. that would allow a good starting point.

> - Better support of maven projects. Actually, we detect if a build is
> required by looking at scm changes and dependencies changes. The problem
> is in dependencies changes. We look only at dependencies
> that are a continuum project too, it would be good to check repositories
> to find if a new version exists like maven do it. An other problem with
> dependencies changes is we don't really check if a new
> version exists but only if a new build result was created, it's a problem
> in case of projects with more than one build definition (for example
> "clean install" and "site"). If a site is generated, a
> new build result is created and continuum consider it as a dependency
> change so it rebuild all dependent projects in the next step.
>

that will be the more important part :)
what i currently miss are clearer build dependencies. i think its pretty
difficult to actually determine the correct build order automatically.
so i would like to have the possibility to create some sort of 'build
tree'. a build would be starting at the root of the tree going downwards
building the projects.
our projects often depend on each other. sometimes the change in one
module triggers the build of another project mutliple times (if a third
module was triggered too). a tree like structure would allow to keep
some order while not loosing some overview of the dependencies and help
to avoid re-re-rebuilds of the same modules.

also a fueature request like 'planned release' would be cool. so a
release could be planned for some date. continuum could then create the
release on its own on a week end. this is an issue since one release may
require the release of dependant porjects (see build tree thing). and
with all reports and stuff this takes ages.

at the moment we dont need clustering. installing multiple servers does
the job for us.


i've seen in bamboo that it is collection certain statistical
information (build time, failed builds, time to fix tests). such
features would be a nice to have. but it would require reporting over
mutliple projects to make any sense.


hope to gave you some ideas :)


thanks a lot!
regards

ossi