Hi Guys,
I suddenly had this error coming later this afternoon when running
Continuum webapp. I suspect one of the snapshot dependencies (looks to
be coming from plexus-security-policy) got updated on the snapshot repo
and causing it.
Cheers,
Rahul
snip/
r,prepare-release]
2006-10-14
BTW, I have posted a patch on JIRA for this.
Rahul
- Original Message -
From: Rahul Thakur [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Saturday, October 14, 2006 10:37 PM
Subject: Continuum webapp error on accessing any page
Hi Guys,
I suddenly had this error
Hi Guys,
I suddenly had this error coming later this afternoon when running
Continuum webapp. I suspect one of the snapshot dependencies (looks to
be coming from plexus-security-policy) got updated on the snapshot repo
and causing it.
Cheers,
Rahul
snip/
r,prepare-release]
2006-10-14
you :P
jesse
On 10/26/06, Graham Leggett [EMAIL PROTECTED] wrote:
Rahul Thakur wrote:
Is 1.1 trunk at a point that I can put it to use . erm . in
production?
I built it from source, and deployed it within tomcat as a war - it's up
and running, but not doing anything yet awaiting
one of the problems here is that if you start letting the CI admin
make changes to project and project group names then you are breaking
the linkage between the POM and the representation of the project in
continuum. Unless you start adding in mapping functionalities and
thats just a pain when
On 27/12/2006, at 7:10 PM, Rahul Thakur wrote:
Updates to any children hanging off key entities should cascade.
This makes sense if and only if the children are dependent. So, for
build definitions - that's right. Profiles and such are all 'links'
and so will be managed by the normal
snip
Having said all of that, my vote (which no one need care about, since
I haven't had much time to actually contribute code here) is to
support hibernate with slight abstraction on top of it (modeled on
JPA's entity manager), so we get the benefits of transparent
persistence without
- Original Message -
From: Rahul Thakur [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Monday, January 08, 2007 4:05 PM
Subject: Re: [discuss] iBatis, JPA and Java 5.0
snip
Having said all of that, my vote (which no one need care about, since
I haven't had much time
Jesse and myself had a chat yesterday morning about the key-refactoring
branch that we spun before Christmas last year, and we reckon that it
might be an idea to get 1.1-alpha rolling and meantime gather more
thoughts around Groupings (introduce versions/tags). We think having
String-based keys
Jesse McConnell wrote:
I was figuring we would add something like this as some kinda
continuum extension for when the workflow is added to the continuum
object.
Is this going to be impelmented using plexus-spe or OS workflow?
Rahul
ah, I forgot mine...
Here's my +1
Rahul
Christian Edward Gruber wrote:
+1
Rahul Thakur wrote:
Hi,
I'd like to request a vote to merge the id-refactor branch changes.
'int' ids are now converted to 'long' across the project and to allow
really large values. This should cater to scenarios
[snip]
Can you please come up with a realistic use case where IDs would start
on something other than 0 or 1? The database is controlled by
Continuum and is an internal thing which we have complete control over.
I don't have a specific use case for Continuum handy, but I guess
Continuum can
[snip]
Can you please come up with a realistic use case where IDs would start
on something other than 0 or 1? The database is controlled by
Continuum and is an internal thing which we have complete control over.
I don't have a specific use case for Continuum handy, but I guess
Continuum can
Hi Marcel,
I am back from holidays now and would be interested in the work you
have done. I started of with some stuff on the Eclipse plugin but got
side tracked.
Cheers,
Rahul
On 3/8/07, Jesse McConnell [EMAIL PROTECTED] wrote:
rahul is on vacation for a bit longer I think, but he was
Since this would be a proper release (not a build), I'd imagine this
going on to the main repository (and subsequently mirrored).
Cheers,
Rahul
- Original Message -
From: Wendy Smoak [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Saturday, April 21, 2007 7:14 AM
Subject:
+1
Rahul
- Original Message -
From: Emmanuel Venisse [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Saturday, April 21, 2007 7:43 AM
Subject: Re: [Vote] release continuum 1.1 alpha 1
+1
Emmanuel
Jesse McConnell a écrit :
Its that time, to start releasing continuum in
Hey guys,
Some quick notes on the security for XML RPC interface. This is what I
am thinking...
Have an AuthenticatedXmlRpcService component that services the xml rpc
requests. The first request from a client to the service is a request
for authentication. A successful authentication
I thought there was something similar to this that exists in Redback?
Rahul
- Original Message -
From: Emmanuel Venisse [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Saturday, April 28, 2007 12:37 AM
Subject: Re: XML RPC security
I think it's best solution. With a
commit: r521662 - in /maven/continuum/trunk:
continuum-model/pom.xml pom.xml
Yes, with the actual version of Modello.
Without output directories, files are generated in wrong directories.
Emmanuel
Rahul Thakur a écrit :
Do we really need to specify the outputDirectory?
Eclipse barfs
- Original Message -
From: Jesse McConnell [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Tuesday, May 01, 2007 2:10 AM
Subject: Re: XML RPC security
I am hoping to get a couple of authn and authz web services running in
redback this week, once I finish up the role
I have been wanting to pop this questions for sometime now.
For generation/maintenance of continuum-model:
a) Why are we using Modello? More specifically what does it buy us? I
know the model is expressed as xml and separate from Java sources,
but I don't see a benefit of having it in XML as
- Original Message -
From: Emmanuel Venisse [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Saturday, September 22, 2007 3:57 AM
Subject: [discuss] Graduate Continuum to its own TLP
Hi,
At the begin, Continuum was designed to support maven2 projects so we
thought it was
I think this might be a good feature to have in continuum. Users can be
allowed to create their own notification templates that can be stored in
DB for a given build. In case of no email template, we use the default.
Thoughts?
Cheers,
Rahul
Tomislav Stojcevich wrote:
This was marked
I agree with Emmanuel; extracting templates from core jar is not a solution.
So far from this thread it seems there are quite a few things we could
do for the email template customization feature. IMO, We need to
brainstorm what might make best sense.
Do we allow custom email templates for:
Wendy Smoak wrote:
On 10/1/07, Tomislav Stojcevich [EMAIL PROTECTED] wrote:
What does everybody think about adding a step to the continuum-webapp
project that extracts the templates from the continuum-core.jar and
puts a copy of them in the WEB-INF/classes directory. When the mail
notifier
in classnames and the same could easily be done with the vm
template resource location, source from some configuration and then if
resource isn't found just use the default like emm was saying...
jesse
On 10/2/07, Rahul Thakur [EMAIL PROTECTED] wrote:
I agree with Emmanuel; extracting templates from core
like to nominate Emmanuel as the chair of the project. Are
there any other nominations?
I have the current committers list as:
Maria Odea Ching
Joakim Erdfelt
Olivier Lamy
Trygve Laugstol
Jesse McConnell
Brett Porter
Edwin Punzalan
Carlos Sanchez
Wendy Smoak
Rahul Thakur
Emmanuel Venisse
Kenney
Just wondering if anyone else got to the changes?
Emmanuel Venisse wrote:
I don't have the time to look at it these days but I'll do it asap
(maybe in few weeks :( )
Emmanuel
Rahul Thakur a écrit :
Hi All,
Scribbling some quick notes on some of the toying around I have been
doing
on the underlying database. However, most
database flavors and hibernate providers turn criteria queries into
named queries (parameterized SQL) which is then cached, so, on the
surface I suspect the performance characteristics will be similar.
Christian.
On 18-Jan-08, at 14:35 , Rahul Thakur
Emmanuel Venisse wrote:
Hi,
I'll probably create a new branch for 1.x dev and will reserve the trunk for
2.x dev. I think I'll do it this week or the next (if you're agree, of
course :) )
+1
I'll try to send at the same time my ideas for 2.x so we'll can discuss
about them.
+1. I
I'll try to send at the same time my ideas for 2.x so we'll can discuss
about them.
Can't wait for 2.x design discussions to kick off :-)
Cheers,
Rahul
Emmanuel
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
])
- Wendy Smoak ([EMAIL PROTECTED])
- Rahul Thakur ([EMAIL PROTECTED])
- Emmanuel Venisse ([EMAIL PROTECTED])
- Kenney Westerhof ([EMAIL PROTECTED])
- Andrew Williams ([EMAIL PROTECTED])
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be
appointed to the office of Vice President
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.
characteristics will be similar.
Christian.
On 18-Jan-08, at 14:35 , Rahul Thakur wrote:
Thanks Emmanuel! Responses inlined...
Emmanuel Venisse wrote:
Hi Rahul,
After few days to look at JPA, I'm sure now it would be good to use
it
instead of the actual JDO/JPOX (I know JPOX 1.2 support JPA).
The code
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
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 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
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
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
:
Thanks Brett.
I'm +1 to open it.
Emmanuel
On Feb 13, 2008 8:43 AM, Brett Porter [EMAIL PROTECTED] wrote:
no, permissions changes are non-destructive :)
On 13/02/2008, at 6:33 PM, Rahul Thakur wrote:
+1 as long as editing it requires a login :-)
Should I hold off the migration from
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
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
Great news! Congrats everyone :-)
Rahul
Brett Porter wrote:
Hi all,
Congratulations - the board passed the resolution we submitted.
We'll have some work to do to get set up over the next month, but
other than that it's business as usual. Certainly shouldn't interrupt
the planning for the
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
Hi,
I'd like to go ahead and pick up something towards the next Continuum
iteration. I am thinking refactoring ContinuumStore interface as was
earlier discussed on this list and as I did on the 'continuum-jpa'
branch.
To this end, I need to get a clear picture on a few items:
1) Which JPA
2) Criteria vs Named Queries: I am not convinced (yet) that Named
queries are the way to go. I did some digging around, they are indeed
best practices for JPA but I think the decision merits other
consideration(s). I still believe the Criteria Queries will help us
define a cleaner Store
Hi,
Some code using a couple of Entities as examples would be nice :-)
I still think the API would be verbose.
Thanks,
Rahul
On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse
[EMAIL PROTECTED] wrote:
On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur [EMAIL PROTECTED]
wrote:
2
Brett Porter wrote:
On 29/02/2008, at 10:04 AM, Emmanuel Venisse wrote:
On Thu, Feb 28, 2008 at 11:55 PM, Brett Porter [EMAIL PROTECTED] wrote:
On 29/02/2008, at 9:52 AM, Emmanuel Venisse wrote:
why 1.1.x?
in case there was a bugfix release on 1.1? I thought that was what the
branch
There are some other branches residing in Continuum SVN. Should we
remove any (or all) of the following if they are not in active
development? I know (id-refactor and key-based-refactor can go)
# continuum-acegi
# continuum-site_1.1
# gbuild
# id-refactor
# key-based-refactor
#
The branches have been removed except for 'continuum-site_1.1' which had
some updates a few months ago. If this is not required please feel free
to remove.
Rahul
Olivier Lamy wrote:
IMHO, we can remove.
2008/3/10, Rahul Thakur[EMAIL PROTECTED]:
There are some other branches residing
52 matches
Mail list logo
