I'm going to start goofing around with this. I'll start by putting the
specs into geronimo/specs/branches. You can monitor the work:
https://issues.apache.org/jira/browse/GERONIMO-2336
Regards,
Alan
[
http://issues.apache.org/jira/browse/GERONIMO-2267?page=comments#action_12429183
]
Vamsavardhana Reddy commented on GERONIMO-2267:
---
Resolving GERONIMO-2294/GERONIMO-2268 will automatically resolve this issue.
I am cc'ying to Gianny (hope I got the right address), but I'd still
like to keep the thread public.
Since the response from others (Matt) was essentially JPA QL support
is not planned, and we need it now, I already started working on the
parser on Cayenne side using JavaCC (I know TranQL
I don't think that trick will work for an IDE, as it will only tell
you which directory the IDE started in. In intellij you can use
something like this:
public static String baseDir() {
Class myClass = null; // TestClass.class
URL classUrl =
+1
-dain
On Aug 18, 2006, at 4:53 PM, Jason Dillon wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags.
There will instead be one trunk+branches+tags for all specs laid
out as follows:
specs/trunk/pom.xml
specs/trunk/artifactId
On 8/18/06, Jason Dillon [EMAIL PROTECTED] wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags.
There will instead be one trunk+branches+tags for all specs laid out
as follows:
specs/trunk/pom.xml
specs/trunk/artifactId
Hi Jason,
Before going too deeply in to the JUnit space what do you think of
using TestNG. I've used it on a couple of applications and found it
very nice to work with. Its yet another reason to move to JDK 5
though so I'm not sure about timing (although you can use it with JDK
1.4 I've
GERONIMO-2332 didn't show up in the list of RTC issues sent out
today, and I don't see the Begin RTC Review button any ideas?
Anyway, please vote so we can get this taken care of.
thanks
david jencks
On Aug 18, 2006, at 4:15 PM, David Jencks wrote:
I've implemented the proposal to not
[ http://issues.apache.org/jira/browse/GERONIMO-2248?page=all ]
Vamsavardhana Reddy updated GERONIMO-2248:
--
Attachment: GERONIMO-2248-revised.patch
GERONIMO-2248-revised.patch: Revised the patch to output stack trace when a
should not occur
[
http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429207
]
Alan Cabrera commented on GERONIMO-2332:
While I understand the problem that this is trying to solve, I do not agree
with the way we are trying to
[ http://issues.apache.org/jira/browse/GERONIMO-2332?page=all ]
Alan Cabrera updated GERONIMO-2332:
---
Issue Type: RTC (was: Bug)
Workflow: RTC Workflow (was: jira)
RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a
Its issue type was a bug. Bugs don't go through RTC. I have changed
its type to be RTC and moved its state to RTC review.
Regards,
Alan
David Jencks wrote:
GERONIMO-2332 didn't show up in the list of RTC issues sent out today,
and I don't see the Begin RTC Review button any ideas?
I'm wondering what why one would need such a bean.
Regards,
Alan
Move classloaders to their own module
-
Key: XBEAN-45
URL: http://issues.apache.org/jira/browse/XBEAN-45
Project: XBean
Issue Type: RTC
Reporter: Alan Cabrera
Assigned To: Alan
I think that we should move the XBean Jira notifications to the new
XBean dev list. Any objections?
Regards,
Alan
+1
On 8/19/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
I think that we should move the XBean Jira notifications to the new
XBean dev list. Any objections?
Regards,
Alan
--
Cheers,
Guillaume Nodet
And svn notifiations too i guess.
On 8/19/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
I think that we should move the XBean Jira notifications to the new
XBean dev list. Any objections?
Regards,
Alan
--
Cheers,
Guillaume Nodet
I'm going to start goofing around with this. I'll start by putting the
specs into geronimo/specs/branches. You can monitor the work:
https://issues.apache.org/jira/browse/GERONIMO-2336
Regards,
Alan
JSR196 API
--
Key: GERONIMO-2336
URL: http://issues.apache.org/jira/browse/GERONIMO-2336
Project: Geronimo
Issue Type: RTC
Security Level: public (Regular issues)
Reporter: Alan Cabrera
Assigned To: Alan
Then we should create a list xbean-scm.
Regards,
Alan
Guillaume Nodet wrote:
And svn notifiations too i guess.
On 8/19/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
I think that we should move the XBean Jira notifications to the new
XBean dev list. Any objections?
Regards,
Alan
[
http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429219
]
David Jencks commented on GERONIMO-2332:
I have no big argument against alan's objection. I'd kind of like to only have
one copy of these and not one
The spec is currently in
http://svn.apache.org/repos/asf/geronimo/sandbox/jaspi-spec/
On 8/19/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
I'm going to start goofing around with this. I'll start by putting the
specs into geronimo/specs/branches. You can monitor the work:
Is it even possible as xbean is under geronimo in the svn tree ?
On 8/19/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
Then we should create a list xbean-scm.
Regards,
Alan
Guillaume Nodet wrote:
And svn notifiations too i guess.
On 8/19/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
I
It's kinda out of date. I'll check my stuff in.
Regards,
Alan
Guillaume Nodet wrote:
The spec is currently in
http://svn.apache.org/repos/asf/geronimo/sandbox/jaspi-spec/
On 8/19/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
I'm going to start goofing around with this. I'll start by
On 8/19/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
I think that we should move the XBean Jira notifications to the new
XBean dev list. Any objections?
Oh, I didn't notice there were a new mailing list for XBean (!)
+1 for the change.
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
If your stuff supersedes the bits in the sandbox can we remove the
sandbox stuff?
--jason
On Aug 19, 2006, at 1:04 PM, Alan D. Cabrera wrote:
It's kinda out of date. I'll check my stuff in.
Regards,
Alan
Guillaume Nodet wrote:
The spec is currently in
[ http://issues.apache.org/jira/browse/GERONIMO-2336?page=all ]
Jacek Laskowski updated GERONIMO-2336:
--
Summary: JSR 196: JavaTM Authentication Service Provider Interface for
Containers API (was: JSR196 API)
Description:
JSR196 API in
Do you plan to work on the implementation too ?
On 8/19/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
It's kinda out of date. I'll check my stuff in.
Regards,
Alan
Guillaume Nodet wrote:
The spec is currently in
http://svn.apache.org/repos/asf/geronimo/sandbox/jaspi-spec/
On 8/19/06,
Thanks Jacek!
Regards,
Alan
Jacek Laskowski (JIRA) wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2336?page=all ]
Jacek Laskowski updated GERONIMO-2336:
--
Summary: JSR 196: JavaTM Authentication Service Provider Interface for
Seems this was changed with your recent pluggable jacc stuff...
snip
--- geronimo/trunk/configs/javamail/pom.xml 2006/08/15 23:17:22 431731
+++ geronimo/trunk/configs/javamail/pom.xml 2006/08/18 07:44:04 432510
@@ -42,9 +42,9 @@
/dependency
dependency
-
I had figured I might need something magical like this... will
validate soonish and commit.
--jason
On Aug 19, 2006, at 8:11 AM, Dain Sundstrom wrote:
I don't think that trick will work for an IDE, as it will only tell
you which directory the IDE started in. In intellij you can use
I've cleaned up the javamail project, and published artifacts as well as site. Site should be up in an hour or so (or whenever the sync gremlins do their thing) here: http://geronimo.apache.org/maven/javamailYou should not need to build this by hand anymore. Lemme know if you (or anyone else)
I'm all for TestNG... hopefully now the maven reports are all happy
since its now supported by surefire.
But, the TestSupport classes does not need to be JUnit specific, the
same code will work fine in TestNG... and once we switch over to TNG
fully (if or when that is), all we need to do
Aight, I'm gonna nuke it and the custom pom muck that was making
product-versions.properties.
--jason
On Aug 18, 2006, at 6:39 PM, Aaron Mulder wrote:
On 8/18/06, Jason Dillon [EMAIL PROTECTED] wrote:
Anything else we can whack?
And do you know will anything blow up if we remove
[X] 0 No opinion
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
On 8/18/06, Jason Dillon [EMAIL PROTECTED] wrote:
Since we are not going to put any effort into getting the izpack
installer back up in trunk/1.2 right now, I'd like to remove this
module.
If needed we can always resurrect it later.
+1 (Create a jira task and whack the module)
Jacek
--
Chris, this sounds like an interesting idea. As I recall, the
discussion from a few months ago came down to removing the JMX debug
application iff we could get the JConsole to work with Geronimo. And
then I think that problem was addressed in GERONIMO-1329. So assuming
that we can now connect
The issue is here:
http://issues.apache.org/jira/browse/GERONIMO-2334
--jason
On Aug 19, 2006, at 4:24 PM, Jacek Laskowski wrote:
On 8/18/06, Jason Dillon [EMAIL PROTECTED] wrote:
Since we are not going to put any effort into getting the izpack
installer back up in trunk/1.2 right now,
On Aug 19, 2006, at 3:10 PM, Jason Dillon wrote:
I'm all for TestNG... hopefully now the maven reports are all happy
since its now supported by surefire.
But, the TestSupport classes does not need to be JUnit specific,
the same code will work fine in TestNG... and once we switch over
to
My point was that TestSupport is as of right now now dependent on JUnit.
But, even if we do move on to use TestNG there is no major reason why
we would need to change the parent class... we could, but don't have to.
--jason
On Aug 19, 2006, at 5:21 PM, Dain Sundstrom wrote:
On Aug 19,
+1 to JIRA
+1 to create svn list
-dain
On Aug 19, 2006, at 12:02 PM, Guillaume Nodet wrote:
+1
On 8/19/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
I think that we should move the XBean Jira notifications to the new
XBean dev list. Any objections?
Regards,
Alan
--
Cheers,
Hi Jason,
If you have it extending from TestCase then people will use those
methods in writing their tests which would force the dependency even
if unintended.
Could we make this class a decorator? Then many fewer would be likely
to use it as a superclass but instead would import it and
+1
On Aug 18, 2006, at 5:53 PM, Jason Dillon wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags.
There will instead be one trunk+branches+tags for all specs laid
out as follows:
specs/trunk/pom.xml
specs/trunk/artifactId
43 matches
Mail list logo
