On 6/14/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
I have pushed new XBean 2.4 binaries in a private repo for review.
They are available at
http://people.apache.org/~gnodet/xbean-2.4/m1/org.apache.xbean
http://people.apache.org/~gnodet/xbean-2.4/m2/org/apache/xbean
+1
John Sisson wrote:
The Derby library we are using in Geronimo does not have line number
debug information, which is useful in stack traces.
This has been addressed in the upcoming Derby 10.1.3 release by
providing a lib-debug distribution (
http://issues.apache.org/jira/browse/DERBY-178 )
John Sisson wrote:
Matt Hogstrom wrote:
The corrections applied due to license files are first in this list.
Thanks to John for dogging this.
The distributions and builds were not affected. Based on previous
feedback the vote continues. Thanks for your feedback.
*Geronimo 1.1
+1 now the alterations suggested by John have been completed.
David Blevins wrote:
+1
On Jun 19, 2006, at 8:33 AM, Matt Hogstrom wrote:
Here are the latest binaries built from
http://svn.apache.org/repos/asf/geronimo/branches/1.1.0,
http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and
Here is the current status of voting.
I know we've had several issues we had to work through wrt to licenses and other issues that have
caused some respins. At this point I think we're green for the release. Please take a few minutes
to cast your vote and we can get this release wrapped up,
Whoops...sorry I am late in the game (baby on way)...have not been
checking the lists...
+1
Matt Hogstrom wrote:
Here is the current status of voting.
I know we've had several issues we had to work through wrt to licenses
and other issues that have caused some respins. At this point I
[ https://issues.apache.org/activemq/browse/AMQ-739?page=all ]
Nathan Mittler resolved AMQ-739:
Fix Version: (was: 4.1)
Resolution: Won't Fix
Since ActiveMQ already correctly identifies TextMessages and BytesMessages
based on
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ]
Anita Kulshreshtha updated GERONIMO-2067:
-
Attachment: modules.patch
Thanks to Brett Porter! The latest release of maven-war-plugin and
maven-rar-plugin allows excluding pom.xml
+1
Gianny
Matt Hogstrom wrote:
The corrections applied due to license files are first in this list.
Thanks to John for dogging this.
The distributions and builds were not affected. Based on previous
feedback the vote continues. Thanks for your feedback.
*Geronimo 1.1 Version*
Support for inverse class loading, exclusions and non overridable classes
-
Key: XBEAN-22
URL: http://issues.apache.org/jira/browse/XBEAN-22
Project: XBean
Type: New Feature
Components:
Jason Dillon wrote:
I don't think we should keep creating so many spaces. The idea behind
having multiple spaces was to allow easier management of the
documentation as we deliver new releases of Geronimo.
I do not think we should limit the number of spaces...
If a sub-project warrants its
[ http://issues.apache.org/jira/browse/XBEAN-21?page=all ]
Guillaume Nodet updated XBEAN-21:
-
Attachment: XBEAN-21.patch
org\apache\xbean\spring\context\XmlWebApplicationContext.java does not work
[ http://issues.apache.org/jira/browse/XBEAN-22?page=all ]
Guillaume Nodet updated XBEAN-22:
-
Attachment: XBEAN-22.patch
Merge from Dain's work on Geronimo classloaders
Support for inverse class loading, exclusions and non overridable classes
Improve support for shared libraries
Key: SM-465
URL: https://issues.apache.org/activemq/browse/SM-465
Project: ServiceMix
Type: Improvement
Components: servicemix-core
Reporter: Guillaume Nodet
Fix For: 3.0
--
I noticed that my mail filters put this in my geronimo-jira folder..
I'm hoping that's why no one replied to the RTC. Going to change the
subject like a little in hopes that it gets filtered correctly and get
folks to +1 it.
On 6/19/06, Hiram Chirino [EMAIL PROTECTED] wrote:
Hi folks,
Looking
+1
On 6/21/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
Here is the current status of voting.
I know we've had several issues we had to work through wrt to licenses and
other issues that have
caused some respins. At this point I think we're green for the release.
Please take a few minutes
to
Thanks to all who voted.The release is available at http://geronimo.apache.org/xbean/dist/xbean-2.4/and has been mirrored on public repos
http://www.ibiblio.org/maven2/org/apache/xbean/xbean-spring/2.4/ (for example)I have already some patches pending, so I hope we will release a 2.5 soon.Do you
+1 (I assume we are all voting to raise the jira and proceed to
change versions in 1.1.1 and 1.2 without an additional vote)
david jencks
On Jun 21, 2006, at 2:38 AM, John Sisson wrote:
The Derby library we are using in Geronimo does not have line
number debug information, which is useful
Congratulations Joe and welcome!
david jencks
On Jun 20, 2006, at 4:47 PM, Sachin Patel wrote:
In recognition of his contributions to the Apache Geronimo
community, the Geronimo PMC is proud to announce the committership
of Joe Bohn. Joe has contributed in many areas, including the
On Jun 18, 2006, at 1:55 PM, Gianny Damour wrote:
Hi,
Is there a way to do this substitution of JACC implementation by
providing a substitutionGroup attribute to the security element?
giant snip
I think this is the best solution, although there are some problems.
It appears that
What's our strategy for the 2 active Wikis we now have?
http://wiki.apache.org/geronimo/
http://cwiki.apache.org/geronimo/
Are we moving everything from wiki over to cwiki and all new
architecture content (like building Geronimo/Devtools and the new
Plug-in architecture) should
Yes, that is the plan. Some time ago we voted to use confluence and now we are migrating the content
over cwiki. We will drop (eventually) MoinMoin once we have all the content consolidated.
Cheers!
Hernan
Donald Woods wrote:
What's our strategy for the 2 active Wikis we now have?
Expose MessageGroupMap implementation to be configurable via BrokerService
property
---
Key: AMQ-769
URL: https://issues.apache.org/activemq/browse/AMQ-769
Project: ActiveMQ
Type:
Hernan, Can you paste the command that you are trying to use? Merging is the proper approach for this type of thing. With the merge command, you can create a patch using the unified-diff output and piping it to a file. If I can see your command, I can hook you up.
Take care,JeremyOn 6/20/06,
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ]
Anita Kulshreshtha updated GERONIMO-2067:
-
Attachment: applications.patch
configs.patch
1. applications.patch - excludes pom.xml and pom.properties from war files.
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).
Thanks
Regards
- Sridhar
ps: I will try delete it from the Users group
--
View this message in context:
Hi Jeremy,
I was using a graphical tool to do the merge. The dry run would show all the files that would be
updated but when I ran it for real nothing really changed on my working, local trunk, copy.
I did an svn stat and saw no changes, did an svn up and it failed. Can't remember exactly the
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 zipped up geronimo/tomcat server with liferay
already deployed. I had some problems starting a fresh install of this
distribution due to
Classpath modifications by bootstrap are not handled
Key: SM-466
URL: https://issues.apache.org/activemq/browse/SM-466
Project: ServiceMix
Type: Bug
Components: servicemix-core
Versions: 3.0-M2
Hernan, Glad to hear you got it working. As for the command-line way:svn merge [EMAIL PROTECTED] [EMAIL PROTECTED] PATH_TO_WORKING_COPY_YOU_WISH_TO_MERGE_CHANGES_INTO
Sorry for the weird looking command but I tried to put some useful tidbits into the command. ;)Take care,JeremyOn 6/21/06, Hernan
Classpath modifications at installation time should be persisted somehow
Key: SM-467
URL: https://issues.apache.org/activemq/browse/SM-467
Project: ServiceMix
Type: Bug
Components:
[ https://issues.apache.org/activemq/browse/SM-466?page=all ]
Guillaume Nodet resolved SM-466:
Resolution: Fixed
Assign To: Guillaume Nodet
Author: gnodet
Date: Wed Jun 21 12:16:31 2006
New Revision: 416076
URL:
On Tue, Jun 20, 2006 at 10:47:50AM -0400, Sachin Patel wrote:
In recognition of his contributions to the Apache Geronimo community,
the Geronimo PMC is proud to announce the committership of Joe Bohn.
Joe has contributed in many areas, including the console and as of
recent, the work on
I don't like the idea of having multiple apps mapped to the same context
path/root.
It sounds like liferay needs to be modified to properly path to resources.
This may be a major development, but any production level site should really
support whatever context path the user wants to select,
[ https://issues.apache.org/activemq/browse/AMQ-764?page=all ]
shahzad bhatti closed AMQ-764:
--
Resolution: Fixed
I tried 4.0.1 and am no longer see out-of-memory. Can you explain what was
changed between 4.0-RC2 and 4.0.1 to fix this.
Getting
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 zipped up geronimo/tomcat server with liferay
already deployed. I had some problems starting a fresh install of
Paul,
David Jencks wrote a GBean to do mostly what your looking for. If you look in
applications/daytrader/derby you'll find how the database is predefined for derby. In the DayTrader
plan built in configs/daytrader/src/plan/target/plan.xml you'll find an entry in the deployment plan
the
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
plugin with that name. If the user creates a custom database pool
named LiferayDatabase then the Liferay
On Jun 21, 2006, at 10:47 AM, Donald Woods wrote:
What's our strategy for the 2 active Wikis we now have?
http://wiki.apache.org/geronimo/
http://cwiki.apache.org/geronimo/
Are we moving everything from wiki over to cwiki and all new
architecture content (like building
I think this is complicated by the fact that we split out the trunk
and branch after the fact (basically moved trunk to branch and
recreated trunk by copying from a previous revision.
I think the way to do the merge would be to generate a diff between
the revision we copied to trunk (I forget
Following up off-list to track down the tool.
Thanks,
Aaron
On 6/21/06, Hernan Cunico [EMAIL PROTECTED] wrote:
Aaron, IIRC some time ago you mentioned a tool for migrating MoinMoin to
Confluence, do you have it
available for download somewhere?
I think it would be better to migrate the
FYI:
http://confluence.atlassian.com/display/CONFEXT/MoinMoin+importer
There is also:
http://confluence.atlassian.com/display/CONFEXT/Universal+Wiki
+Converter
Not sure well either work though.
--jason
On Jun 21, 2006, at 3:24 PM, Hernan Cunico wrote:
Aaron, IIRC some time ago
Here is the current status of voting ... only 12 hours left.
+1 from PMC Members
Davanum Srinivas
Gianny D'Amour
Sachin P. Patel
*PMC Members who have not voted:*
Geir Magnusson Jr.
Greg Wilkins
Jacek Laskowski
Jan Bartel
John R. Sisson
(I believe your +1 in the thread was to keep the vote
+1 to release.
John
Matt Hogstrom wrote:
Here is the current status of voting.
I know we've had several issues we had to work through wrt to licenses
and other issues that have caused some respins. At this point I think
we're green for the release. Please take a few minutes to cast your
After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1
branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that
branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the
+1
--kevan
On Jun 20, 2006, at 6:15 PM, Matt Hogstrom wrote:
The corrections applied due to license files are first in this
list. Thanks to John for dogging this.
The distributions and builds were not affected. Based on previous
feedback the vote continues. Thanks for your feedback.
Matt Hogstrom wrote:
After the branches/1.1 was moved to tags there was some question as to
what happened to the 1.1 branch. At that time some kind soul created
a new branches/1.1.1. No activity has occurred in that branch and
given that we'll need to define the release goals of 1.1.1 soon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
+0
- --
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
Millennium hand and shrimp!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG
Why would a branch get moved to a tag? Why do we need branches
for revisions? Why are we deleting branches?
IMO, we should have a branch for each Major.Minor, where all of the
Major.Minor.Revision work happens. So branches/1.1 would hold the
active work for 1.1.x. When it is time to
+0
I have not had time to play with the release, but I am not against
getting the release out. So for those that have reviewed and gave a
+1 I trust them.
--jason
On Jun 21, 2006, at 2:20 AM, Matt Hogstrom wrote:
Here is the current status of voting.
I know we've had several issues
On 6/21/06, Jason Dillon [EMAIL PROTECTED] wrote:
Why would a branch get moved to a tag? Why do we need branches
for revisions? Why are we deleting branches?
IMO, we should have a branch for each Major.Minor, where all of the
Major.Minor.Revision work happens. So branches/1.1 would hold the
Hi Jason,
I agree that we should avoid branching. But I do agree with the 1.1.1
branch. It's a dead-end branch in that it's only used to prepare he
release. Applying last minute fixes and changing version numbers.
Since it's a dead-end branch, once the release if approved
moving/deleting it
Aaron Mulder wrote:
One is that you can declare a database pool dependency named
LiferayDatabase or whatever. Then provide a Derby database pool
plugin with that name. If the user creates a custom database pool
named LiferayDatabase then the Liferay plugin will map to that,
whatever it
I think your right if nothing needs to change. IIUC there is a general preference for tags being
pristine with no modifications. So, if a release can go from being worked to a good release then
the Maven system is great. I think the reality is that there will generally be the time required to
Hi Jason,
The problem is that it can take weeks to do a geronimo release since
stuff like CTS testing is involved. So the release work (putting the
finishing touches) needs to be done in a branch so that work can
continue on the next release.
Perhaps m2 has a way of dealing with those issues
Hi Jason,
Hiya :-)
The problem is that it can take weeks to do a geronimo release since
stuff like CTS testing is involved. So the release work (putting the
finishing touches) needs to be done in a branch so that work can
continue on the next release.
I would hope that most if not all of
I think your right if nothing needs to change. IIUC there is a
general preference for tags being pristine with no modifications.
Generally I agree with this.
So, if a release can go from being worked to a good release then
the Maven system is great. I think the reality is that there will
According to the maven guys, the release process is:
* deploy snapshot
* vote on snapshot
* build and deploy a release
Currently the m2 release process (if you use the release plugin is): * change all versions in poms and commit * create a tag * release and deploy from tag * revert to
On Jun 21, 2006, at 5:18 PM, Jason Dillon wrote:
Hi Jason,
I agree that we should avoid branching. But I do agree with the
1.1.1
branch. It's a dead-end branch in that it's only used to prepare he
release. Applying last minute fixes and changing version numbers.
Since it's a dead-end
+1
Joe
Matt Hogstrom wrote:
The corrections applied due to license files are first in this list.
Thanks to John for dogging this.
The distributions and builds were not affected. Based on previous
feedback the vote continues. Thanks for your feedback.
*Geronimo 1.1 Version*
*Source*
IIUC, version specific information has snuck into elements that should
be version free, e.g. scm. Here is a list of elements that should
have version information removed:
scm
build...remoteRepositoryUrl
distributionManagment
Regards,
Alan
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. branches/x.y would be the
On Jun 21, 2006, at 6:37 PM, Alan D. Cabrera wrote:
IIUC, version specific information has snuck into elements that
should be version free, e.g. scm. Here is a list of elements
that should have version information removed:
scm
build...remoteRepositoryUrl
distributionManagment
Not
David Blevins wrote:
On Jun 21, 2006, at 6:37 PM, Alan D. Cabrera wrote:
IIUC, version specific information has snuck into elements that
should be version free, e.g. scm. Here is a list of elements that
should have version information removed:
scm
build...remoteRepositoryUrl
+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 evenly across the board when
fixes were checked into one branch. This is one reason why the versions
drifted so wildly apart.
Dain Sundstrom wrote:
On Jun 16, 2006, at 2:35 PM, David Jencks wrote:
--- Dain Sundstrom [EMAIL PROTECTED] wrote:
I have two thoughts:
1) we have an automated tool to track patches and it
can track votes
and send out these reports.
I'm not convinced automating this will work all that
On Jun 21, 2006, at 7:05 PM, Alan D. Cabrera wrote:
David Blevins wrote:
On Jun 21, 2006, at 6:37 PM, Alan D. Cabrera wrote:
IIUC, version specific information has snuck into elements that
should be version free, e.g. scm. Here is a list of elements
that should have version
[
http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12417233
]
David Jencks commented on GERONIMO-1563:
sorry for the delay. Can you be more specific about the problems you find? I
regard this as a fairly small feature and
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83?page=all ]
Donald Woods updated GERONIMODEVTOOLS-83:
-
Summary: Build fails for plugin org.apache.geronimo.st.v11.ui (was:
Build fails for plugin org.apache.geronimo.st.v1.core)
[
http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12417235
]
Alan Cabrera commented on GERONIMO-1563:
I did a fresh checkout of Geronimo and OpenEJB trunk/openej2 and fed the
patches in and got errors.
I also see in your
+1
-dain
On Jun 21, 2006, at 7:06 PM, 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 evenly across the board
when fixes were checked into one branch. This
+1
On 6/21/06, Alan D. Cabrera [EMAIL PROTECTED] 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 evenly across the board when
fixes were checked into one branch. This is one
[
http://issues.apache.org/jira/browse/GERONIMO-2135?page=comments#action_12417237
]
Gianny Damour commented on GERONIMO-2135:
-
I had a look to the patch and vote +1 for it. Some more details:
1. is fixed.
2. is not fixed.
3. is partially fixed
4.
+1 Look great!
I tried it out all 4 binaries in a path containing spaces, and
installed a few plugins from the cli, console and examples.
Sorry it took me so long,
-dain
On Jun 21, 2006, at 2:20 AM, Matt Hogstrom wrote:
Here is the current status of voting.
I know we've had several
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:
John Sisson wrote:
Some notes in relation to documentation:
* Clicking on the the Geronimo
David,
Thanks for that excellent recap.
+1 from me.
+1 to Alan's comment that all patches to branches should also be
applied to the trunk. Any future x.(y+1) branch should come from the
trunk and not from the recently frozen x.y.z branch.
Cheers
Prasad
On 6/21/06, Hiram Chirino [EMAIL
Does this mean that the bulk of changes will be done on M.m branches
and only release + minor changes done on M.m.r branches?
--jason
On Jun 21, 2006, at 6:52 PM, David Blevins wrote:
We had this whole conversation last week, lots of good discussion was
had. I'd prefer not to have to have
Hi everyone,
It's great to see the traction going on in the Geronimo world. Just signed up
for the dev list so I'm happy to participate.
In our next release of Liferay 4.1.0, we'll:
1.) Upgrade to the latest Geronimo 1.1 (even if it's just a pre zip until 1.1
gets voted final).
2.) Use Derby
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 the point of the freeze the release manager owns the
branches/x.y.z till the
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.
When we agree we look good enough to cut and run, we freeze, make the
branch and put together a release candidate. At the
Sachin Patel wrote:
In recognition of his contributions to the Apache Geronimo community,
the Geronimo PMC is proud to announce the committership of Joe Bohn.
Joe has contributed in many areas, including the console and as of
recent, the work on our minimal distributions.
His work shows
[ https://issues.apache.org/activemq/browse/AMQ-755?page=all ]
Rob Davies reassigned AMQ-755:
--
Assign To: Rob Davies
possible bug with temporary queues and networks?
Key: AMQ-755
URL:
HI,
I am in the hunt of an Open source MOM ... I am not sure which one is widely
popular and best.
Kindly suggest a location which could give me a comparison for the various
open source MQ options available. It should have C++ support.
Can anybody tell me why we should use ActiveMQ ... what
+1 ! BTW IMO the spec is still fuzzy. I think they need to clarify
it a bit more. But I think it's something we should be able to
implement really easy.
On 6/20/06, Brian McCallister [EMAIL PROTECTED] wrote:
FYI: http://www.infoq.com/news/amq
AMQP looks to be an attempt at wire protocol
84 matches
Mail list logo
