Thanks Rahul.
Emmanuel
On Feb 20, 2008 4:44 AM, Rahul Thakur [EMAIL PROTECTED] wrote:
Hi,
I have re-organised and updated content related to Continuum 2.0 Roadmap
here:
http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Draft+-+Continuum+2.0+Roadmap
Would appreciate if others can
Another feature (rather features) that i would like to see is around
Change tracking/audit.
I would like to add to the feature list - integration with some of
popular Change management/ Bug tracking systems, such that user can see
issues fixed in a build.
On a related note, I think we are
On 21/02/2008, at 9:57 AM, Rahul Thakur wrote:
Another feature (rather features) that i would like to see is around
Change tracking/audit.
I would like to add to the feature list - integration with some of
popular Change management/ Bug tracking systems, such that user can
see issues
Hi,
I have re-organised and updated content related to Continuum 2.0 Roadmap
here:
http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Draft+-+Continuum+2.0+Roadmap
Would appreciate if others can review/update/comment as appropriate.
Also, I think we start cutting out concrete JIRA tasks
Sorry, just caught up with my mails today..
Anyway, +1 on the things in the wiki. All the ideas are exciting :) As what
have been mentioned already in the thread, I agree that it would be easier
and more manageable to implement these plans in milestones not just in one
blow.
And if Continuum
Maria Odea Ching wrote:
Anyway, +1 on the things in the wiki. All the ideas are exciting :) As what
have been mentioned already in the thread, I agree that it would be easier
and more manageable to implement these plans in milestones not just in one
blow.
Smaller iterations and more frequent
Hello Everyone,
I have re-organized the document on the cwiki.apache.org
http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Continuum+2.0+Roadmap*
*and, moved the items into their own child pages. I think we should have
a template to lend some structure to requirements captured and
Overall I think the core of Continuum should be re-though to be more
pluggable. In particular a workflow engine should be in the middle of
the execution to orchestrate any steps involved with building a
project. This is one of the places where people should be able to plug
in their own steps
snipped
1-2)I would like to bring Guice to the mix. I think it is worth
investigating for Continuum 2.0 - WDYT?
I need a reason to drop the current set of technologies, why is the
new set better etc.
My motivations behind this were:
# leverage Java 5 language and other library
Here's my list:
1) Peformance improvements.
2) A slicker User Interface. Ability to let the user work in an offline
mode (Google Gears!) and sync periodically.
3) Good user and developer documentation.
4) Better public APIs (rework Store and Continuum)
Rahul
Napoleon Esmundo C. Ramirez
1. +1 on distributed builds, along with examples on the 2 main use
cases I see for distributed builds:
a. building on many platforms for native builds that need
multiple distributions.
b. distribute the build across many machines to decrease the
latency of building everything.
Some good points emerging from this discussion! :-)
Would it be a nice idea to put following on wiki:
1) State goals/philosophy for C2 in light of lessons learnt from 1.x
development - lean, mean, extensible (~add any other here~)
2) Document *all* features/requirements we want to see in C2
Are you thinking what I am thinking - an OSGi based runtime underneath
and plugins/extensions that could be loaded runtime?
:-)
Carlos Sanchez wrote:
Some comments
Database vs xml: definitely database. Throwing away the db access api
(JDO/JPA/...) now that it's already there doesnt make much
Hi,
This looks very exciting (I love the plugin idea).
As all of this features can be long to implement, I agree with Brett
to separate into different millestones releases. (IMHO a full big
bang will be very long).
And currently they are some blocking issues in the 1.1 release.
--
Olivier
We can create such a wiki any time - the challenge is converting
existing content. If someone is happy to lose history and do it by
hand, it can be done straight away.
On 06/02/2008, at 9:25 PM, Rahul Thakur wrote:
Some good points emerging from this discussion! :-)
Would it be a nice
well, if you want to have a plugin based architecture, what better
that OSGi? and it may help too for distributiion of build machines
On Feb 6, 2008 2:08 AM, Rahul Thakur [EMAIL PROTECTED] wrote:
Are you thinking what I am thinking - an OSGi based runtime underneath
and plugins/extensions that
On Feb 6, 2008 6:52 AM, Christian Edward Gruber [EMAIL PROTECTED] wrote:
LOL. I'm so out of date. I used to work with TopLink way back in the
earliest days, and tracked it up to the Oracle buyout. After that I
didn't pay attention, and it's clearly changed direction. Never knew
the core
If everyone is happy to keep the history till date on codehaus wiki, I
can help copy stuff across to Apache wiki :-)
Rahul
Brett Porter wrote:
We can create such a wiki any time - the challenge is converting
existing content. If someone is happy to lose history and do it by
hand, it can
I can only agree on the pointers given in the wiki. However, I'd like to
reiterate the low significance of database portability in a CI server. I
think speed matters but not really portability.
Andy seems to be willing to help solve the database problems Continuum is
experiencing.
Just my 2
Some comments
Database vs xml: definitely database. Throwing away the db access api
(JDO/JPA/...) now that it's already there doesnt make much sense.
Maybe there are implementations that use xml for storage and that's
where you'd need to look if you want file storage
Spring vs Guice vs Plexus:
Just some thoughts,
I strongly agree to the proposed technology changes, particularly in the
database, as it will definitely improve the storage performance. In line
with the objectives to make Continuum a slick CI server, I think the design
changes is a good move as well. In my opinion, having
On 06/02/2008, at 1:20 PM, Napoleon Esmundo C. Ramirez wrote:
Just some thoughts,
I strongly agree to the proposed technology changes, particularly in
the
database, as it will definitely improve the storage performance. In
line
with the objectives to make Continuum a slick CI server, I
Good to see C2 discussions picking up! \o/
Re. TopLink
TopLink Essentials is governed by this license:
https://glassfish.dev.java.net/public/CDDLv1.0.html
I am not sure if that license is compatible with our goals or not. Also,
EclipseLink has already been mentioned on this thread earlier.
LOL. I'm so out of date. I used to work with TopLink way back in the
earliest days, and tracked it up to the Oracle buyout. After that I
didn't pay attention, and it's clearly changed direction. Never knew
the core was open-sourced.
Anyway, it's always been one of the better OR/M
Incidentally, according to this:
http://people.apache.org/~cliffs/3party.html
CDDL software can be included in binary form (so as a binary maven
dependency), but the project would not be able to ship any source from
it.
regards,
Christian.
On 6-Feb-08, at 00:03 , Rahul Thakur wrote:
On Jan 30, 2008 9:05 AM, Rahul Thakur [EMAIL PROTECTED] wrote:
Hi,
Great to see version 2.0 discussions kicking off! Thanks for putting the
ideas on confluence, Emmanuel. :-)
Some notes around the ideas outlined on the wiki:
1) Architecture
Moving to JSE 5 and JPA is a good idea \o/, it
Hi,
Great to see version 2.0 discussions kicking off! Thanks for putting the
ideas on confluence, Emmanuel. :-)
Some notes around the ideas outlined on the wiki:
1) Architecture
Moving to JSE 5 and JPA is a good idea \o/, it been fairly overdue ;-).
1-1)Can you please elaborate a bit on
TopLink has a large community of users and active forums at both Oracle and
Glassfish. If you are concerned about licensing, Oracle has donated the
full TopLink source to the Eclipse Foundation under the Eclipse Persistence
Services (EclipseLink) project. If you have any questions the
28 matches
Mail list logo
