in particular?
Emmanuel
Christian Edward Gruber a écrit :
It's quite nice. I wonder, since there are some ways to construct
cron schedules that don't use all fields, if it makes sense to have
an advanced alternate ui that does away with the individual form
values and tries out the single string
Actually, To Emannuel's point about building with clean checkout or
update, I'm working on such a thing, and should have a patch this
weekend. It'll also include the per-group/per-project/per-build-def
working directories, per my conversation with Kenney, and the do you
force a build on change,
Hey all,
I mentioned this on IRC and felt it should be sent ot the list.
The notion of default build def is really wierd, now that groups are
there.
In particular, can the default build def for a project be a group
def, or only a project def. The UI for this is also crapped out, as
If somone could document the jndi resources and how to configure them in
tomcat 5.5 that would be very nice. I couldn't figure it out, and am
currently running it with:
mvn jetty:run continuum.log
Christian.
ben short wrote:
Hi Philippe,
I wanted to do the same to see if there where any
Cool, more comment in-line.
Jesse McConnell wrote:
On 11/4/06, Christian Edward Gruber [EMAIL PROTECTED] wrote:
To that end, also, I think that the projects should still have an
internal primary key that's integer based, but that (continuum)
groupId+projectId should be an alternate business
Can you do the same with javax.activation? :)
[EMAIL PROTECTED] wrote:
Author: jmcconnell
Date: Wed Nov 8 09:17:12 2006
New Revision: 472550
URL: http://svn.apache.org/viewvc?view=revrev=472550
Log:
align with latest plexus-security configuration mechanism
update the pom.xml with a
Doesn't the plexus-runtime need it too?
Christian.
[EMAIL PROTECTED] wrote:
Author: jmcconnell
Date: Thu Nov 9 10:39:25 2006
New Revision: 473012
URL: http://svn.apache.org/viewvc?view=revrev=473012
Log:
added activation dependency, it appears that WorkingCopyAction brings in this
Sounds great to me. But I'm confused. Are the api's passing around
keys as in database keys (id), or so-called business keys, i.e. the
project group's text id and the project's text id? I presume the
latter, given the earlier discussions.
Christian.
Jesse McConnell wrote:
I am thinking about
This all sounds great, but why do they need to be immutable? If they
are essentially used for lookups, and they only exist in one place in
the database (because it's normalized enough through surrogate keys),
then other then the obvious caveats about external things depending on
the keys, why
If we use JPA or some such with caching at the HttpSession-scoped level
for keys (with some fancy dealing, I admit) we can have each person's
view independent on a per-session basis. That is, the key will be
translated into an id _in that person's context_, and the real id's are
used to fetch.
Yeah. But to have truly pluggable persistence, then we end up having to
pick LCD features. For isntance, if we want JDO, iBatis, and
JPA/Hibernate as possible approaches, then our design has to pretty much
ignore transparent relationship manifestation that JPA/hibernate/Toplink
provide.
Sorry, I was writing my post when this came in. I'm in general
agreement, and while I do think moving to something more than JDO is
important, Brett is right, the use of hte store could use a good audit
and re-factor. Probably some of the problems of strange access
approaches used currently
Trygve Laugstøl wrote:
1.0 to a 1.1 is not the time when you break an API. You can add stuff
with minor released, but not break things. This is the versioning
conventions used for all Maven-related projects. Perhaps trunk should
be 2.0, but as long as it's 1.1 it can't break the API.
+1
Christian
On 21-Sep-07, at 8:10 PM, Brett Porter wrote:
On 22/09/2007, at 7:34 AM, Rahul Thakur wrote:
So I think it would be good for Continuum to become a Top Level
Project at ASF and the continuum community will have more chance to
grow.
I agree. It is effectively running itself
+1, except for the last one, but only +0 for that.
Christian.
On 23-Sep-07, at 3:56 PM, Brett Porter wrote:
Hi,
Sorry, didn't take a look at these before the beta-3 release. What
do folks think of the following changes?
- replace select all/unselect all by a checkbox above the checkbox
You can get some benefit from named queries in terms of query pre-
compilation and caching 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
my two cents.
Emmanuel
On Jan 18, 2008 9:57 PM, Christian Edward Gruber [EMAIL PROTECTED]
wrote:
You can get some benefit from named queries in terms of query pre-
compilation and caching on the underlying database. However, most
database flavors and hibernate providers turn criteria queries
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
Nice!
On 6-Feb-08, at 00:31 , Rahul Thakur wrote:
I would have liked this thread to merge with Continuum 2.0
discussion thread, but anyway...
Its seems TopLink can do Criteria Queries (using Expressions and
ExpressionBuilders, correct me if I am wrong). It seems quite a few
JPA
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:
], Christian Edward
Gruber
[EMAIL PROTECTED] wrote:
On that note, isn't Cayenne JPA enabled? These guys are pretty sharp
and Cayenne has been around for quite some time, and it's been nicely
apachefied.
Christian.
On 6-Feb-08, at 12:48 , Howard Lewis Ship wrote:
Another very active Tapestry
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.
22 matches
Mail list logo
