[
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83?page=comments#action_12417412
]
Donald Woods commented on GERONIMODEVTOOLS-83:
--
Guess I'm wondering how you are getting past the need for v4 POMs for the
Geronimo 1.0 files, given the
[
http://issues.apache.org/jira/browse/GERONIMO-2116?page=comments#action_12417408
]
Prasad Kashyap commented on GERONIMO-2116:
--
DJ, I didn't think you had to rebuild the jspc plugin. Jeff has applied my
patches to that plugin and had also deploy
Done.
--jason
On Jun 22, 2006, at 9:01 PM, Prasad Kashyap wrote:
Cool Jason. I like it. Can we please have to/fro links from the
http://cwiki.apache.org/geronimo site to the KB.
Thanx
Prasad
On 6/22/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
Autoexport is up:
http://cwiki.apache.org
Cool Jason. I like it. Can we please have to/fro links from the
http://cwiki.apache.org/geronimo site to the KB.
Thanx
Prasad
On 6/22/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
Autoexport is up:
http://cwiki.apache.org/GMOxKB/index.html
--jason
On Jun 22, 2006, at 12:17 PM, Jason Dill
Stack Traces upon Publishing Errors are difficult to read
-
Key: GERONIMODEVTOOLS-86
URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-86
Project: Geronimo-Devtools
Type: Improvement
Components: ecli
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83?page=all ]
Donald Woods reopened GERONIMODEVTOOLS-83:
--
Tried building it at least 6 times tonight without any luck.
Tried building a clean checkout at least 3 times in a row.
Tried with
Subject says it all. All projects moved over except XBean because
its root pom.xml has an incorrect scm url.
-David
[
http://issues.apache.org/jira/browse/GERONIMO-1960?page=comments#action_12417397
]
Dain Sundstrom commented on GERONIMO-1960:
--
Applied to branches/dain/openejb-2.2-merge
> Bad GBean reference isn't caught during deployment
>
Being one of the dissenters I think your approach is fine. Please take into consideration that
there may be competing implementations so the name hopefully will provide a clue as to what the
plugin does.
Thanks for the heads up.
Cheers
Matt
Aaron Mulder wrote:
I was not swayed by the argum
Update: injection of GBean references into the job works too. So it's
only EJB references that are problematic for these purposes in 1.1.
Thanks,
Aaron
On 6/22/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
I was not swayed by the arguments against letting people deploy Quartz
jobs as GBeans.
MessageAuthorizationPolicy doesn't work
---
Key: AMQ-775
URL: https://issues.apache.org/activemq/browse/AMQ-775
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Environment: windows NT 2003 server
Repo
[ https://issues.apache.org/activemq/browse/AMQ-528?page=all ]
will gunadi reopened AMQ-528:
-
Using:
-
backport-util-concurrent-2.1.jar
activemq-core-4.0.jar
activemq-ra-4.0.jar
jencks-all-1.1.3.jar
broker.xml:
---
http://activemq.org/
This is awesome! I think this framework can really let us quickly
and easily grow the content.
On Jun 22, 2006, at 2:38 PM, Jason Dillon wrote:
I think that the bulk of what is in http://wiki.apache.org/
geronimo/ should move to http://cwiki.apache.org/geronimo/
I think that the KB space is
I think that the bulk of what is in http://wiki.apache.org/
geronimo/ should move to http://cwiki.apache.org/geronimo/
I think that the KB space is really for stuff that does not fit
well into other spaces (like docNN or geronimo), or stuff that is
FAQ-like.
That was the original idea behi
On Jun 22, 2006, at 1:23 PM, Jason Dillon wrote:
I also think that we could probably merge GMOxPMGT into the
geronimo space, but that is just a thought.
+1
-David
IMO, the important thing is to get the content into Confluence and
out of moin. Maybe start by adding them to the sandbox j
Jason Dillon wrote:
I think that the bulk of what is in http://wiki.apache.org/geronimo/
should move to http://cwiki.apache.org/geronimo/
I think that the KB space is really for stuff that does not fit well
into other spaces (like docNN or geronimo), or stuff that is FAQ-like.
That was the
I think that the bulk of what is in http://wiki.apache.org/geronimo/
should move to http://cwiki.apache.org/geronimo/
I think that the KB space is really for stuff that does not fit well
into other spaces (like docNN or geronimo), or stuff that is FAQ-like.
It looks like the moin content is
Hi Jason,
what is the long term plan for this space? could we ultimately move/merge the MoinMoin content there
once migrated?
There is this GMOxSBOX space (the SandBox) that we could remove and put the GMOxKB instead, see
cwiki.apache.org/geronimo
Let me know what you think?
Cheers!
Hernan
Autoexport is up:
http://cwiki.apache.org/GMOxKB/index.html
--jason
On Jun 22, 2006, at 12:17 PM, Jason Dillon wrote:
Okay, here ya go:
http://cwiki.apache.org/confluence/display/GMOxKB
I did a few things...
First, I setup a geronimo team label, and labeled all of our spaces
(so
Okay, here ya go:
http://cwiki.apache.org/confluence/display/GMOxKB
I did a few things...
First, I setup a geronimo team label, and labeled all of our spaces
(so from the dashboard you can see all of the G-related spaces
easily). New spaces for G should also get this label added (have
On Jun 22, 2006, at 3:17 AM, Matt Hogstrom wrote:
The remaining question is what to do with the branches that are out
there. I think we should whack what's out there (does not appear
that there has been any activity) branches/1.1 and branches/1.1.1.
When the vote is complete later today a
Ok, on to the next phase of the javamail reorganization. This patch
http://issues.apache.org/jira/browse/GERONIMO-2147
is to remove the javamail-transport module and replace it with
references to the javamail-providers-1.3.1 jar file.
Rick
[ http://issues.apache.org/jira/browse/GERONIMO-2147?page=all ]
Rick McGuire updated GERONIMO-2147:
---
Attachment: notrans.diff
Changes to the config for removing the javamail-transport dependencies. Also
deletes the javamail-transport module.
> Remov
Then I think we're open for G-Business.
I love it... G-Business :-)
--jason
Remove javamail-transport from Geronimo build and replace with
javamail-provider dependency.
-
Key: GERONIMO-2147
URL: http://issues.apache.org/jira/browse/GERONIMO-2147
Project: Ge
[
http://issues.apache.org/jira/browse/GERONIMO-2116?page=comments#action_12417335
]
David Jencks commented on GERONIMO-2116:
The error I got before rebuilding the plugins was:
Embedded error: The -uriroot option must specify a pre-existing directo
Aaron Mulder wrote:
> I was not swayed by the arguments against letting people deploy Quartz
> jobs as GBeans. However, I agree that it's not appropriate for every
> case. When I document this plugin, I plan to list the use cases I'm
> going for and the ones I'm not.
>
I don't think people ha
GBeanOverride ignores reference name when saving if artifact is not set
---
Key: GERONIMO-2146
URL: http://issues.apache.org/jira/browse/GERONIMO-2146
Project: Geronimo
Type: Bug
Security: public
NPE in Maven1Repository
---
Key: GERONIMO-2145
URL: http://issues.apache.org/jira/browse/GERONIMO-2145
Project: Geronimo
Type: Bug
Security: public (Regular issues)
Components: kernel
Versions: 1.1
Reporter: Aaron Mulder
Assi
I was not swayed by the arguments against letting people deploy Quartz
jobs as GBeans. However, I agree that it's not appropriate for every
case. When I document this plugin, I plan to list the use cases I'm
going for and the ones I'm not.
After a little experimentation, I've been able to confi
Can you update the release procedure page?
http://geronimo.apache.org/xbean/release-procedure.html
-dain
On Jun 22, 2006, at 12:05 AM, Guillaume Nodet wrote:
The distribution repos ?
Well, i wanted to publish the release in a private repo so that it
can be voted,
and then move to public r
On Jun 22, 2006, at 2:01 AM, Rick McGuire wrote:
+1 (and we need to make sure this is added to the wiki so we can
remember it the next time a release is spun :-))
Definitely, was waiting to see some +1s before doing that part.
Here it is:
http://cwiki.apache.org/GMOxPMGT/release-branching-
GBean for handling initial database population
--
Key: GERONIMO-2144
URL: http://issues.apache.org/jira/browse/GERONIMO-2144
Project: Geronimo
Type: New Feature
Security: public (Regular issues)
Components: databases
ENCConfigBuilder blocks outside callers
---
Key: GERONIMO-2143
URL: http://issues.apache.org/jira/browse/GERONIMO-2143
Project: Geronimo
Type: Bug
Security: public (Regular issues)
Components: deployment, naming
Versio
Thanks for the helpful feedback Jeff. Comments inline.
On 6/21/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
Paul McMahan wrote:
> Liferay is an open source portal made available under the MIT license.
> They provide a geronimo+liferay distribution from their website,
> which is basically a zi
I have just launched a deployment of a new version which fixes a few bugs.
Will start a new vote in a few hours.
Cheers,
Guillaume Nodet
On 6/22/06, James Strachan <[EMAIL PROTECTED]> wrote:
+1
On 6/21/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> Here is my +1
>
> Cheers,
> Guillaume Node
+1
On 6/21/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
Here is my +1
Cheers,
Guillaume Nodet
On 6/20/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>
> I have uploaded binaries for the 3.0-M2-incubating release.
> The repos and site are available at
> http://people.apache.org/~gnodet/se
Thanks for the suggestions Aaron. Comments inline.
On 6/21/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
There are two options you should be aware of for a plugin.
One is that you can declare a database pool dependency named
"LiferayDatabase" or whatever. Then provide a Derby database pool
plug
I played around with j2ee-tomcat-server and came away with a good
first impression. I liked the 'usage' link on Database Pools and
Security Realms page. Here is my +1.
Thanks
Anita
P.S. - The copyright notice on console-->welcome says :
Copyright © 1999-2005 Apache Software Foundation
All Rig
On 6/22/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
Thanks David, I tried to recap in the other thread and didn't receive any
additional responses so
now that we have a branches/1.1.0 branches/1.1 and a branches/1.1.1 I don't
think we quite nailed
it. Your summary is great and I concur.
Her
On 6/22/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
+1 To Jason's comments with Hiram's comments...
I think we should do all development of 1.1.x in branches/1.1 (with
version 1.1.N-SNAPSHOT). But at the time we code freeze for a
release, I think we should svn copy branches/1.1 to branches/1.1.
Thanks Matt this helps a lot. Sounds like
DirectoryInitializationGBean can get the job done, mainly due to the
fact that creating a database in derby is as easy as copying a
directory into var/derby. I'll look into this approach for the
initial rev of the liferay database pool plugin and think l
Aaron Mulder wrote:
> On 6/21/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> Personal preference...but I think its better throwing an error. Is
>> "obsoleting" a settable option? I am not so sure I like obsoleting by
>> default...this could be ugly since it may be another app other than the
>>
EJB Refs to EJB in parent module often fail
---
Key: GERONIMO-2142
URL: http://issues.apache.org/jira/browse/GERONIMO-2142
Project: Geronimo
Type: Bug
Security: public (Regular issues)
Components: deployment, OpenEJB
+1 to david and alan's annotations.
Lets get it in the wiki!
thanks
david jencks
On Jun 22, 2006, at 4:06 AM, Alan D. Cabrera wrote:
+1
I think that we should mention that patches that go into
x.y.z also go into x.y and trunk
x.y also go into trunk
Last time we neglected to apply patches e
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83?page=all ]
Sachin Patel resolved GERONIMODEVTOOLS-83:
--
Resolution: Cannot Reproduce
Actually I've seen random compile errors like this once in a blue moon. I
think this is some ty
[ http://issues.apache.org/jira/browse/GERONIMO-2141?page=all ]
Rick McGuire resolved GERONIMO-2141:
Resolution: Fixed
Committed revision 416340.
Also fixed a copyright problem with a couple of the pom.xml files.
> javamail providers componen
javamail providers component referencing non-released version of activation
specs.
--
Key: GERONIMO-2141
URL: http://issues.apache.org/jira/browse/GERONIMO-2141
Project: Geronimo
Type: B
+1
Gianny
David Blevins wrote:
We had this whole conversation last week, lots of good discussion was
had. I'd prefer not to have to have it again. Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.
1.
+1 to David's recap and to Matts plans below.
John
Matt Hogstrom wrote:
Thanks David, I tried to recap in the other thread and didn't receive
any additional responses so now that we have a branches/1.1.0
branches/1.1 and a branches/1.1.1 I don't think we quite nailed it.
Your summary is grea
David Blevins wrote:
On Jun 21, 2006, at 10:53 PM, Alan D. Cabrera wrote:
David Blevins wrote:
The only thing done in a branches/x.y.z made from branches/x.y is
the release process itself.
I don't quite understand what this means. Sorry.
Referring to things like switching the version numb
Thanks David, I tried to recap in the other thread and didn't receive any additional responses so
now that we have a branches/1.1.0 branches/1.1 and a branches/1.1.1 I don't think we quite nailed
it. Your summary is great and I concur.
Here is my + 1 and I'm happy to get the Wiki updated.
Th
I think moving from branches to tags and back again is too disruptive. The reason it sits in its
own area in branches is so that it can be finalized and then copied once its done. If we have to
then we have to but this should be the rare exception that something is caught after the final vote
This patch addresses my major concerns. I consider it
a bug fix and thus not requiring further voting beyond
my previous +1, but in case anyone disagrees, I've
applied it and tested it to the best of my abilities
and vote +1.
thanks
david jencks
--- "Gianny Damour (JIRA)"
wrote:
> [
>
http
I replied on the other thread :) basically ActiveCluster
On 6/21/06, Komandur <[EMAIL PROTECTED]> wrote:
Hi,
Is any group membership protocol implemented as part of ActiveMQ ?
(I have seen references to ActiveCluster, and would like to know if AMQ
uses it for any of the configurations).
Than
+1 from me.
thanks
david jencks
--- Prasad Kashyap <[EMAIL PROTECTED]>
wrote:
> I did a sniff test of the installed product and I
> think we are good to go.
>
> +1 from me.
>
> I shall grill it some more tomorrow.
>
> Cheers
> Prasad
>
> On 6/19/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
+1 (and we need to make sure this is added to the wiki so we can
remember it the next time a release is spun :-))
David Blevins wrote:
We had this whole conversation last week, lots of good discussion was
had. I'd prefer not to have to have it again. Here is my exact
understanding of our cons
+1, but if we cut a release from the frozen branch, we need to note
the SVN version number or something so when we move it to tags we're
absolutely sure we didn't catch an extra commit in the tag. I'm also
fine with copying to tags, making the candidate from tags, and then
recreating the tag if a
Guillaume,
The M2 binary doesn't have the optional libraries, is this intentional or a
build issue
thanks
Soumadeep
- Original Message -
From: "Guillaume Nodet" <[EMAIL PROTECTED]>
To: ;
Sent: Tuesday, June 20, 2006 12:44 PM
Subject: ServiceMix-3.0-M2-incubating
I have uploaded bi
+1 To Jason's comments with Hiram's comments...
I think we should do all development of 1.1.x in branches/1.1 (with
version 1.1.N-SNAPSHOT). But at the time we code freeze for a
release, I think we should svn copy branches/1.1 to branches/1.1.N and
finalize the version numbers there (to version
On 6/21/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
Personal preference...but I think its better throwing an error. Is
"obsoleting" a settable option? I am not so sure I like obsoleting by
default...this could be ugly since it may be another app other than the
Welcome app that gets obsoleted.
Okay, then +1
--jason
On Jun 21, 2006, at 10:19 PM, David Blevins wrote:
The only thing done in a branches/x.y.z made from branches/x.y is
the release process itself. When we agree we look good enough to
cut and run, we freeze, make the branch and put together a release
candidate. At t
The distribution repos ?Well, i wanted to publish the release in a private repo so that it can be voted,and then move to public repos.I will change them back to what they were.Cheers,Guillaume Nodet
On 6/22/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
Ahh, ok. What about the other eleme
On Jun 21, 2006, at 10:53 PM, Alan D. Cabrera wrote:
David Blevins wrote:
The only thing done in a branches/x.y.z made from branches/x.y is
the release process itself.
I don't quite understand what this means. Sorry.
Referring to things like switching the version numbers, etc. The
"but
Ahh, ok. What about the other elements?
Regards,
Alan
Guillaume Nodet wrote:
When you use the maven release plugin, maven change the
scm url
to point to the tag. I will revert it to trunk asap.
Cheers,
Guillaume Nodet
On 6/22/06,
David Blevins <[EMAIL PROTECTED]>
wrote:
On Jun
65 matches
Mail list logo