+1, maybe as a UI plugin
Emmanuel
On Wed, Feb 20, 2008 at 11:57 PM, Rahul Thakur <[EMAIL PROTECTED]>
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 ma
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 f
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
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 oth
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
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 expand
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 re
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 will
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
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.
2.
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 w
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 features, and en
Rahul Thakur 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 been fairly overdue ;-).
1-1)Can you please
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 cen
t; De : Thierry Lach [mailto:[EMAIL PROTECTED]
> Envoyé : mercredi 6 février 2008 17:34
> À : continuum-dev@maven.apache.org
> Objet : Re: [Discussion] Continuum 2.0 Roadmap
>
> Hibernate can be used in a completely JPA-compliant mode, so it would be
> (theoretically) just as swappab
Lach [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 6 février 2008 17:34
À : continuum-dev@maven.apache.org
Objet : Re: [Discussion] Continuum 2.0 Roadmap
Hibernate can be used in a completely JPA-compliant mode, so it would be
(theoretically) just as swappable as any other JPA implementation as long a
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 be
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 co
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 t
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 idea
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 on
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
2008
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
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:
Go
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 platfo
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.
Ra
Oh, and Tapestry5 is pretty high-performance, in my initial experience.
Christian.
On 5-Feb-08, at 22:12 , Christian Edward Gruber wrote:
Toplink is mentioned, but it's a commercial app, and I don't think
they'll license it in a way that's compatible (unless they've
radically changed polici
Toplink is mentioned, but it's a commercial app, and I don't think
they'll license it in a way that's compatible (unless they've
radically changed policies recently). I'm not a huge hibernate fan,
but at least its supported. At least with JPA and decent abstraction,
you should be able to
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 th
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
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: Sp
7) Documentation
I would like to add and emphasize here on documenting the code itself as
we write it. We are not going to get down to user documentation from day
one but there will be users in the community who start consuming the
code and contributing back as soon as we starting cooking it! :-
Rahul Thakur wrote:
Jesse McConnell wrote:
1-2)I would like to bring Guice to the mix. I think it is worth
investigating for Continuum 2.0 - WDYT?
I don't think. I don't see the interest to look at it for Continuum. We
already use Plexus that works fine, and if we decide to move
On Jan 31, 2008 11:05 PM, Jesse McConnell <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > 1-2)I would like to bring Guice to the mix. I think it is worth
> > > investigating for Continuum 2.0 - WDYT?
> >
> >
> > I don't think. I don't see the interest to look at it for Continuum. We
> > already use
>
> >
> > 1-2)I would like to bring Guice to the mix. I think it is worth
> > investigating for Continuum 2.0 - WDYT?
>
>
> I don't think. I don't see the interest to look at it for Continuum. We
> already use Plexus that works fine, and if we decide to move to something
> else, it should be
On Jan 30, 2008 9:54 PM, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> On Jan 30, 2008 12:34 PM, Jesse McConnell <[EMAIL PROTECTED]>
> wrote:
> > How important is the database really to things in continuum?
> >
> > To me it has always seemed somewhat of an annoyance to have to manage
> and
> > maintain
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
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 EclipseLin
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 r
39 matches
Mail list logo
