I've added...
https://svn.apache.org/repos/asf/geronimo/sandbox/xsds/web-app_2_3.dtd
On Dec 11, 2006, at 4:08 PM, Kevan Miller wrote:
On Dec 11, 2006, at 3:44 PM, Jarek Gawor wrote:
I attached to https://issues.apache.org/jira/browse/GERONIMO-2630 a
simple Java program that can remove any
On Dec 11, 2006, at 4:41 PM, Sachin Patel wrote:
I've added...
https://svn.apache.org/repos/asf/geronimo/sandbox/xsds/web-app_2_3.dtd
Thanks Sachin. I'll get the others taken care of -- over half way
done. I'll test/validate later tonight. Should be able to commit in
specs tree later
On Dec 11, 2006, at 1:41 PM, Jason Dillon wrote:
On Dec 11, 2006, at 12:16 PM, Dain Sundstrom wrote:
On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
I'm in favor of a single version for all specs. Versioning the
specs
individually has some advantages but makes the release manager's job
On Dec 11, 2006, at 12:16 PM, Dain Sundstrom wrote:
In that case, why not move specs into the server tree?
Why not version each module in the server tree separately?
--jason
On Dec 11, 2006, at 1:13 PM, Matt Hogstrom wrote:
IMHO I like option 3 which is both option 1 and 2. First, I think
all SPECs should be versioned independently as not everyone is
interested in all the specs. If, for instance, the Tomcat dudes
decide to pick up anything we have they would
On Dec 11, 2006, at 1:28 PM, Prasad Kashyap wrote:
The openejb-itests-core is created in the openejb itself.
Not the jar file, the car file, where is that created? The est-
ejbcontainer/pom.xml has a dep on it.
-David
http://svn.apache.org/viewvc/incubator/openejb/branches/v2_2/
There also is a OpenJPA snapshot getting pulled in -
0.9.6-incubating-SNAPSHOT
and a activeio snapshot from ActiveMQ -
3.0-SNAPSHOT
I've got most of the Package page updated on the wiki with what was in
the last unstable build drop on 12/7 -
That's the point, you wont find it ;-)
For those articles where I could not get rid of the SNAPSHOT I left them for
developing later on.
Cheers!
Hernan
Jason Dillon wrote:
Can you point me at a specific screenshot which has the offending
snapshot muck in it?
--jason
On Dec 11, 2006, at
You do not need a branch for this. You can easily make a release
like this using `mvn release:*` off of trunk, and it will update the
poms, label and then update to the next version for development.
--jason
On Dec 11, 2006, at 1:37 PM, Paul McMahan wrote:
In order to make a release you
OMG.. For some reason, I thought that was David Jencks who asked that
and was explaining to him where the itests-core gets built :-)
Sorry, Blevins. I was talking to Jencks about this on the other thread.
Anyways, so you are looking at this pom snippet from the undeploy-module id.
OK the
Dependency on the car ? Where ? I don't see it.
It's just specified as the module to undeploy because that's what it
becomes after it gets deployed.
org.apache.openejb/openejb-itests-core/2.2-incubating-SNAPSHOT/car is
the entry in the config.xml
Cheers
Prasad
On 12/11/06, David Blevins
On Dec 11, 2006, at 1:53 PM, Dain Sundstrom wrote:
Um.. that's not true. Maven has full support for this. Also it
doesn't make the release manager's job harder.
Sure it does Dain, running one set of `mvn release:prepare mvn
release:perform` vs, running one per spec module. That is
On Dec 11, 2006, at 1:28 PM, Prasad Kashyap wrote:
So the itests-core's pom and plans all use this property during
resource filtering and thus have a dependency on it.
We should likely move the plan file security-plan.xml and openejb-
jar.xml which are essentially hardcoded to a geronimo
On Dec 11, 2006, at 1:56 PM, David Blevins wrote:
On Dec 11, 2006, at 1:28 PM, Prasad Kashyap wrote:
The openejb-itests-core is created in the openejb itself.
Not the jar file, the car file, where is that created? The est-
ejbcontainer/pom.xml has a dep on it.
Momentary brain loss.
Mmmkay, well then how about the URL on the console which has the
snapshot you want to remove. I'm just curious where this snapshot is
that is causing you problems.
--jason
On Dec 11, 2006, at 2:01 PM, Hernan Cunico wrote:
That's the point, you wont find it ;-)
For those articles where I
What do you mean? If you specify -Dmaven.repo.local=./svn-repo (or
where ever the svn checkout is) and run the build offline, then the
repo won't get modified, and thus only chance a bad artifact would
get in there would be if someone checked in something bad, or if the
local `mvn
Here is an example
http://cwiki.apache.org/confluence/download/attachments/29983/InstApp2.jpg
Is this the kind of screenshot you are looking for?
Cheers!
Hernan
Jason Dillon wrote:
Mmmkay, well then how about the URL on the console which has the
snapshot you want to remove. I'm just curious
But why do we want to use jetty5 and then jetty6 all in the same
branch?
I don't think the version should be here.
Actually I don't think that we need a version for the jee5 stuff
either. It should be jee, or probably javaee, adding the version
just means that every release we will have
Hrm... I had hoped that refactoring like this would have been delayed
until 1.2 was out the door. As with so many module renames, sync'ing
the 1.2 tree with trunk using SVK is going to be nearly impossible.
Maybe once SVK has more Perforce-like integration tracking then it
can handle
Sure. For now, that seems like a good idea. If you don't mind
separating the two, fine by me.
Also, the itests-core/pom.xml has this dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-security/artifactId
/dependency
Hope this doesn't cause any problems
Sorta, though these don't have snapshot in them :-P
The only way to fix these types of versions is to run the build as
1.2... which I guess you can do, but I still don't recommend.
I would hope that our users would be smart enough to figure this out
with out needing to make a mock 1.2
Moved the openejb-jar.xml to test-ejbcontainer.
Here's an error.
http://rifers.org/paste/show/2718
Will look at it further tonight
Cheers
Prasad
On 12/11/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Sure. For now, that seems like a good idea. If you don't mind
separating the two, fine by me.
On Dec 11, 2006, at 2:25 PM, Prasad Kashyap wrote:
Sure. For now, that seems like a good idea. If you don't mind
separating the two, fine by me.
Fine by me too. Let me know when you get it in and working and I'll
delete the copies from openejb.
Also, the itests-core/pom.xml has this
On Dec 11, 2006, at 11:28 AM, Rick McGuire wrote:
Prasad Kashyap wrote:
Geronimo 2.0-SNAPSHOT pulls in OpenEJB-2.2
OpenEJB-2.2 has a dependency on Geronimo-1.2-SNAPSHOT
When the openejb-2.2 branch was created, the Geronimo branch was
updated to have a dependency on OpenEJB-2.3. How did
Is there a way to specify that in the pom ?
Or you have to rely on users to specify it on the command
line everytime they build (or use batch files).
On 12/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
What do you mean? If you specify -Dmaven.repo.local=./svn-repo (or
where ever the svn
On Dec 11, 2006, at 2:47 PM, David Blevins wrote:
On Dec 11, 2006, at 2:25 PM, Prasad Kashyap wrote:
Sure. For now, that seems like a good idea. If you don't mind
separating the two, fine by me.
Fine by me too. Let me know when you get it in and working and
I'll delete the copies from
On Dec 11, 2006, at 2:35 PM, Prasad Kashyap wrote:
Moved the openejb-jar.xml to test-ejbcontainer.
Here's an error.
http://rifers.org/paste/show/2718
Will look at it further tonight
Maybe I need to yank the exiting ones before it will work. Going to
do that now.
-David
Cheers
Prasad
On Dec 11, 2006, at 2:55 PM, David Blevins wrote:
On Dec 11, 2006, at 2:35 PM, Prasad Kashyap wrote:
Moved the openejb-jar.xml to test-ejbcontainer.
Here's an error.
http://rifers.org/paste/show/2718
Will look at it further tonight
Maybe I need to yank the exiting ones before it will
Non-Geronimo servlet-api-2.4.jar being included in G1.2 build
-
Key: GERONIMO-2647
URL: http://issues.apache.org/jira/browse/GERONIMO-2647
Project: Geronimo
Issue Type: Bug
Unfortunately this would have to be externally controlled, can not
specify maven.repo.local in a pom, and if you could, can't root it to
the project, as ${pom.basedir} will always keep changing.
This was possible in m1 though... for what its worth. Only way to do
this in m2 is to use
On Dec 11, 2006, at 2:53 PM, Paul McMahan wrote:
For the tc6 integration I used jee5 in the assembly ids because the
jetty assemblies in trunk already used it. I certainly don't mind if
anyone wants to change them.
Ya, I don't think they should have ever been changed to jee5... but
with all
activemq::util::Boolean::parseBoolean should return bool not int
Key: AMQCPP-24
URL: https://issues.apache.org/activemq/browse/AMQCPP-24
Project: ActiveMQ C++ Client
Issue
[ https://issues.apache.org/activemq/browse/AMQCPP-24?page=all ]
Timothy Bish reassigned AMQCPP-24:
--
Assignee: Timothy Bish (was: Nathan Mittler)
activemq::util::Boolean::parseBoolean should return bool not int
[ https://issues.apache.org/activemq/browse/AMQCPP-24?page=all ]
Timothy Bish resolved AMQCPP-24.
Resolution: Fixed
Fixed in Trunk
activemq::util::Boolean::parseBoolean should return bool not int
[ https://issues.apache.org/activemq/browse/AMQCPP-24?page=all ]
Timothy Bish closed AMQCPP-24.
--
activemq::util::Boolean::parseBoolean should return bool not int
Key:
JPA mode is adding columns to our tables
Key: DAYTRADER-31
URL: http://issues.apache.org/jira/browse/DAYTRADER-31
Project: DayTrader
Issue Type: Bug
Components: EJB Tier
Affects
[ http://issues.apache.org/jira/browse/DAYTRADER-31?page=all ]
David Jencks closed DAYTRADER-31.
-
Resolution: Fixed
Fixed in rev 485965. Populating in direct mode and trading in jpa mode now
works (for me, on my machine, etc etc)
JPA mode is adding
Integrate JSF 1.2 into 2.0-M1
-
Key: GERONIMO-2648
URL: http://issues.apache.org/jira/browse/GERONIMO-2648
Project: Geronimo
Issue Type: Improvement
Security Level: public (Regular issues)
OpenJPA cache needs to be flushed when moving to jpa mode (or moving away from
jpa mode)
Key: DAYTRADER-32
URL: http://issues.apache.org/jira/browse/DAYTRADER-32
[ http://issues.apache.org/jira/browse/GERONIMO-2648?page=all ]
Tim McConnell updated GERONIMO-2648:
Patch Info: [Patch Available]
Integrate JSF 1.2 into 2.0-M1
-
Key: GERONIMO-2648
[ http://issues.apache.org/jira/browse/GERONIMO-2648?page=all ]
Tim McConnell updated GERONIMO-2648:
Attachment: GERONIMO-2648.patch
Integrate JSF 1.2 into 2.0-M1
-
Key: GERONIMO-2648
Just a FYI, that I'm going to enable AH email notifications to [EMAIL PROTECTED]
Emails have links to more details, log in with:
user: guest
pass: gbuild
--jason
[ http://issues.apache.org/jira/browse/GERONIMO-2648?page=all ]
Tim McConnell updated GERONIMO-2648:
Attachment: modules.zip
Integrate JSF 1.2 into 2.0-M1
-
Key: GERONIMO-2648
URL:
On Dec 11, 2006, at 1:55 PM, Jason Dillon wrote:
On Dec 11, 2006, at 12:16 PM, Dain Sundstrom wrote:
In that case, why not move specs into the server tree?
Why not version each module in the server tree separately?
Because many of the server modules are HIGHLY coupled which makes
FYI, I have disabled this, as it appears that AH is still misbehaving.
--jason
On Dec 11, 2006, at 5:01 PM, Jason Dillon wrote:
Just a FYI, that I'm going to enable AH email notifications to [EMAIL PROTECTED]
Emails have links to more details, log in with:
user: guest
pass: gbuild
On Dec 11, 2006, at 2:08 PM, Jason Dillon wrote:
On Dec 11, 2006, at 1:53 PM, Dain Sundstrom wrote:
Um.. that's not true. Maven has full support for this. Also it
doesn't make the release manager's job harder.
Sure it does Dain, running one set of `mvn release:prepare mvn
I updated the 1.2 tree last week to use the released versions of
OpenJPA and ActiveIO. Did they get rolled back to the SNAPSHOT
versions?
-dain
On Dec 11, 2006, at 1:57 PM, Donald Woods wrote:
There also is a OpenJPA snapshot getting pulled in -
0.9.6-incubating-SNAPSHOT
and a
I agree that parts of server should be split up into a few smaller
chunks... but I can tell you from current experience with what we
have so far, and from past experence where I worked on systems larger
than G with each bit versioned separately... that the more versions
you put in the mix,
On Dec 11, 2006, at 5:39 PM, Dain Sundstrom wrote:
In several cases, you must release more than one spec at a time.
But my point was more general... as in general its easier to
manage releases for a set of modules together instead of one by one.
You are assuming that is makes since to
The itests-core.jar now deploys and starts successfully. In a hurry, I
had yanked the openejb-jar.xml out but had forgotten to include it
during deployment. *duh*
Checked in the latest code changes to test-ejbcontainer.
Next problem, it thinks there are no tests ro run
On Dec 11, 2006, at 5:59 PM, Jason Dillon wrote:
I'm not sure that we will ever agree with each other. I'm not even
trying to convince you or anyone else... cause at this point I
simply don't care.
Before we continue this discussion, how about we first determine if
anyone cares?
If
No, I was using the last published unstable build from 12/7 for my
initial pass.
I just updated those 2 to match what's in pom.xml.
-Donald
Dain Sundstrom wrote:
I updated the 1.2 tree last week to use the released versions of OpenJPA
and ActiveIO. Did they get rolled back to the SNAPSHOT
Most of what I'm doing are only deletions since the new modules were
already created when sandbox/javaee5 was merged with trunk. For the
rework items, I am currently planning to leave the names of the
configurations unchanged. I will change
assemblies/geronimo-jetty-minimal to
On 12/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
I'm talking about the g-m-p assembly id, which is a terse alias to an
assembly configuration. That has *nothing* to do with artifactId's
as that thread was talking about. Assembly id's are not artifactId's
and the fact that people having been
Just finished updating the dependent packages wiki page for 1.2, along
with the current available version for each project we ship -
http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+Package+Tracking
I'll add a 2.0-M1 column next..
-Donald
smime.p7s
Description:
Maybe I could have saved you the trouble of writing the below email
and the subsequent discussion that ensued if I had only updated this
thread with the statement that I have already reverted back all the
assemblyIds to tomcat and jetty.
Sorry !
Anyway, I think we should go further and also
Aight, no worries... still the same problem. Would have recommended
that 1.2 get released before any significant changes here made.
Still possible to SVK merge 1.2 into trunk, just its going to be much
more manual now.
--jason
On Dec 11, 2006, at 6:37 PM, Joe Bohn wrote:
Most of what
I care but don't have the brain power or will to comment tonight.
On Dec 11, 2006, at 9:25 PM, Dain Sundstrom wrote:
On Dec 11, 2006, at 5:59 PM, Jason Dillon wrote:
I'm not sure that we will ever agree with each other. I'm not
even trying to convince you or anyone else... cause at this
[ http://issues.apache.org/jira/browse/GERONIMO-2646?page=all ]
Paul McMahan closed GERONIMO-2646.
--
Resolution: Fixed
WAR without a geronimo-web.xml deploys to the wrong context
---
On Dec 11, 2006, at 1:05 PM, Matt Hogstrom wrote:
OpenEJB will need to release as well so I'm hoping to have an
answer on the DayTrader issues tonight or tomorrow.
FYI, I have a similar thread on openejb-dev about releasing 2.2.
Make sure you read/reply if you have any open 2.2 issues.
Can you point me at a specific screenshot which has the offending
snapshot muck in it?
--jason
On Dec 11, 2006, at 7:46 AM, Hernan Cunico wrote:
Hi All,
I updated most of the Geronimo v1.2 doc. I couldn't get rid of the
*SNAPSHOT* for some screen captures so I guess it will be better to
Ok, I still don't have the brain power but this is in the back of my
mind.
Here is my take (yes, I'm rehashing stuff).
Currently what we have we don't want so we can eliminate the option
where we release everything under an uber version number that has no
bearing on the actual artifacts
On Dec 11, 2006, at 5:03 PM, Jason Dillon wrote:
You do not need a branch for this. You can easily make a release
like this using `mvn release:*` off of trunk, and it will update
the poms, label and then update to the next version for development.
I was thinking that our normal process
I have run into some problems trying to run Daytrader 1.2 (branches/1.2) on
Geronimo 1.2 and was wondering if anyone had any suggestions or thoughts?
The application deploys successfully from the console. However, the
following is encountered while starting the application. I have tried to
it worked! Thanks!
But I have a observation. When the broker starts, it shows the wrong total
recovered message number from Journal. This may not be the activemq-cpp
related. Can you help to verify?
This happens when you cosumed all the messages, and restart the broker. It
shows non-zero message
Do we really need to vote on all of these, and then release and then
revote, blah, blah? I mean do we want to spend so much energy on a
pre-alpha tech preview?
--jason
On Dec 11, 2006, at 7:39 PM, Matt Hogstrom wrote:
On Dec 11, 2006, at 5:03 PM, Jason Dillon wrote:
You do not need a
On Dec 11, 2006, at 7:36 PM, Matt Hogstrom wrote:
Ok, I still don't have the brain power but this is in the back of
my mind.
Here is my take (yes, I'm rehashing stuff).
Currently what we have we don't want so we can eliminate the option
where we release everything under an uber version
On Dec 11, 2006, at 8:23 PM, David Blevins wrote:
Just to quietly raise my hand, we used to do option 2 on 1.0-M1
through 1.0-M5 and I was release manager nearly all of those. I
advocated using one version for all specs. I eventually grew to
dislike that
On Dec 11, 2006, at 7:36 PM, Matt Hogstrom wrote:
Option 1:
Version all modules independently with no association to each other
except through perhaps dependencies.
- Makes releasing hard as coordinating multiple modules is the
responsibility of the consumer
- Makes releasing easy as there
Hopefully it will be one cut, one vote, and Xmas vacation :)
On Dec 11, 2006, at 10:58 PM, Jason Dillon wrote:
Do we really need to vote on all of these, and then release and
then revote, blah, blah? I mean do we want to spend so much energy
on a pre-alpha tech preview?
--jason
On Dec
Client deadlock during failover
---
Key: AMQ-1093
URL: https://issues.apache.org/activemq/browse/AMQ-1093
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 4.1.0
[ https://issues.apache.org/activemq/browse/AMQ-908?page=all ]
Ken Gallo updated AMQ-908:
--
Attachment: authorizationPlugin.patch
In:
authorizationEntry queue=USERS. read=users write=users admin=users
[ https://issues.apache.org/activemq/browse/AMQ-908?page=all ]
Ken Gallo updated AMQ-908:
--
Attachment: authorizationPlugin.patch
In:
authorizationEntry queue=USERS. read=users write=users admin=users
101 - 173 of 173 matches
Mail list logo
