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
