Hi James.Strachan,
I am working cms(ActiveMQ-4.0) code on SuSe(Linux machine-
i686-suse-linux, version 2.6.13-15.8-default)
You refer me to use Queue to mentain the persistence in the cms code, but
this is Outstanding Item
[
https://issues.apache.org/activemq/browse/AMQ-406?page=comments#action_36488 ]
Hiram Chirino commented on AMQ-406:
---
Fixed in trunk rev 418495.
You can now configure the prefetchPolicy and redeliveryPolicy using the jndi
properties. For example:
[ https://issues.apache.org/activemq/browse/AMQ-450?page=all ]
Hiram Chirino updated AMQ-450:
--
Fix Version: 4.2
(was: 4.1)
Description: This could take a little bit of work reorganizing how the
broker and the persistence store
[ https://issues.apache.org/activemq/browse/AMQ-451?page=all ]
Hiram Chirino updated AMQ-451:
--
Fix Version: 4.2
(was: 4.1)
scheduling delivery of messages is very similar to expiring messages on a given
date. Lets thing about how to
WireFormatNegotiator could hang a client or server connection if the peer
disconnects before sending the wire format info
-
Key: AMQ-789
URL:
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ]
Hiram Chirino updated AMQ-608:
--
Fix Version: 4.0.2
(was: 4.0.1)
Change logging level of some DemandForwardingBridge log messages.
[ https://issues.apache.org/activemq/browse/AMQ-528?page=all ]
Hiram Chirino updated AMQ-528:
--
Fix Version: 4.0.2
4.1
(was: 4.0 RC2)
Version: 4.0
(was: 4.0 M4)
Ajusted target fix version so
[
https://issues.apache.org/activemq/browse/AMQ-725?page=comments#action_36492 ]
William MacDonald commented on AMQ-725:
---
I have tested this with the new 4.01 release of ActiveMQ using the default
configuration file and I am still having the problem.
Howdy STOMP developers,
Just wantted to let you know that I spent the day doing some major
refactoring to the STOMP server side protocol implementation in ActiveMQ.
The previous implementation did all the work inside a WireFormat layer. The
poll model that it imposed made some things difficult
Why can't the dependency plugin be used to install the car files?
I'm not sure what you mean by the dependency plugin.
http://mojo.codehaus.org/dependency-maven-plugin/
It basically handles copying (or unpacking) artifacts and their
dependencies to somewhere other than the repo cache.
I
This is only for bootstrapping the server then?
It would be very good to eliminate this configuration.
Better IMO to just soak up everything in lib/*.jar.
--jason
On Jun 30, 2006, at 11:47 PM, David Jencks wrote:
On Jun 30, 2006, at 9:31 PM, Jason Dillon wrote:
Can someone please explain
[
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12418775
]
Jason Dillon commented on GERONIMO-2161:
FYI, there is also related work to clean up dependency configuration in all
modules. In many places modules re-specify
Why not?
--jason
Why?
--jason
Why?
--jason
These are also missing pom.xmls:
configs/remote-deploy-jetty
configs/remote-deploy-tomcat
configs/uddi-jetty
configs/uddi-tomcat
Why?
--jason
SVN changes that are associated with a JIRA should include the JIRA
id (exact case) so that JIRA can link back to the changes.
--jason
On Jun 30, 2006, at 6:56 PM, John Sisson wrote:
In the Re: [RTC] Clarification please from the PMC thread I
raised some issues regarding documenting
Rename all modules to match the artifactId defined in the module's pom.xml
--
Key: GERONIMO-2162
URL: http://issues.apache.org/jira/browse/GERONIMO-2162
Project: Geronimo
Type: Task
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
Jason Dillon updated GERONIMO-2161:
---
Attachment: GERONIMO-2161-v1.patch
GERONIMO-2161-v1 patch removed the mentioned bits from the root pom.xml and
adds the required bits to to child
Call me crazy, but cant we have a build.bat and build.sh in the root
directory that executes the multi-stage builds (modules, plugins,
OpenEJB if present, apps, assemblies, etc.)?
Thanks,
Aaron
On 6/30/06, Jason Dillon [EMAIL PROTECTED] wrote:
I also think we need another pre-stage that
Sure, I was going to add that, as well as update the README.txt...
pending approval of the changes.
That script would just facilitate the multi-stage build... and is not
intended to be a replacement for invoking mvn directly.
BUT, we can use build[.bat] to provide users with a one command
It's old code and should be removed.
Thanks,
Aaron
On 7/1/06, Jason Dillon [EMAIL PROTECTED] wrote:
Why not?
--jason
Sweet... I love to remove stuff :-)
--jason
On Jul 1, 2006, at 3:04 AM, Aaron Mulder wrote:
It's old code and should be removed.
Thanks,
Aaron
On 7/1/06, Jason Dillon [EMAIL PROTECTED] wrote:
Why not?
--jason
On 6/30/06, Jason Dillon [EMAIL PROTECTED] wrote:
BUT the point that I was making was that Maven must resolve the
plugin before the build commences... that means that the plugin must
exist in a repository (or cache) already, and that is the version
that will be used for the current build
On 7/1/06, Jason Dillon [EMAIL PROTECTED] wrote:
Why?
Never written?
See http://issues.apache.org/jira/browse/GERONIMO-2067
--jason
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
On 7/1/06, Aaron Mulder [EMAIL PROTECTED] wrote:
It's old code and should be removed.
+1 for the removal.
Aaron
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Hi
I'm working on a simple sample J2EE application which contains
JSP,struts and ejb with mysql-plan.xml in Geronimo 1.1-jetty.I'm
trying to build the sample application using maven and I have attached
the maven.xml and build error bottom.
For the above application following are deployment
* * * * * * * * * * * * * * * * * * * * * * * * * * *
1 WEEK (5 issues)
* * * * * * * * * * * * * * * * * * * * * * * * * * *
Key Summary
ReporterCreated
GERONIMO-2160 Can`t install a J2EE connector
We do not have poms for tomcat jars. We have managed so far without
them. It appears that m. assembly pluign is refusing for work without
them. May be Jeff can help with this.
Thanks
Anita
--- David Jencks [EMAIL PROTECTED] wrote:
OK, I got further. actually into the assembly.
I can probably create some basic poms for them and push em out.
anita kulshreshtha wrote:
We do not have poms for tomcat jars. We have managed so far without
them. It appears that m. assembly pluign is refusing for work without
them. May be Jeff can help with this.
Thanks
Anita
---
Jeff,
THANKS!
Anita
--- Jeff Genender [EMAIL PROTECTED] wrote:
I can probably create some basic poms for them and push em out.
anita kulshreshtha wrote:
We do not have poms for tomcat jars. We have managed so far
without
them. It appears that m. assembly pluign is refusing for
Hi,
After OpenEJB jars have been published and added two deps to
configs/client/project.xml, I could build Geronimo on a clean
environment with Maven *1*, just-checked-out sources and ~/.maven
removed.
The steps are as follows:
$ rm -rf ~/.maven
$ rm -rf geronimo
$ svn co
Never written... or maybe not used, or moved...
Wasn't daytrader moved out of the main tree?
--jason
On Jul 1, 2006, at 3:33 AM, Jacek Laskowski wrote:
On 7/1/06, Jason Dillon [EMAIL PROTECTED] wrote:
Why?
Never written?
See http://issues.apache.org/jira/browse/GERONIMO-2067
--jason
Anyone know how many of the 22 issues that are older than a year are
still valid?
Also... why is the formatting for this all whacked up? Kinda hard to
grok.
--jason
* * * * * * * * * * * * * * * * * * * * * * * * * * *
OLDER THAN 1 YEAR (22 issues)
* * * * * * * * * * * * * * * * *
On 7/1/06, Jason Dillon [EMAIL PROTECTED] wrote:
Never written... or maybe not used, or moved...
Wasn't daytrader moved out of the main tree?
Yes, it was - https://svn.apache.org/repos/asf/geronimo/daytrader
--jason
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
So does that mean that the configs/daytrader-jetty module in trunk is
no longer used and should be nuked ( dropped, removed, deleted,
consigned to the void, dropped into the empty abyss of nothing, ... :-
P )?
--jason
On Jul 1, 2006, at 11:13 AM, Jacek Laskowski wrote:
On 7/1/06, Jason
Is there any reason why a rebuild (with no clean) would cause errors
like this:
snip
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO]
No...that is the configuration that handles the plan.
Jason Dillon wrote:
So does that mean that the configs/daytrader-jetty module in trunk is no
longer used and should be nuked ( dropped, removed, deleted, consigned
to the void, dropped into the empty abyss of nothing, ... :-P )?
--jason
Does this need to live in the trunk? Seems that it would make more
sense in the daytrader tree.
--jason
On Jul 1, 2006, at 11:38 AM, Jeff Genender wrote:
No...that is the configuration that handles the plan.
Jason Dillon wrote:
So does that mean that the configs/daytrader-jetty module in
I think Matt H should probably decide on that.
Jason Dillon wrote:
Does this need to live in the trunk? Seems that it would make more
sense in the daytrader tree.
--jason
On Jul 1, 2006, at 11:38 AM, Jeff Genender wrote:
No...that is the configuration that handles the plan.
Jason
On 7/1/06, Jason Dillon [EMAIL PROTECTED] wrote:
Is there any reason why a rebuild (with no clean) would cause errors
like this:
snip
[INFO]
[ERROR] BUILD ERROR
[INFO]
My gut still tells me that CAR files should go the way of the Dodo.
W/o CAR's the number of modules for the build is reduced close to
half, which is a massive simplification IMO. Also seems that w/o
CARs then we don't need our custom build plugins, which is another
significant
On 7/1/06, Jeff Genender [EMAIL PROTECTED] wrote:
I think Matt H should probably decide on that.
Sure, but before he approaches it we can propose something, right?
It's a community matter nor Matt's (don't you want to get rid of RTC?
:-))
I think Jason's right as we don't need to maintain
This happens during the m2 build... and actually the build ends up
cycling between 2 errors, this one and another that is an internal
plugin error regarding some JCL classes...
:-(
At least it appears to switch back and forth between these two errors
and is not completly random... but
(From Seinfeld...picture George saying Whoa...back
up...BEEP...BEEP...BEEP) ;-)
I think we were discussing it, I think Jason and I both said something
about it...and I simply stated that I would get Matt's signoff to a
certain degree since it was his component to begin with...just my opinion.
Is
[
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12418806
]
Jason Dillon commented on GERONIMO-2161:
Forgot, also adds configuration to build module-linked project for IDEA using
the correct JDK.
[RTC] Remove Geronimo
This helped us ensure that we always have a clean environment for
the configuration being packaged. As soon as we have our first server
that starts, this restriction will be removed.
Thanks
Anita
--- Jason Dillon [EMAIL PROTECTED] wrote:
Is there any reason why a rebuild (with no clean)
The packaging plugin needs to be made to do a clean first, the m1
plugin did this with jelly.
I always run mvn -o clean install inside configs, which is annoying,
but I haven't had time to investigate how to do clean from within
an m2 plugin. Maybe you or someone else knows how?
thanks
Inline -
On 6/30/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
inline..
--- Prasad Kashyap [EMAIL PROTECTED] wrote:
1. Our pom.xml first lists all and only geronimo modules, configs and
apps as dependencies. The transitive deps are taken care of by m-a-p.
In a perfect M2 world just
On 7/1/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
After OpenEJB jars have been published and added two deps to
configs/client/project.xml, I could build Geronimo on a clean
environment with Maven *1*, just-checked-out sources and ~/.maven
removed.
The fix has been committed in Revision
FYI, re-adding the JCL dependency fixes one of the problems...
--jason
On Jul 1, 2006, at 12:17 PM, Jason Dillon wrote:
This happens during the m2 build... and actually the build ends up
cycling between 2 errors, this one and another that is an internal
plugin error regarding some JCL
The m-a-p is invoked twice for the following reasons:
When we copy some modules into a m2 repo structure format, it also
copies the META-INF/maven/.. directories. This unneccesary directory
introduces a very long path too. So in the first execution, we use the
intermediaryAssembly to skip the
We can exclude META-INF/maven/ from the jars by configuring the
jar plugin to use addMavenDescriptorfalse/... I have not used it,
but it should work.
Thanks
Anita
--- Prasad Kashyap [EMAIL PROTECTED] wrote:
The m-a-p is invoked twice for the following reasons:
When we copy some
Um, why would we want to do that? IMO the descriptors are a good
thing and I do not recommend that we turn that off as a bandaid for
another problem.
--jason
On Jul 1, 2006, at 1:39 PM, anita kulshreshtha wrote:
We can exclude META-INF/maven/ from the jars by configuring
the
Any idea what this is about?
snip
[INFO]
[INFO] Building Geronimo Configs :: Axis Deployer
[INFO]task-segment: [install]
[INFO]
FYI, this in the configs/pom.xml should do the trick:
build
plugins
!--
| NOTE: Currently to build CAR files, we need to
ensure that the module has been cleaned first
| otherwise the second time around the build
will fail.
Jason Dillon wrote:
Please read the JIRA for details:
http://issues.apache.org/jira/browse/GERONIMO-2161
--jason
It seems reasonable to me.
IIRC, this was originally set up by Mr. MavenHead himself. Might want
to run this by him to see what he was originally thinking.
+1 - pending a
Aight... well lets get it working asis for now...
I think we don't need to run the assembly plugin twice to get to the
same place, but we can fix that once something is working.
--jason
On Jul 1, 2006, at 1:23 PM, Prasad Kashyap wrote:
The m-a-p is invoked twice for the following
The only advantage of listing internal modules in
dependencyManagement is so that you don't need to include the version
and/or type where its referenced. That seems like a good idea, but
in practice it adds more complexity to the configuration and more on
going maintenance and coupling of
Jason, who are you replying to? You accidentally cut out the person's name.
Regards,
Alan
Jason Dillon wrote:
I agree with your comments but I also recognize that it is a slippery
slope. Who is responsible for tracking the changes and lobbying the
other groups? My limited experience tells
John Sisson wrote:
* The code in svn should always build. During the development of 1.0
and 1.1 there were long periods of time where builds were broken due
to people committing code without doing a build to test it. In some
cases the developer may have done a build and it was successful,
Ooops... I got trim happy. This was a reply to Matt.
--jason
On Jul 1, 2006, at 2:05 PM, Alan D. Cabrera wrote:
Jason, who are you replying to? You accidentally cut out the
person's name.
Regards,
Alan
Jason Dillon wrote:
I agree with your comments but I also recognize that it is a
There was/is some bits on gbuild that is using Continuum... but I'm
unsure at this time how trustworthy the setup is (ie. can we trust
that a failure notice is really something broke or just something
transient).
Once the m2 build is square we should get a concrete CI setup to help
avoid
John Sisson wrote:
One of the issues I see with the current process we have for changes
under RTC is that it is hard to keep track of what patches are pending
RTC.
Ken suggested that we reintroduce the STATUS file as a way of keeping
track of the status of patches (
I am adamantly against pulling in code from a CodeHaus repository when
I do a co from an ASF repo. Do I understand the proposed behavior
correctly?
Regards,
Alan
Jason Dillon wrote:
I'd just like to know why you are really, really against
it?
I don't like it, but as a short-term
GERONIMO-1234-FixNPE-v1
GERONIMO-1234-FixNPE-v2 (second attempt at patch)
GERONIMO-3421-v1
Why should a patch that has been attached to a specific Jira issue
include the number of the jira issue? I don't mind but it seems
odd and usually that means that I am misunderstanding
On 7/1/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
I am adamantly against pulling in code from a CodeHaus repository when I do
a co from an ASF repo. Do I understand the proposed behavior correctly?
You're right. I didn't think about it this way - they're two separate
(legal) entities and
On 7/1/06, Jason Dillon [EMAIL PROTECTED] wrote:
Any idea what this is about?
...
Unable to resolve dependency activecluster/activecluster//jar
Just a guess (again today), but I saw something alike when I was
looking into the m1-based build and the solution was to add
dependencies to a
I see your point. Thanks for the explanation.--jasonOn Jul 1, 2006, at 2:31 PM, Alan D. Cabrera wrote: I am adamantly against pulling in code from a CodeHaus repository when I do a co from an ASF repo. Do I understand the proposed behavior correctly? Regards, Alan Jason Dillon wrote: I'd
On 7/1/06, Jason Dillon [EMAIL PROTECTED] wrote:
Is anyone using these extra profiles:
They've been used very extensively when we first worked on the m2
build. It helped with build only one module from the top-level
directory. I don't know whether it's used or not nowadays, but I don't
mind if
Seems like other stuff is also missing:
Unable to resolve dependency axion/axion//jar
Where are these coming from?
--jason
On Jul 1, 2006, at 3:10 PM, Jacek Laskowski wrote:
On 7/1/06, Jason Dillon [EMAIL PROTECTED] wrote:
Any idea what this is about?
...
Unable to resolve
Ug I give up. I keep adding a dependency and then find another
that is missing...
And now it complains about:
Unable to resolve dependency geronimo/geronimo-timer/1.2-
SNAPSHOT/jar
Which looks like an old groupId.
Where are these dependencies coming from? Where is this
On Jul 1, 2006, at 2:14 PM, Jason Dillon wrote:
Bummer... highly sucky that we must clean to make a build. Stuff
like this negates some of the intelligence the build uses to reduce
the amount of work (and time to execute).
In general I recommend that a normal build never need to clean,
yikes the dependencies need a lot of work axis and axis deployer
don't need openejb
Anyway I think the problem comes from using m1 built openejb jars
that have geronimo-dependency.xml files inside for the m1 groupIds.
I think the problem will go away if you build openejb with m2.
I do not believe that their are m2 builds of openejb to get us the
right SNAPSHOT versions we need... so if we need to openejb jars
built from m2, then we need to get the CI build up using m2 and
deploying so that G can use em.
--jason
On Jul 1, 2006, at 3:55 PM, David Jencks wrote:
Jason Dillon wrote:
2. Not all communication regarding the fix is done in JIRA comments,
therefore people reviewing the fix have to search the mailing lists
and JIRA reducing the amount of time they have to actually review the
change. This also makes it harder for people in the future who
[
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12418816
]
Jason Dillon commented on GERONIMO-2161:
FYI, this should be relatively easy to validate.
Setup a workspace and apply the patch:
{noformat}
wget
AFAIK, it has never changed from having three binding +1 votes from the
PMC, which is why there is an issue with a bottleneck processing RTCs
due to the size of the PMC.
It may not have been clearly communicated that that is how RTC works.
See Ken's comment in
Alan D. Cabrera wrote:
John Sisson wrote:
One of the issues I see with the current process we have for changes
under RTC is that it is hard to keep track of what patches are
pending RTC.
Ken suggested that we reintroduce the STATUS file as a way of keeping
track of the status of patches (
Here is why we had to exclude them from the wars and rars -
http://www.nabble.com/M2-%3A-build-on-Windows-tf1803375.html#a4914787
Cheers
Anita
--- Jason Dillon [EMAIL PROTECTED] wrote:
Um, why would we want to do that? IMO the descriptors are a good
thing and I do not recommend that we
[ http://issues.apache.org/jira/browse/GERONIMO-592?page=all ]
John Sisson closed GERONIMO-592:
Resolution: Cannot Reproduce
Startup failure in Turkish language settings
Key: GERONIMO-592
[
http://issues.apache.org/jira/browse/GERONIMO-592?page=comments#action_12418821
]
John Sisson commented on GERONIMO-592:
--
Gorkem, can you please verify whether this problem still exists in the 1.1
release and if so provide more detailed error
Hi David..That's still work that I've got on my plate to do. The # of gbeans have changed for activemq 4. So before we switch to amq 4 and the new gbean modules, I'll have to update lots of plans. Including the ones in the CTS I imagine.
Regards,HiramOn 6/30/06, David Jencks [EMAIL PROTECTED]
Whoa!I think we have been operation under a different assumption. I know I committed a patch when 1 got 3 committer +1s... And not even 1 PMC member looked at it. And that took over a week to garner enough votes. Imagine how long it would take if we had to get 3 PMC +1! I think we need to clear
84 matches
Mail list logo
