[ https://issues.apache.org/activemq/browse/SM-468?page=all ]
Guillaume Nodet resolved SM-468:
Fix Version: 3.0
Resolution: Fixed
Assign To: Guillaume Nodet
Author: gnodet
Date: Wed Jun 21 23:35:16 2006
New Revision: 416269
URL: http://s
When you use the maven release plugin, maven change the scm urlto point to the tag. I will revert it to trunk asap.Cheers,Guillaume NodetOn 6/22/06,
David Blevins <[EMAIL PROTECTED]> wrote:
On Jun 21, 2006, at 6:37 PM, Alan D. Cabrera wrote:> IIUC, version specific information has snuck into ele
I don't quite understand what you are asking. Can you rephrase?
Regards,
Alan
Jason Dillon wrote:
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 ha
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 init
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 point
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
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
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
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 PROT
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 Do
+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 issue
[
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. i
+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 r
+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 i
[
http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12417236
]
Alan Cabrera commented on GERONIMO-1563:
BTW, this is not a small trival change that you are proposing.
> Make the JACC implementation pluggable
>
[
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 co
[ 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)
E
[
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 t
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. . Here is a list of elements
that should have version information re
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
we
+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.
Regards,
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. . Here is a list of elements that
should have version information removed:
...
Not sure how this got there, it should
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. . Here is a list of elements
that should have version information removed:
...
Not sure how this got there, it should point to trunk
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 branch
IIUC, version specific information has snuck into elements that should
be version free, e.g. . Here is a list of elements that should
have version information removed:
...
Regards,
Alan
+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*
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 bran
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 sn
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
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 t
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 al
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
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,
> whatev
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 ma
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
+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 we
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
-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
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 I'
We now have the web site updated with the content from the trunk so the merge
is behind.
I have a question though, we did not have branches for the web site before, just a "main" trunk.
What would be the criteria from now on to update the web site? There were updates to the web site
directly o
+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.
*
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 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
v
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
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 yo
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
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 whi
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 entire MoinMoin wiki into a separate Confluence space and
do the "cleaning" directly from Confluence.
Cheers!
Hernan
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 Geronim
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 pl
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 cop
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
[ 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 Outof
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, ra
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
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: servicemix
[ 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: http://svn.apache.org/viewvc?re
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, Hern
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
Rep
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 hsql
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
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:
http:
[ 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.
2
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,
Expose MessageGroupMap implementation to be configurable via BrokerService
property
---
Key: AMQ-769
URL: https://issues.apache.org/activemq/browse/AMQ-769
Project: ActiveMQ
Type: Improv
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?
http://w
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
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?
I think this is the best solution, although there are some problems.
It appears that substitution grou
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
conso
+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 in
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 y
+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
t
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,
Lookin
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
--
[ 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
> --
[ 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
> -
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
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: server
+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*
*Sour
[ 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 and
[ 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 content-lengt
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 t
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, 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
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 Version*
+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 ) .
86 matches
Mail list logo