+0
--- Vincent Massol <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Apache is slowly migrating all its projects to Subversion and they're
> asking
> us if we want to do it for Cactus. I've personally used SVN on several
> projects and it's great. The tools are slightly behind compared to CVS
> but
> they a
I don't see any reason to hold it up.
Cheers,
Nick
--- Vincent Massol <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'd like to quickly release Cactus 1.7. I have tried it with latest
> versions
> of most containers and it's working fine.
>
> We've already had a positive vote some time back and we've ag
+1 from me then.
nick
--- Vincent Massol <[EMAIL PROTECTED]> wrote:
> Hi Chris,
>
> Patches no longer go to the mailing list as we're now using JIRA. Before
> sending my email I had done a search on JIRA and found about 6 issues
> opened
> by Felipe along with corresponding patches. I have also a
+1 --Nick
--- Christopher Lenz <[EMAIL PROTECTED]> wrote:
> Vincent Massol wrote:
> > Hi committers,
> >
> > I'd like to move the Cactus plugin for Maven in Cactus CVS. The reason
> > it was in Maven CVS was that until now it was much easier for end users
> > to get it bundled with the Maven distr
Also, should we vote on giving Julien commiter status? I haven't reviewed
his patch, but if he plans to contribute on a regular basis, it might be a
good idea...
Cheers,
Nick
--- Lesiecki Nicholas <[EMAIL PROTECTED]> wrote:
> I trust your judgement, though I know little about M
I trust your judgement, though I know little about Maven. If Maven would
simplify the current build process I am all for it.
+0 (I'm for it, but I'm unlikely to help)
Cheers,
Nick
--- Vincent Massol <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This follows a recent email exchange with Julien about his w
t; > throw new IllegalStateException();//I always get this
> > }
> > return resultsId;
> > }
> >
> > I haven't worked much with headers, is either of these two code
> fragments
> > fundamentally flawed?
> >
> >
> > Cheers,
> > Nick
>
+1. (sorry. I was out of town.)
--- Vincent Massol <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Quick update: all the changes from CVS HEAD have been merged into the
> 1.5 branch. Only waiting for the vote result now... :-)
>
> Thanks
> -Vincent
>
>
> -
Thamks for the heads up.
Cheers,
Nick
--- Vincent Massol <[EMAIL PROTECTED]> wrote:
> Hi Cactus committers,
>
> I would like to apologize for not helping answer questions during the
> past week. The reason is that I have been on business trip in India and
> I was very busy (I also got sick...). I
Thanks Chris!
Cheers,
nick
--- [EMAIL PROTECTED] wrote:
> cmlenz 2003/07/09 09:36:07
>
> Modified:framework/src/java/share/org/apache/cactus
> RequestDirectives.java
> AbstractWebServerTestCase.java
>
> framework/src/java/s
ess I hear otherwise.
Cheers,
nick
--- Christopher Lenz <[EMAIL PROTECTED]> wrote:
> Lesiecki Nicholas wrote:
> > Hi,
> >
> > --- Christopher Lenz <[EMAIL PROTECTED]> wrote:
> >
> >>On a related note, we are now pretty much in a feature freeze until we
Hi,
--- Christopher Lenz <[EMAIL PROTECTED]> wrote:
> On a related note, we are now pretty much in a feature freeze until we
> branch out a CACTUS_15_BRANCH for maintenance. That will be done as soon
> as we release a beta of 1.5. Until then, we should not add the Test-ID
> functionality to CVS
--- Vincent Massol <[EMAIL PROTECTED]> wrote:
> I don't understand. There are two kinds of unit tests: logic unit test,
> tested in isolation and integration unit tests. Logic unit test is
> executed in the cactus framework project and iut in the sample-servlet
> one. What's wrong with this?
>
N
-1 To supporting two HttpClients going forward. What's the benefit?
Lets rely on HttpClient.
Cheers,
Nick
--- Christopher Lenz <[EMAIL PROTECTED]> wrote:
> Vincent Massol wrote:
>
> >>-Original Message-
> >>From: news [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Lenz
> >>Sent: 23 J
What do you all think of generating the uniqueId on the server side? The
question of uniqueness then becomes much, much easier. We could simply
store the id in a cookie cactus_test_id (like jsessionid) and have
subsequent requests pull the value of the cookie from the response and
resend it with th
Good point. Will do soon.
Cheers,
nick
--- Vincent Massol <[EMAIL PROTECTED]> wrote:
> Hi Nick,
>
> Cool!
>
> However, I think I would prefer not to add "Cactus" to method names. For
> 3 reasons:
> - everything in the code is about Cactus, so I find it redundant
> - we would need to add Cactus t
> I think this is something that needs to be decided *together* (i.e. all
> cactus committers). This is certainly not our current policy (which is
> why it wasn't in the checkstyle.xml).
Yes, of course. I will fix it soon.
>
> Can you please revert ASAP and document your private methods until we
--- Vincent Massol <[EMAIL PROTECTED]> wrote:
> I've been thinking about this and I find it a little inconsistent. We're
> calling addCommand() for all data that need to be passed to the server
> side. However, we don't call this for the id. Instead we call
> setUniqueId() (BTW, am I wrong in thin
> > -if (getWrappedTest() != this)
> > +if (wrappingATest())
>
> The refactoring is good but I don't much like the wrappingATest() method
> name... What about hasWrappedTest() or something like this (I like to
> prefix methods that return a boolean with "is" or "has")?
>
My
> Are we sure we need to add static text to the generated id? (I mean all
> the "testCase:", "_", etc?
No, I'm not sure. I guess I just wanted it there to check if the IDs were
really unique, and if not, why...So I'll take it out...
>
> How confident are we that this leads to a unique id? I'm n
I generally favor clear verbosity over muddled compactness. So, +1 from me.
Let's try it and see how it works out.
Cheers,
Nick
--- Vincent Massol <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'd like to propose a way to name our test methods. Instead of naming
> them with "test" such as in:
>
> testSet
Good point. I'm not convinced either. Why not URL parameters?
In any case I think the refactoring stands on its own. I might even be
tempted to push it one step further and have setter methods on WebRequest
for all the Cactus parameters. Just for clarity...
Cheers,
Nick
--- Vincent Massol <[EMAIL
22 matches
Mail list logo
