[jira] Commented: (AMQ-734) Network connections do not reconnect when using static: with failover=true
[ https://issues.apache.org/activemq/browse/AMQ-734?page=comments#action_36274 ] Rob Davies commented on AMQ-734: the reason for the fixed client_id is durable topic consumers. The network bridge amalgamates multiple durable subscribers on the same topic in to one durable subscriber - to avoid duplicates and improve performance. There is a keep alive protocol used with the tcp connector that should detect the network outage - needs some more investigation to see why this doesn't appear to be working Network connections do not reconnect when using static: with failover=true -- Key: AMQ-734 URL: https://issues.apache.org/activemq/browse/AMQ-734 Project: ActiveMQ Type: Bug Components: Connector Versions: 4.0 Environment: winxp java1.5.6 Reporter: tao Priority: Critical Fix For: 4.0.1 If I pull out RJ45 port from net card ,waiting a time ,then put RJ45 port net card .Network is resume.Other computer always throw errors and net channel can't work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
For documentation of ActiveMQ
Hi all, I am New for this ActiveMQ. I wants to write c++ client and I wants to attache a sever to ActiveMQ for acheving these thing I wants the documentation for ActiveMQ. So please help me Thanks in advance Regards Arashad Ahamad
[jira] Created: (AMQ-744) add a vmstat agent to the maven activemq performance plugin so we can track the CPU, IO, RAM use on the machine we are running the test on
add a vmstat agent to the maven activemq performance plugin so we can track the CPU, IO, RAM use on the machine we are running the test on Key: AMQ-744 URL: https://issues.apache.org/activemq/browse/AMQ-744 Project: ActiveMQ Type: Improvement Components: Performance Test Reporter: james strachan Assigned to: Adrian Co Fix For: 4.1 When running a performance test it would be good to spawn off a process to run 'vmstat' which works on linux and solaris (the flags may differ etc) which outputs the amout of CPU use in system/user code and how much is idle together with RAM IO numbers. I'd be good to include in each snapshot whatever vmstat numbes we can find so we can see how the box was doing as the test was running. e.g. sample index=5 ... machine cpuSystem=50 cpuUser=25 cpuIdle=25 ram=44 io=1000/ /sample Note that we may wanna make a few different machine monitoring agents using different tools - so lets make it pluggable - let 'em write whatever XML they can - though we should be able to get linux and solaris done (linux only would be fine for now) To call vmstat we'll need to do a System.exec() then parse the results etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-448) Allow to provide a wsdl instead of generating one
Allow to provide a wsdl instead of generating one - Key: SM-448 URL: https://issues.apache.org/activemq/browse/SM-448 Project: ServiceMix Type: Improvement Components: servicemix-jsr181 Reporter: Guillaume Nodet Fix For: 3.0-M2 This is necessary for wsdl design first development -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2096) PluginInstallerGBean.updatePluginMetadata(..) may leave geronimo-plugin.xml file open
[ http://issues.apache.org/jira/browse/GERONIMO-2096?page=all ] John Sisson reassigned GERONIMO-2096: - Assign To: John Sisson PluginInstallerGBean.updatePluginMetadata(..) may leave geronimo-plugin.xml file open - Key: GERONIMO-2096 URL: http://issues.apache.org/jira/browse/GERONIMO-2096 Project: Geronimo Type: Bug Security: public(Regular issues) Components: core, Plugins Versions: 1.1 Reporter: John Sisson Assignee: John Sisson Fix For: 1.1 The code contains the following statement, where the xml variable is a File. xform.transform(new DOMSource(doc), new StreamResult(xml)); We have experienced in another issue ( GERONIMO-2095 ) that this does not close the FileOutputStream that gets created automatically on your behalf. It is safer to create your own FileOutputStream and pass it on the StreamResult constructor and ensure it is closed in a finally block. See fix for GERONIMO-2095 for an example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2096) PluginInstallerGBean.updatePluginMetadata(..) may leave geronimo-plugin.xml file open
[ http://issues.apache.org/jira/browse/GERONIMO-2096?page=all ] John Sisson closed GERONIMO-2096: - Resolution: Fixed Fixed. PluginInstallerGBean.updatePluginMetadata(..) may leave geronimo-plugin.xml file open - Key: GERONIMO-2096 URL: http://issues.apache.org/jira/browse/GERONIMO-2096 Project: Geronimo Type: Bug Security: public(Regular issues) Components: core, Plugins Versions: 1.1 Reporter: John Sisson Assignee: John Sisson Fix For: 1.1 The code contains the following statement, where the xml variable is a File. xform.transform(new DOMSource(doc), new StreamResult(xml)); We have experienced in another issue ( GERONIMO-2095 ) that this does not close the FileOutputStream that gets created automatically on your behalf. It is safer to create your own FileOutputStream and pass it on the StreamResult constructor and ensure it is closed in a finally block. See fix for GERONIMO-2095 for an example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Frustrations of a Release Manager
On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote: I think it will help to have the schedule of the release. No one can claim IBM has a secret agenda if the time line is laid out there. And it's easy to wink if no one has any idea what the deadlines we're working toward are. I agree with Aaron here - publicity of not only the timeline (i.e., a calendar of release schedules maybe) but also the Road Map may help on all fronts. IMO we should consider publishing and continually revisiting both of these items. I know that this won't be a popular suggestion on the committer side of things because we are a volunteer organization, but it would most certainly help our user community immensely. A wiki page of the Road Map along with a rough timeline would be a good start. I also think that tying the Road Map to a timeline will cause people to more closely examine the time a particular feature might require. But like the Linux kernel release schedule, determining any kind of regular release schedule may prove to be quite difficult. But IMO it can't hurt to have goals. Just my $0.02. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: Anschluss - CORBA specs new home
Don't they have to have incubator as part of the file names and then when they exit the incubator they can remove incubator from the name. Sounds like it may create extra work changing Geronimo POMs to point to the correct files at different stages. Are the groupIDs changing too? John Dain Sundstrom wrote: Projects in the incubator can do releases. They do have a restriction until the IP is cleared, but once that is done they can release using the normal release process. -dain On Jun 5, 2006, at 6:29 PM, Matt Hogstrom wrote: I'm ok with it but would prefer to turn them over after Yoko graduates. My understanding is that an incubator project can't release anything. I expect they don't change a whole lot but that would be my only reservation. Alan D. Cabrera wrote: I think that it's time that we, Yoko, take responsibility for the CORBA spec jars. After Geronimo releases v1.1, let's plan on moving them over to Yoko. Thoughts? Regards, Alan
Re: 1.1 Release plan
Matt Hogstrom wrote: Final Items for 1.1 I would like to release Geronimo 1.1 on June 12th. Yes, that is three days away. If we can't make that date then it will be 72 hours away from each candidate build. Problem that are found need to be addressed if they are deemed critical. Otherwise they will be tracked and solved in a follow on release. That said. I sent a note earlier today announcing the freeze to branches/1.1. Changes to this branch should be limited to bug fixes only. The little changes are the ones that generally burn you. At 1400 ET the Inn is closed and I will spin up a release that will be our release candidate. The issues that have been raised from the previous build were Guillaume's observation of the problem when running Geronimo under CygWin as well as the license and Notice issues. Since Geronimo is a multifaceted project there are several things that need to be voted on. They are Geronimo itself, the specification jars and DayTrader. Geronimo itself is the significant component that will carry the other items so I believe a vote for Geronimo in this context is a vote for all three items. *There is a concern about the specification jars* David Jencks raised this issue in another note on the list. The jars have not been released but they have had a tag cut and the resulting compilation has been placed on http://people.apache.org/repository. One of the issues I found with the spec is that there are different spec releases in the 1_1 tag. I would prefer that all jars have the same version suffix. Right now it includes 1.0, 1.0.1, 1.1 and others. I think this is confusing. We release Geronimo with all the same module versions even if nothing has changed. I would like to move that we recut a 1_2 tag with all spec jars having a 1.2 suffix. I will add the NOTICE and LICENSE files so that they are included in the spec jars. This is mandatory for publicly available jars (so afaik, all). Specs jars are built with m2 and this i svery important that they are available in a m2 repo. *DayTrader* Day Trader is currently a 1.1-SNAPSHOT as well. We will release the DayTrader Ear (separate from Geronimo) as a 1.1 version as well. This way the build will be in sync. *Issues* 1. It was noted earlier today that there is a problem with Geronimo under CygWin. Guillaume noted that an issue exists where a file is not renamed (config.xml). Given that CygWin is a hybrid environment I think we should investigate this problem but not hold up the release. I have tested under cygwin. I will try with plain windows command line, but I fear this is the same problem. I will update the JIRA accordingly. 2. Guillaume also pointed out the lack of a License and Notices file. I will include the two files from the SVN geronimo/branches/1.1 in the build tomorrow. I will add the in the META-INF directory for all geronimo jars (not sure if it can be done for car files, though) Cheers, Guillaume Nodet 3. Numerous bug fixes are being addressed. Excellent. Apart from Spec issue above I think we have most everything addressed. Does this list of outstanding items and release plan make sense? Matt
[jira] Resolved: (AMQ-731) Redeliveries don't work with resource adapter and Jencks
[ https://issues.apache.org/activemq/browse/AMQ-731?page=all ]
james strachan resolved AMQ-731:
Fix Version: 4.0.1
4.1
Resolution: Fixed
Assign To: james strachan
Patch applied with thanks!
Redeliveries don't work with resource adapter and Jencks
Key: AMQ-731
URL: https://issues.apache.org/activemq/browse/AMQ-731
Project: ActiveMQ
Type: Bug
Components: Connector
Versions: 4.0
Environment: Sun JDK 1.5.0_06, Jencks 1.1.3, AMQ 4.0, Resin Pro 3.0.14
Reporter: Christopher G. Stach II
Assignee: james strachan
Fix For: 4.1, 4.0.1
Attachments: amq-txcontext.patch
During a rollback in a JTA transaction, this exception is generated a few
times:
org.apache.activemq.broker.AbstractConnection.serviceException Async
error occurred: javax.jms.JMSException: Could not correlate
acknowledgment with dispatched message: MessageAck {commandId = 137,
responseRequired = false, ackType = 1, consumerId =
ID:xxx-2276-1148335783189-2:5:-1:2, firstMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
javax.jms.JMSException: Could not correlate acknowledgment with
dispatched message: MessageAck {commandId = 137, responseRequired =
false, ackType = 1, consumerId = ID:xxx-2276-1148335783189-2:5:-1:2,
firstMessageId = ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
at
org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:175)
at
org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:233)
at
org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:362)
at
org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:176)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:78)
at
org.apache.activemq.broker.AbstractConnection.processMessageAck(AbstractConnection.java:356)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:178)
at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:201)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:)
at
org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1655)
at
org.apache.activemq.ActiveMQSession$2.afterRollback(ActiveMQSession.java:720)
at
org.apache.activemq.TransactionContext.afterRollback(TransactionContext.java:134)
at
org.apache.activemq.TransactionContext.rollback(TransactionContext.java:409)
at
org.apache.activemq.ra.LocalAndXATransaction.rollback(LocalAndXATransaction.java:126)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:78)
at
com.caucho.transaction.TransactionImpl.rollbackInt(TransactionImpl.java:787)
at
com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java:560)
at org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:125)
at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:64)
at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:214)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751)
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:163)
at com.caucho.jca.WorkThread.run(WorkThread.java:99)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:490)
at com.caucho.util.ThreadPool.run(ThreadPool.java:423)
at java.lang.Thread.run(Thread.java:595)
Note that the ackType is a poison ack. This shouldn't be the case as the
configuration (below) on the
[jira] Updated: (AMQ-688) Avoid blocking producers
[ https://issues.apache.org/activemq/browse/AMQ-688?page=all ] james strachan updated AMQ-688: --- Fix Version: 4.1 (was: incubation) updated fix version Avoid blocking producers Key: AMQ-688 URL: https://issues.apache.org/activemq/browse/AMQ-688 Project: ActiveMQ Type: New Feature Components: Broker Versions: 4.0 RC2 Reporter: Christopher A. Larrieu Assignee: Christopher A. Larrieu Fix For: 4.1 Original Estimate: 8 weeks Remaining: 8 weeks Our main goal is to avoid stalled producers by addressing the main culprit: too many undispatched messages in the broker's memory. Our motivation is to handle significant --though temporary-- imbalances between production and consumption rates. Reaching this goal entails specific broker modifications: 1. When memory gets tight, start dropping undispatched non-persistent messages. This is the first-cut attempt to maintain throughput of persistent messages. Unlike the approach documented at http://docs.codehaus.org/display/ACTIVEMQ/Slow+Consumer+Handling, the message dropping will only occur after the UsageManager reaches capacity. Non-persistent messages in dispatch lists will be dropped according to per-destination policy. Subscriptions can purge their own messages triggered via callback from the UsageManager. 2. Evict messages if memory remains tight, to be fetched from backing store prior to dispatch. ActiveMQ already supports this for persistent messages on Topics with durable subscriptions. If a consumer's prefetch buffer is full, the splash-over messages remain as IndirectMessageReference objects in the dispatch list, with the actual message body loaded from store on demand. I believe we can extend this approach for Queues as well. 3. Improve the efficiency with which evicted messages are loaded back into memory. Currently, they are loaded one at a time as needed. It would make sense to batch-load message sets periodically. This will require a significant shift in responsibilities between objects, since an IndirectMessageReference doesn't know about other instances that can be loaded in mass. The goal will be to keep each subscription dispatch list stocked with a decent number of messages in-memory to reasonably trade-off between it's consumer's performance and resource usage in the broker. As with everything else, we can implement this as a strategy class with the first cut implementing a simple resource allocation strategy: divvy up available memory amongst all subscriptions and keep that memory filled with messages for dispatch. I envision a worker task assuming responsibility for keeping these lists filled. 4. Even with the above modifications, we still can't entirely avoid blocked producers, so we'd like to add client-configurable time-outs to provide a bound for the time a producer can remain stalled. Maybe this should be a new attribute of ActiveMQConnection: maxProducerFlowControlWait. Calls to UsageManager.waitForSpace can take this quantity as an argument. Failure to reach sufficient space for the new message will throw an exception back up the stack and across the wire, letting the producer know that the message was not delivered. 5. Finally, we need to extend disk support for Topics that have only non-durable subscribers, otherwise their dispatch lists can fill up with persistent messages. In order to maintain compliance with JMS, it would be nice to provide some alternative to dropping persistent messages. One possible first cut is to layer this on top of a DurableTopicSubscription by creating an anonymous subscriber for every Topic that has only non-durable subscriptions. When all such subscriptions terminate, the broker can remove the anonymous subscriber. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1638) Multiple servers sharing the same repo and config store
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12415496 ] John Sisson commented on GERONIMO-1638: --- Currently working on scripts as discussed at http://www.mail-archive.com/dev@geronimo.apache.org/msg22807.html . Have made changes but they need to be tested on windows, cygwin and unix, so looks like this is going to be for 1.1.1 . Multiple servers sharing the same repo and config store --- Key: GERONIMO-1638 URL: http://issues.apache.org/jira/browse/GERONIMO-1638 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: usability Versions: 1.0 Reporter: Gianny Damour Assignee: John Sisson Fix For: 1.1 David J. sent to the dev mailing list: Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are located outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to relocate. I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like resolveVar and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the var trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now var. Several people have suggested putting an additional config-store into var for private use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-743) make it easier to debug log message flows in ActiveMQ in debugging mode with a logging plugin
make it easier to debug log message flows in ActiveMQ in debugging mode with a logging plugin - Key: AMQ-743 URL: https://issues.apache.org/activemq/browse/AMQ-743 Project: ActiveMQ Type: Improvement Reporter: james strachan Assigned to: james strachan Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-743) make it easier to debug log message flows in ActiveMQ in debugging mode with a logging plugin
[ https://issues.apache.org/activemq/browse/AMQ-743?page=all ] james strachan resolved AMQ-743: Resolution: Fixed http://activemq.org/site/logging-interceptor.html make it easier to debug log message flows in ActiveMQ in debugging mode with a logging plugin - Key: AMQ-743 URL: https://issues.apache.org/activemq/browse/AMQ-743 Project: ActiveMQ Type: Improvement Reporter: james strachan Assignee: james strachan Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.1 Release plan
Matt Hogstrom wrote: Final Items for 1.1 I would like to release Geronimo 1.1 on June 12th. Yes, that is three days away. If we can't make that date then it will be 72 hours away from each candidate build. Problem that are found need to be addressed if they are deemed critical. Otherwise they will be tracked and solved in a follow on release. Unfortunately I will be off-line for the next three days. Not everybody has every weekend free, so how about another 3 days so everyone has plenty of notice and there will be less chance of complaints. The only thing that I had outstanding was changes to the scripts (GERONIMO-1638) as discussed at http://www.mail-archive.com/dev@geronimo.apache.org/msg22807.html . Have made changes (not committed) but they need to be tested on windows, cygwin and unix, so with my time constraints it looks like this is going to be for 1.1.1 . Probably need something in the release notes saying that use of the GERONIMO_BASE environment variables probably won't work and the new org.apache.geronimo.server.dir and org.apache.geronimo.server.name system properties are subject to change as they are experimental. It would have been nice if I had a few more days to test and the effectiveness of having a release candidate has already been proven.. Maybe we should be giving the users a bit more time to test.. That said. I sent a note earlier today announcing the freeze to branches/1.1. Changes to this branch should be limited to bug fixes only. The little changes are the ones that generally burn you. At 1400 ET the Inn is closed and I will spin up a release that will be our release candidate. The issues that have been raised from the previous build were Guillaume's observation of the problem when running Geronimo under CygWin as well as the license and Notice issues. Since Geronimo is a multifaceted project there are several things that need to be voted on. They are Geronimo itself, the specification jars and DayTrader. Geronimo itself is the significant component that will carry the other items so I believe a vote for Geronimo in this context is a vote for all three items. *There is a concern about the specification jars* David Jencks raised this issue in another note on the list. The jars have not been released but they have had a tag cut and the resulting compilation has been placed on http://people.apache.org/repository. One of the issues I found with the spec is that there are different spec releases in the 1_1 tag. I would prefer that all jars have the same version suffix. Right now it includes 1.0, 1.0.1, 1.1 and others. I think this is confusing. We release Geronimo with all the same module versions even if nothing has changed. I would like to move that we recut a 1_2 tag with all spec jars having a 1.2 suffix. In theory the version suffix should match up with the JIRA records for it, but it seems we don't have a separate JIRA project set up for specs, but having a 1.2 suffix seems just as confusing to me since the specs from a JIRA perspective are managed as part of Geronimo's JIRA and we are releasing 1.1. *DayTrader* Day Trader is currently a 1.1-SNAPSHOT as well. We will release the DayTrader Ear (separate from Geronimo) as a 1.1 version as well. This way the build will be in sync. *Issues* 1. It was noted earlier today that there is a problem with Geronimo under CygWin. Guillaume noted that an issue exists where a file is not renamed (config.xml). Given that CygWin is a hybrid environment I think we should investigate this problem but not hold up the release. I could reproduce the problem and fixed it. See GERONIMO-2095. 2. Guillaume also pointed out the lack of a License and Notices file. I will include the two files from the SVN geronimo/branches/1.1 in the build tomorrow. 3. Numerous bug fixes are being addressed. Excellent. Apart from Spec issue above I think we have most everything addressed. Does this list of outstanding items and release plan make sense? Thanks Matt, I know you have been putting in some late nights getting this on its way. Matt
Re: Notes from JavaOne
Aaron, Do you have any more information on the Ebay announcement the Apache PRC has been asked whether we have any details on this? The only public mention I have found (I didn't attend JavaOne) is on page 42 of the The eBay Matrix slides from the JavaOne 2006, presented by Ian Flint and David Marsland that briefly mentions WebSphere and Geronimo. I was able to download these slides soon after JavaOne finished but unfortunately these slides seem to be no longer downloadable. If you have any more information please copy the prc@ and pmc@ lists. Regards, John Aaron Mulder wrote: All, A great time was had at JavaOne, including a variety of Geronimo-related meetings, hacking time in the W and Moscone, a BOF, a party, etc. Here are some thoughts I put together based on the bits I was involved with, which I think we'd all like to run by everyone who couldn't be there. Also, here are the slides from the Geronimo BOF, that talk a bit about the various releases: http://people.apache.org/~ammulder/geronimo-javaone2006.pdf Thanks, Aaron Ebay announced in a BOF that they are deploying their site on WebSphere CE (Geronimo)!!! Yeah, let's talk about acalability... :) Vendor Support - Many vendors are supporting Geronimo, including: - 24x7 support - services - building applications on Geronimo - building/supporting software stacks including Geronimo 1.1/1.2 Merge - Major things changed in 1.2: OpenEJB refactoring, JavaMail providers, initial Maven 2 build script, ActiveMQ 3-4, dynamic EJB queries - Still, not that much compared to 1.1 - We plan for the process to be 1) move 1.2 to branches/1.2-pre 2) copy 1.1 to trunk 3) maintain 1.1 in current 1.1 branch 4) merge changes from branches/1.2-pre to trunk 5) eventually whack branches/1.2-pre perhaps Release Schedule - 1.0 took too long to arrive (since founding) and 1.1 took too long to arrive (since 1.0) - We need to avoid TCK breakage and do a better job of incremental change - Some people advocate time-based releases (2/3/4 months) - Some people would like to see XBean releases more often, outside the Geronimo release schedule - Vendors don't like the uncertainty about release dates; most are still targeting 1.0 because it's here and there's no guarantee when 1.1 will actually arrive - Overall, there seems to be interest in targeting a 3-month release schedule for 1.2 (2 months active development and 1 month stabilization) - Proposal to target 4 features releases per year with incremental features available via plugins Jira Process - lots of open Jiras - estimate we have closed 250 for 1.1, and have 500 currently open - may need to clean up some old/stale issues - Jira never reflects how close we are to a release - Many Jiras go unnoticed - There's not a good way to have a personal work/priority list separate from the project release/priority list - Might be good to have 3 Jira releases: current release, next release, everything else - Might be helpful to have someone take responsibility for evaluating all incoming Jiras for a period of time (1-4 weeks?) and rotate that responsibility - Maybe could add custom fiuelds to help us manage it Java SE 5 - We can develop on Java 5 and support 1.4.2 via Retrotranslator - It supports most of Java 5, with some caveats regarding Serialization and new classes added outside of Collections (some SSL-related stuff, etc.) - Running on 1.4 with Retrotranslator causes a startup penalty of ~20% (but shouldn't have much effect after startup, when all the classes are loaded) - Running on 1.5 speeds startup by 20% and should have benefits after startup too - Dain will try a more extensive test and make sure everything works for us - Yoko is making good progress. Some holes (e.g. SSL) but we can probably start integrating and may have this for 1.2 (Rick will work on this) Java EE 5 - OpenJPA code is only partially available; more expected soon - Should be able to implement a JPA factory that lets us give access to installed JPA implementations - Should be able to get web features from Jetty 6 - Should be able to get JAX-WS from XFire/Celtix - Don't have an immediate plan for EJB3 (outside of JPA), though Spring reportedly has working code we could leverage - Should be easy to get initial EE 5 features in 1.2, may not have full support, but this is enough for people to play with Candidate Features for Future Releases - Console portlets can be added at runtime - OpenEJB 2.x revisions - Initial XBean-style features - Don't require GBeanInfo for GBeans - Integrate XBean reflect to support factory beans, nested complex objects, etc. - Designate startup methods instead of requiring interface - Full XBean Integration - Monitoring / Statistics - DConfigBeans - Improved JMX+SNMP - Pluggable JACC (Acegi, LDAP, etc.) - Start Levels - ActiveIO - IBM AIO??? - Workflow via BeanFlow - Global JNDI - XDoclet - Startup Wrapper - Upgrade on the fly - Security Rewrite - 1-click to disable unused services -
[jira] Commented: (GERONIMO-2094) All geronimo jars and distributions should include at least the required LICENSE and NOTICE files
[ http://issues.apache.org/jira/browse/GERONIMO-2094?page=comments#action_12415500 ] Guillaume Nodet commented on GERONIMO-2094: --- I have added the LICENSE and NOTICE files in spec jars. All geronimo jars and distributions should include at least the required LICENSE and NOTICE files - Key: GERONIMO-2094 URL: http://issues.apache.org/jira/browse/GERONIMO-2094 Project: Geronimo Type: Task Security: public(Regular issues) Components: general Versions: 1.0 Reporter: Guillaume Nodet Priority: Critical Fix For: 1.1 The presence of the LICENSE and NOTICE files are a legal requirements for all ASF software published. For distributions, they must be in the root folder. For jars publicly available (via maven repos), they should be in the META-INF dir. Also, the distributions should include third party licenses for included jars. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Geronimo doesn't startup if restart it using another JDK
Hello, I have launched Geronimo on Sun JDK. Then Ive tried to run it with Harmony class library and IBM VM j9. Ive got the error log below. Also Ive got the same result when launched Geronimo on Harmony and then - on Sun JDK. There is a bug in HOWL repaired in howl-1.0.1 by the new parameter (adler32Checksum) adding. At Geronimo startup it checks the log files' validity if they exist. One of verified parameters is the file content control sum. One value of this sum is read from file header and another is calculated by function java.nio.ByteBuffer.hashCode(). So if the algorithms of hash code functions of the JDKs are different Geronimo doesnt startup. If the parameter adler32Checksum value is false the control sum is calculated by function java.nio.ByteBuffer.hashCode() otherwise it is calculated using ADLER-32 algorithm. Therefore, I think, it would be correct to add this parameter to configs/j2ee-server/src/plan/plan.xml and to gbean org.apache.geronimo.transaction.log.HOWLLog with value 'true'. Any thoughts? Thanks, Nellya Udovichenko, Intel Middleware Products Division Error log: $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.4.2_01)... Starting Geronimo Application Server v1.1-20060607 [** ] 11% 6s Starting geronimo/j2ee-server/1...14:23:30,3 19 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED s tate: abstractName=geronimo/j2ee-server/1.1-20060607/car?ServiceModule=geronimo /j2ee-server/1.1-20060607/car,j2eeType=TransactionLog,name=HOWLTransactionLog org.objectweb.howl.log.InvalidLogBufferException: CHECKSUM Class: org.objectweb.howl.log.BlockLogBuffer workerID: LogFile: C:\Nellya\geronimo-1.1\var\txlog\howl_1.log HEADER HEADER_ID: 0x484f574c bsn: 0x1 size: 0x8000 should be: 0x8000 data used: 0x4f checkSum: 0x2227d tod: 0x10bb850e3b1 crlf: 0xd0a FOOTER FOOTER_ID: 0x4c574f48 bsn: 0x1 tod: 0x10bb850e3b1 crlf: 0xd0a at org.objectweb.howl.log.BlockLogBuffer.read(BlockLogBuffer.java:460) at org.objectweb.howl.log.LogFileManager.init(LogFileManager.java:821) at org.objectweb.howl.log.Logger.open(Logger.java:314) at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:893) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:217) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j ava:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe ndency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:512) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:493) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastCla ssByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:122) at
Issues Closed: week of 06-09-2006
Project: Apache Geronimo Status: Resolved, Closed (25 items) Updated In Last: Week (7 days) ** Bug * [GERONIMO-2096] PluginInstallerGBean.updatePluginMetadata(..) may leave geronimo-plugin.xml file open * [GERONIMO-2095] Problem with attribute manager * [GERONIMO-1425] access to unprotected web resource after login does not use correct Subject * [GERONIMO-1532] NullPointerException when a badly named jar is put into repository directory * [GERONIMO-1883] Make sure all documentation is clearly marked as G 1.0 or G 1.1 * [GERONIMO-2091] MimeBodyPart.getFileName() not retrieving name from the Content-Disposition header * [GERONIMO-2054] http://geronimo.apache.org/xml/ns/j2ee/web-1.0 name spaces are not upgraded by Upgrade1_0To1_1 * [GERONIMO-1774] baseDir NPE in org.apache.geronimo.deployment.DeploymentContext * [GERONIMO-1993] Build failure during assembly of j2ee-installer * [GERONIMO-2024] namespace updates were turned off in 1.1 * [GERONIMO-1992] Exception in ConfigManager during redeploy * [GERONIMO-1906] Cannot add a new connector using ActiveMQManagerGBean * [GERONIMO-1821] maven new4 in 1.1 leaves loads of /tmp/packageN.tmpdir directories behind * [GERONIMO-1483] During Undeploy entry in config.xml is not removed * [GERONIMO-1933] Database pool usage doesn't include mandatory dependency * [GERONIMO-2042] ConfigurationAwareReference needs Serial Version UID * [GERONIMO-2089] Plugin exporter omits copy file and config.xml blocks * [GERONIMO-2088] Plugin installer writes bad XML for config.xml content * [GERONIMO-2087] MimeUtility.encodeWord()/encodeText() have some errors. * [GERONIMO-1498] DriverDownloader.DriverInfo causes java.io.NotSerializableException during server shutdown ** Improvement * [GERONIMO-1434] Allow GBeans to be bound into a component's java:comp/env namespace * [GERONIMO-1950] Plugins should be able to specify config.xml settings to include explicitly * [GERONIMO-2023] Improve sample app install process
[jira] Resolved: (GERONIMO-1645) Module migration to Maven2: tomcat
[ http://issues.apache.org/jira/browse/GERONIMO-1645?page=all ] Anita Kulshreshtha resolved GERONIMO-1645: -- Fix Version: 1.2 Resolution: Fixed Module migration to Maven2: tomcat -- Key: GERONIMO-1645 URL: http://issues.apache.org/jira/browse/GERONIMO-1645 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: Tomcat Versions: 1.x Reporter: Jacek Laskowski Assignee: Anita Kulshreshtha Fix For: 1.2 Attachments: maven-metadata-local.xml, part_fixes.patch, pom.patch, pom.patch, pom.patch, pom.patch, pom.patch, pom.patch, pom.xml, pom.xml, pom.xml, pom.xml, tomcat-tests.patch It's a task to help keep track of the progress of the tomcat module build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1646) Module migration to Maven2: tomcat-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1646?page=all ] Anita Kulshreshtha resolved GERONIMO-1646: -- Fix Version: 1.2 Resolution: Fixed Module migration to Maven2: tomcat-builder -- Key: GERONIMO-1646 URL: http://issues.apache.org/jira/browse/GERONIMO-1646 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: Tomcat Versions: 1.x Reporter: Jacek Laskowski Assignee: Anita Kulshreshtha Fix For: 1.2 Attachments: pom.patch, pom.patch, pom.patch It's a task to help keep track of the progress of the tomcat-builder module build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1693) Module migration to Maven2: j2ee-schema
[ http://issues.apache.org/jira/browse/GERONIMO-1693?page=all ] Anita Kulshreshtha resolved GERONIMO-1693: -- Fix Version: 1.2 Resolution: Fixed Module migration to Maven2: j2ee-schema --- Key: GERONIMO-1693 URL: http://issues.apache.org/jira/browse/GERONIMO-1693 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Priority: Blocker Fix For: 1.2 Attachments: pom.patch, pom.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1693) Module migration to Maven2: j2ee-schema
[ http://issues.apache.org/jira/browse/GERONIMO-1693?page=all ] Anita Kulshreshtha closed GERONIMO-1693: Module migration to Maven2: j2ee-schema --- Key: GERONIMO-1693 URL: http://issues.apache.org/jira/browse/GERONIMO-1693 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Priority: Blocker Fix For: 1.2 Attachments: pom.patch, pom.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Plugin versioning problems
That's a good idea and it would be pretty straightforward. But now
that Dain has brought our attention to GERONIMO-1637 I'm concerned
about deviating from the G 1.2 activities where the full syntax of
maven version ranges will be introduced. I don't know much about
maven version ranges - there may be some subset that can be
implemented during G 1.1.x that addresses our specific concerns about
forcing plugins to continually update their geronimo-plugin.xml.
Best wishes,
Paul
On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote:
Paul, what if we tweaked your proposed patch and allowed the plugin to
provide an optional attribute of exactVersion=required, which would
control the behavior?
-Donald
Paul McMahan wrote:
I definitely agree that a full fledged solution for version ranges is
out of scope for G 1.1.x. I was thinking that a minor change to the
plugin installer's version checking could at least partially address
Donald's concerns and also avoid the version mismatch problem Dave C.
found in the candidate build. Here's a patch that makes the plugin
installer only check the digits of geronimo's version that the
plugin's xml specifies. So if the plugin specifies
geronimo-version1.1/geronimo-version then it can be installed into
1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
Best wishes,
Paul
Index:
modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
===
---
modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
(revision
412744)
+++
modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
(working
copy)
@@ -1409,7 +1409,7 @@
if(gerVersion == null || gerVersion.equals()) {
throw new IllegalStateException(geronimo-version
should not be empty!);
}
-if(gerVersion.equals(version)) {
+if(version.startsWith(gerVersion)) {
match = true;
break;
}
On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote:
Perhaps I was unclear; I didn't mean to say this was a bad idea, only
that our code doesn't currently support it. I expect version ranges
are on the road map, but if you want to work on them, you're more than
welcome to. :)
I don't think this is a G 1.1.x discussion, since AFAIK it would
require kernel changes.
Thanks,
Aaron
On 6/8/06, Paul McMahan [EMAIL PROTECTED] wrote:
On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote:
What I meant by 1.1.* was the Maven behavior of private builds like
1.1-1 being taken as newer than 1.1. Also, being able to use the
behavior of 1.1-starting with any alpha is less than 1.1.
Basically,
I should be able to specify 1.1 in the plugin and have it work on
1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on
1.1.1,
then I'd argue that we broke something in 1.1.1, given it should
only be
a maintenance release and app/plan breaking changes should only go
into 1.2.
+1 This approach is similar to how eclipse plugin versioning works.
From http://www.eclipse.org/equinox/documents/plugin-versioning.html :
How to specify plug-in requirements
Plug-ins that require other plug-ins must qualify their requirements
with a version range since the absence of a version range means that
any version can satisfy the dependency. Given that all the changes
between the version x.0.0 and the version x+1.0.0 excluded must be
compatible (given the previous guidelines); the recommended range
includes the minimal required version up-to but not including the next
major release.
IMHO geronimo should adopt eclipse's strategy for plugin versioning
where possible since the two sets of base requirements are quite
similar and eclipse is a few years ahead in this area. The document
referenced above spells out their strategy in detail.
Best wishes,
Paul
Re: Frustrations of a Release Manager
Bruce Snyder wrote: On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote: I think it will help to have the schedule of the release. No one can claim IBM has a secret agenda if the time line is laid out there. And it's easy to wink if no one has any idea what the deadlines we're working toward are. I agree with Aaron here - publicity of not only the timeline (i.e., a calendar of release schedules maybe) but also the Road Map may help on all fronts. IMO we should consider publishing and continually revisiting both of these items. I know that this won't be a popular suggestion on the committer side of things because we are a volunteer organization, but it would most certainly help our user community immensely. I have to disagree here. Although I absolutely agree a roadmap is helpful and trackable, the timeline and release issues that Matt has talked about is clearly an issue. On these lists, Matt has made things extremely clear regarding when our releases should be, along with group consensus, and thing have been quietly injected into Geronimo. I share Matt's feelings and frustrations. Minimally, if we cannot hold to a simple date based on agreement on these lists, a roadmap, although helpful, will surely not be a panacea. It is also my hope that there are not private emails going around talking about secret agendas. This would dismay me as I fully expect that we are all adult enough to share our feelings with each other in these lists. If an email like this is being passed around, then we clearly need to be working on our communication skills and have a long way to go on learning to work with each other as a team. I think communication is the primary thing we need to deal with. Jeff A wiki page of the Road Map along with a rough timeline would be a good start. I also think that tying the Road Map to a timeline will cause people to more closely examine the time a particular feature might require. But like the Linux kernel release schedule, determining any kind of regular release schedule may prove to be quite difficult. But IMO it can't hurt to have goals. Just my $0.02. Bruce
[jira] Closed: (SM-448) Allow to provide a wsdl instead of generating one
[ https://issues.apache.org/activemq/browse/SM-448?page=all ] Guillaume Nodet closed SM-448: -- Resolution: Fixed Assign To: Guillaume Nodet Author: gnodet Date: Fri Jun 9 06:22:37 2006 New Revision: 413042 URL: http://svn.apache.org/viewvc?rev=413042view=rev Log: SM-448: Allow the use of an existing wsdl instead of generating one Modified: incubator/servicemix/trunk/servicemix-jsr181/src/main/java/org/apache/servicemix/jsr181/Jsr181Endpoint.java Allow to provide a wsdl instead of generating one - Key: SM-448 URL: https://issues.apache.org/activemq/browse/SM-448 Project: ServiceMix Type: Improvement Components: servicemix-jsr181 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.0-M2 This is necessary for wsdl design first development -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Frustrations of a Release Manager
In the spirit of greater openness and communication, please elaborate on 'thing have been quietly injected into Geronimo'. As far as I can tell, the main source of the 1.1 delay was that the module ID changes (new syntax, groupless or versionless dependencies, etc.) caused a ton of problems, in the TCK, the deployment tools, the console, and so on. When the original deadline came, the product was not stable enough to ship. I'm sure that some of the features I've worked on have contributed -- mainly the keystore changes, which caused some TCK failures until we updated the keystore configuration for it. Still, we've talked about some of the reasons for this, and I think we all want to try to make the 1.2 changes more incremental and keep the TCK passing at all times to avoid major disconnects as we move forward. As far as the release schedule goes, I'm disappointed that we missed the deadline, and then didn't really update our road map... If there was a new target date or plan it seemed pretty informal -- there didn't seem to be anything posted to the dev list or the web site, etc (though based on Jeff's comments it sounds like there was and I missed it?). Now we're trying to put out a release when our only preview/release candidate has been available for less than a week. I contrast that to the SuSE process where there were at least 12 well-defined test builds (9 or more beta builds and 3 or more RC builds) at well-defined interrvals. As a user, I certainly appreciated that I could get and try the latest, submit bug reports, check the release calendar for the date of the next test build, get it and test the fixes, etc. I don't think that one build and 72 hours is sufficient to convince me that 1.1 is a stable release. I don't feel strongly enough to override a majority opinion, if there is one, but I'd like to try a much more SuSE-like release strategy for 1.2 and see how it goes. If that doesn't work so well either, we'll regroup and try something different for the release after. Thanks, Aaron On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Bruce Snyder wrote: On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote: I think it will help to have the schedule of the release. No one can claim IBM has a secret agenda if the time line is laid out there. And it's easy to wink if no one has any idea what the deadlines we're working toward are. I agree with Aaron here - publicity of not only the timeline (i.e., a calendar of release schedules maybe) but also the Road Map may help on all fronts. IMO we should consider publishing and continually revisiting both of these items. I know that this won't be a popular suggestion on the committer side of things because we are a volunteer organization, but it would most certainly help our user community immensely. I have to disagree here. Although I absolutely agree a roadmap is helpful and trackable, the timeline and release issues that Matt has talked about is clearly an issue. On these lists, Matt has made things extremely clear regarding when our releases should be, along with group consensus, and thing have been quietly injected into Geronimo. I share Matt's feelings and frustrations. Minimally, if we cannot hold to a simple date based on agreement on these lists, a roadmap, although helpful, will surely not be a panacea. It is also my hope that there are not private emails going around talking about secret agendas. This would dismay me as I fully expect that we are all adult enough to share our feelings with each other in these lists. If an email like this is being passed around, then we clearly need to be working on our communication skills and have a long way to go on learning to work with each other as a team. I think communication is the primary thing we need to deal with. Jeff A wiki page of the Road Map along with a rough timeline would be a good start. I also think that tying the Road Map to a timeline will cause people to more closely examine the time a particular feature might require. But like the Linux kernel release schedule, determining any kind of regular release schedule may prove to be quite difficult. But IMO it can't hurt to have goals. Just my $0.02. Bruce
Re: [jira] Commented: (GERONIMO-1638) Multiple servers sharing the same repo and config store
BTW, I think additional fixes are required in 1.1.1 before claiming support for multiple concurrent server instances from a single installation.. Awhile back I was able to start the server using an external var directory (via -Dorg.apache.geronimo.server.dir). After changing all the ports and trying to start a second instance from the default location, I encountered a startup exception regarding the activemq transaction journal. Suspect code changes are needed to relocate the journal to a location outside the installation directory. Thanks -Dave- John Sisson (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12415496 ] John Sisson commented on GERONIMO-1638: --- Currently working on scripts as discussed at http://www.mail-archive.com/dev@geronimo.apache.org/msg22807.html . Have made changes but they need to be tested on windows, cygwin and unix, so looks like this is going to be for 1.1.1 . Multiple servers sharing the same repo and config store --- Key: GERONIMO-1638 URL: http://issues.apache.org/jira/browse/GERONIMO-1638 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: usability Versions: 1.0 Reporter: Gianny Damour Assignee: John Sisson Fix For: 1.1 David J. sent to the dev mailing list: Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are located outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to relocate. I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like resolveVar and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the var trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now var. Several people have suggested putting an additional config-store into var for private use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks
Re: Frustrations of a Release Manager
Aaron Mulder wrote: In the spirit of greater openness and communication, please elaborate on 'thing have been quietly injected into Geronimo'. Personally, I would rather we not get into details as I do not want to see this thread degrade into a flame-fest. I would much rather that we can all agree that there is a communication problem, and definitely enough of a communication problem, that things were quietly being put in and the issue and concern was raised by others. Clearly people have raised that we need to communicate more, and the RTC initiative, in and of itself, is an indication that we need to bring a lot more discussion to the lists. If this is not clear, then we have a much greater problem that I had imagined. As far as I can tell, the main source of the 1.1 delay was that the module ID changes (new syntax, groupless or versionless dependencies, etc.) caused a ton of problems, in the TCK, the deployment tools, the console, and so on. When the original deadline came, the product was not stable enough to ship. I'm sure that some of the features I've worked on have contributed -- mainly the keystore changes, which caused some TCK failures until we updated the keystore configuration for it. Still, we've talked about some of the reasons for this, and I think we all want to try to make the 1.2 changes more incremental and keep the TCK passing at all times to avoid major disconnects as we move forward. As far as the release schedule goes, I'm disappointed that we missed the deadline, and then didn't really update our road map... If there was a new target date or plan it seemed pretty informal -- there didn't seem to be anything posted to the dev list or the web site, etc (though based on Jeff's comments it sounds like there was and I missed it?). Now we're trying to put out a release when our only preview/release candidate has been available for less than a week. I contrast that to the SuSE process where there were at least 12 well-defined test builds (9 or more beta builds and 3 or more RC builds) at well-defined interrvals. As a user, I certainly appreciated that I could get and try the latest, submit bug reports, check the release calendar for the date of the next test build, get it and test the fixes, etc. I don't think that one build and 72 hours is sufficient to convince me that 1.1 is a stable release. I don't feel strongly enough to override a majority opinion, if there is one, but I'd like to try a much more SuSE-like release strategy for 1.2 and see how it goes. If that doesn't work so well either, we'll regroup and try something different for the release after. Thanks, Aaron On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Bruce Snyder wrote: On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote: I think it will help to have the schedule of the release. No one can claim IBM has a secret agenda if the time line is laid out there. And it's easy to wink if no one has any idea what the deadlines we're working toward are. I agree with Aaron here - publicity of not only the timeline (i.e., a calendar of release schedules maybe) but also the Road Map may help on all fronts. IMO we should consider publishing and continually revisiting both of these items. I know that this won't be a popular suggestion on the committer side of things because we are a volunteer organization, but it would most certainly help our user community immensely. I have to disagree here. Although I absolutely agree a roadmap is helpful and trackable, the timeline and release issues that Matt has talked about is clearly an issue. On these lists, Matt has made things extremely clear regarding when our releases should be, along with group consensus, and thing have been quietly injected into Geronimo. I share Matt's feelings and frustrations. Minimally, if we cannot hold to a simple date based on agreement on these lists, a roadmap, although helpful, will surely not be a panacea. It is also my hope that there are not private emails going around talking about secret agendas. This would dismay me as I fully expect that we are all adult enough to share our feelings with each other in these lists. If an email like this is being passed around, then we clearly need to be working on our communication skills and have a long way to go on learning to work with each other as a team. I think communication is the primary thing we need to deal with. Jeff A wiki page of the Road Map along with a rough timeline would be a good start. I also think that tying the Road Map to a timeline will cause people to more closely examine the time a particular feature might require. But like the Linux kernel release schedule, determining any kind of regular release schedule may prove to be quite difficult. But IMO it can't hurt to have goals. Just my $0.02. Bruce
[jira] Updated: (GERONIMO-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Anita Kulshreshtha updated GERONIMO-2067: - Attachment: configs.patch modules.patch pom.patch The attached 3 patches are : 1. configs.patch - -- adding applications jsp-examples, servlets-examples, ldap-demo and welcome for jetty and tomcat -- removed version from o.a.g.configs 2. pom.patch - -- added missing o.a.g.modules -- change the build order, applications should be built before configs. 3. modules.patch - -- adding src/resources2 as resources in axis -- dependency pruning in tomcat, tomcat-builder -- g-dependency.xml needs to be deleted from tomcat/src/resources/META-INF Configs migration to M2 --- Key: GERONIMO-2067 URL: http://issues.apache.org/jira/browse/GERONIMO-2067 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Fix For: 1.2 Attachments: configs.log, configs.patch, configs.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Frustrations of a Release Manager
A wiki page of the Road Map along with a rough timeline would be a good start. I also think that tying the Road Map to a timeline will cause people to more closely examine the time a particular feature might require. But like the Linux kernel release schedule, determining any kind of regular release schedule may prove to be quite difficult. But IMO it can't hurt to have goals. Could use the Road Map feature of JIRA... though I think that works better with more frequent releases (so that the number of issues is less). I like how Atlassian uses their JIRA (and Confluence) to organize their releases. I would like to see G use something closer to their approach. --jason
Re: Frustrations of a Release Manager
On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Personally, I would rather we not get into details as I do not want to see this thread degrade into a flame-fest. I would much rather that we can all agree that there is a communication problem, and definitely enough of a communication problem, that things were quietly being put in and the issue and concern was raised by others. And, in my opinion, a non-trivial part of the problem is nebulous accusations with no specifics. How can we agree not to accuse people of secret agendas, if no one knows what accusations are being made and on what basis? How can we agree not to quietly put things into the product if no one will state what quietly means and what was quietly put in? How can we discuss whether people were being intimidated if no one can provide an example of intimidation? I'm no longer williing to entertain people saying other people are saying there's an issue. I don't feel like saying what the issue is, or I don't know -- it was all other people saying it or whatever. If there's a problem, state it specifically, let's have the flame fest, and we'll agree on how to do things better moving forward. I believe it is 100% counterproductive to keep asserting that things are going wrong without any specifics. If we don't discuss, there won't be improvement. Thanks, Aaron Clearly people have raised that we need to communicate more, and the RTC initiative, in and of itself, is an indication that we need to bring a lot more discussion to the lists. If this is not clear, then we have a much greater problem that I had imagined. As far as I can tell, the main source of the 1.1 delay was that the module ID changes (new syntax, groupless or versionless dependencies, etc.) caused a ton of problems, in the TCK, the deployment tools, the console, and so on. When the original deadline came, the product was not stable enough to ship. I'm sure that some of the features I've worked on have contributed -- mainly the keystore changes, which caused some TCK failures until we updated the keystore configuration for it. Still, we've talked about some of the reasons for this, and I think we all want to try to make the 1.2 changes more incremental and keep the TCK passing at all times to avoid major disconnects as we move forward. As far as the release schedule goes, I'm disappointed that we missed the deadline, and then didn't really update our road map... If there was a new target date or plan it seemed pretty informal -- there didn't seem to be anything posted to the dev list or the web site, etc (though based on Jeff's comments it sounds like there was and I missed it?). Now we're trying to put out a release when our only preview/release candidate has been available for less than a week. I contrast that to the SuSE process where there were at least 12 well-defined test builds (9 or more beta builds and 3 or more RC builds) at well-defined interrvals. As a user, I certainly appreciated that I could get and try the latest, submit bug reports, check the release calendar for the date of the next test build, get it and test the fixes, etc. I don't think that one build and 72 hours is sufficient to convince me that 1.1 is a stable release. I don't feel strongly enough to override a majority opinion, if there is one, but I'd like to try a much more SuSE-like release strategy for 1.2 and see how it goes. If that doesn't work so well either, we'll regroup and try something different for the release after. Thanks, Aaron On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Bruce Snyder wrote: On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote: I think it will help to have the schedule of the release. No one can claim IBM has a secret agenda if the time line is laid out there. And it's easy to wink if no one has any idea what the deadlines we're working toward are. I agree with Aaron here - publicity of not only the timeline (i.e., a calendar of release schedules maybe) but also the Road Map may help on all fronts. IMO we should consider publishing and continually revisiting both of these items. I know that this won't be a popular suggestion on the committer side of things because we are a volunteer organization, but it would most certainly help our user community immensely. I have to disagree here. Although I absolutely agree a roadmap is helpful and trackable, the timeline and release issues that Matt has talked about is clearly an issue. On these lists, Matt has made things extremely clear regarding when our releases should be, along with group consensus, and thing have been quietly injected into Geronimo. I share Matt's feelings and frustrations. Minimally, if we cannot hold to a simple date based on agreement on these lists, a roadmap, although helpful, will surely not be a panacea. It is also my hope that there are not private emails going around talking about secret
Please add me to JIRA developers group
Can someone with karma please add me (jdillon) to the GERONIMO developers group.I think I may have used 'user57' before... but have switched to use my apache id instead.Thanks,--jason
JIRA project for GShell?
Can we create a new JIRA project for GShell? I've got a bunch of task/todo items that I would like to track in JIRA so it is easier to prioritize and plan. Thoughts? --jason
Re: [RTC] m2-plugins deployment plugin
+1 Cheers, Guillaume Nodet David Jencks wrote: I've uploaded http://issues.apache.org/jira/secure/attachment/12335128/geronimo- deployment-plugin-RTC-VOTE.2.patch incorporating most of your comments, see below. Thanks for the review! david jencks On Jun 6, 2006, at 11:57 PM, Jacek Laskowski wrote: On 6/6/06, David Jencks [EMAIL PROTECTED] wrote: Prasad has been working for a long time on an m2 deployment plugin. I've cleaned up his latest patch a little bit and think its ready to commit. Please review http://issues.apache.org/jira/secure/attachment/ 12335116/geronimo-deployment-plugin-RTC-VOTE.patch I have taken a look at the patch and the comments are as follows (they're rather style-centric nor technical, but still valid I hope). No testing was performed. 1/ I was scared to read: May not have been tested. in one of the classes You want me to lie :-) ? I don't think anyone has ever used the in-vm startServer command in the m1 plugin, so I doubt prasad has tested this one either. I still think its worth including as a starting point in case some one wants to try it out. 2/ Copyright 2004-2006 - shouldn't it be Copyright 2006 only? These are basically copies + modifications of the m1 deployment plugin, copyright 2004. I don't know if any changes happened in 2005, but 2004 and 2006 are definitely needed. 3/ The javadoc of classes should be consistent. It means that it should read: /** * @goal undeploy (if appropriate) * * @version $Rev$ $Date$ */ whereas some contain @version $Revision$ $Date$ or no version at all. They should all have the @version, but only mojos should have the @goal in order to not confuse maven. I've fixed the @version tags as well as I can find them. 4/ Geronimo :: Maven Deployment Plugin using m2 - Geronimo :: Maven 2 Deployment Plugin or alternatively Geronimo :: Maven Deployment Plugin for Maven 2, but I'd prefer the former. fixed 5/ geronimo-deployment-plugin/pom.xml has no ASF license header. fixed. I think its better to include the asf license in the source even if maven removes it during processing. So, unless it's corrected I'm -1. If you're swampped with your other work, I can take care of it and propose the patch corrected again. Here's my +1. It doesn't count, though ;-) Why not? Because I edited prasad's patch for formatting and removed unused cruft? Ken's directive requires 3 +1 votes from committers other than the proposer (who apparently does not need to be a committer): although the document he appears to have adapted states only PMC member votes count, that is not in his directive. Since he hasn't responded to requests for clarification I think we have to take him at his word. thanks david jencks david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Frustrations of a Release Manager
Aaron, A flame-fest is counter productive...I prefer we keep this professional. If folks want to see the issues, the mail lists are available for people to read over the last several weeks and make their own opinion. There is more than enough information there to clearly show there are concerns on how we communicate, and our methods of communication. The point is, we need to work on our communication with each other on several levels, and we can choose to agree that we all can work with each other better, both from a informational issue, down to the way we address each other, or we can also choose to look the other way and continue down the path that we have. We know exactly where that path leads us from a consequences perspective, and its not good. Jeff Aaron Mulder wrote: On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Personally, I would rather we not get into details as I do not want to see this thread degrade into a flame-fest. I would much rather that we can all agree that there is a communication problem, and definitely enough of a communication problem, that things were quietly being put in and the issue and concern was raised by others. And, in my opinion, a non-trivial part of the problem is nebulous accusations with no specifics. How can we agree not to accuse people of secret agendas, if no one knows what accusations are being made and on what basis? How can we agree not to quietly put things into the product if no one will state what quietly means and what was quietly put in? How can we discuss whether people were being intimidated if no one can provide an example of intimidation? I'm no longer williing to entertain people saying other people are saying there's an issue. I don't feel like saying what the issue is, or I don't know -- it was all other people saying it or whatever. If there's a problem, state it specifically, let's have the flame fest, and we'll agree on how to do things better moving forward. I believe it is 100% counterproductive to keep asserting that things are going wrong without any specifics. If we don't discuss, there won't be improvement. Thanks, Aaron Clearly people have raised that we need to communicate more, and the RTC initiative, in and of itself, is an indication that we need to bring a lot more discussion to the lists. If this is not clear, then we have a much greater problem that I had imagined. As far as I can tell, the main source of the 1.1 delay was that the module ID changes (new syntax, groupless or versionless dependencies, etc.) caused a ton of problems, in the TCK, the deployment tools, the console, and so on. When the original deadline came, the product was not stable enough to ship. I'm sure that some of the features I've worked on have contributed -- mainly the keystore changes, which caused some TCK failures until we updated the keystore configuration for it. Still, we've talked about some of the reasons for this, and I think we all want to try to make the 1.2 changes more incremental and keep the TCK passing at all times to avoid major disconnects as we move forward. As far as the release schedule goes, I'm disappointed that we missed the deadline, and then didn't really update our road map... If there was a new target date or plan it seemed pretty informal -- there didn't seem to be anything posted to the dev list or the web site, etc (though based on Jeff's comments it sounds like there was and I missed it?). Now we're trying to put out a release when our only preview/release candidate has been available for less than a week. I contrast that to the SuSE process where there were at least 12 well-defined test builds (9 or more beta builds and 3 or more RC builds) at well-defined interrvals. As a user, I certainly appreciated that I could get and try the latest, submit bug reports, check the release calendar for the date of the next test build, get it and test the fixes, etc. I don't think that one build and 72 hours is sufficient to convince me that 1.1 is a stable release. I don't feel strongly enough to override a majority opinion, if there is one, but I'd like to try a much more SuSE-like release strategy for 1.2 and see how it goes. If that doesn't work so well either, we'll regroup and try something different for the release after. Thanks, Aaron On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Bruce Snyder wrote: On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote: I think it will help to have the schedule of the release. No one can claim IBM has a secret agenda if the time line is laid out there. And it's easy to wink if no one has any idea what the deadlines we're working toward are. I agree with Aaron here - publicity of not only the timeline (i.e., a calendar of release schedules maybe) but also the Road Map may help on all fronts. IMO we should consider
[jira] Created: (GERONIMO-2098) Application migration to Maven 2: remote-deploy
Application migration to Maven 2: remote-deploy --- Key: GERONIMO-2098 URL: http://issues.apache.org/jira/browse/GERONIMO-2098 Project: Geronimo Type: Sub-task Security: public (Regular issues) Components: application client Versions: 1.2 Reporter: Prasad Kashyap Fix For: 1.2 Attachments: remote-deploy.patch Merge remote-deploy-lib with remote-deploy Migrate remote-deploy to M2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2098) Application migration to Maven 2: remote-deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2098?page=all ] Prasad Kashyap updated GERONIMO-2098: - Attachment: remote-deploy.patch Application migration to Maven 2: remote-deploy --- Key: GERONIMO-2098 URL: http://issues.apache.org/jira/browse/GERONIMO-2098 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: application client Versions: 1.2 Reporter: Prasad Kashyap Fix For: 1.2 Attachments: remote-deploy.patch Merge remote-deploy-lib with remote-deploy Migrate remote-deploy to M2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2098) Application migration to Maven 2: remote-deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2098?page=all ] Prasad Kashyap reassigned GERONIMO-2098: Assign To: David Jencks Application migration to Maven 2: remote-deploy --- Key: GERONIMO-2098 URL: http://issues.apache.org/jira/browse/GERONIMO-2098 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: application client Versions: 1.2 Reporter: Prasad Kashyap Assignee: David Jencks Fix For: 1.2 Attachments: remote-deploy.patch Merge remote-deploy-lib with remote-deploy Migrate remote-deploy to M2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[RTC] : Migrate remote-deploy to m2
Merged remote-deploy-lib with remote-deploy. Migrated remote-deploy to M2. http://issues.apache.org/jira/browse/GERONIMO-2098
Re: Frustrations of a Release Manager
I think SuSE-like would be a good idea too. --jason -Original Message- From: Aaron Mulder [EMAIL PROTECTED] Date: Fri, 9 Jun 2006 09:34:39 To:dev@geronimo.apache.org Subject: Re: Frustrations of a Release Manager In the spirit of greater openness and communication, please elaborate on 'thing have been quietly injected into Geronimo'. As far as I can tell, the main source of the 1.1 delay was that the module ID changes (new syntax, groupless or versionless dependencies, etc.) caused a ton of problems, in the TCK, the deployment tools, the console, and so on. When the original deadline came, the product was not stable enough to ship. I'm sure that some of the features I've worked on have contributed -- mainly the keystore changes, which caused some TCK failures until we updated the keystore configuration for it. Still, we've talked about some of the reasons for this, and I think we all want to try to make the 1.2 changes more incremental and keep the TCK passing at all times to avoid major disconnects as we move forward. As far as the release schedule goes, I'm disappointed that we missed the deadline, and then didn't really update our road map... If there was a new target date or plan it seemed pretty informal -- there didn't seem to be anything posted to the dev list or the web site, etc (though based on Jeff's comments it sounds like there was and I missed it?). Now we're trying to put out a release when our only preview/release candidate has been available for less than a week. I contrast that to the SuSE process where there were at least 12 well-defined test builds (9 or more beta builds and 3 or more RC builds) at well-defined interrvals. As a user, I certainly appreciated that I could get and try the latest, submit bug reports, check the release calendar for the date of the next test build, get it and test the fixes, etc. I don't think that one build and 72 hours is sufficient to convince me that 1.1 is a stable release. I don't feel strongly enough to override a majority opinion, if there is one, but I'd like to try a much more SuSE-like release strategy for 1.2 and see how it goes. If that doesn't work so well either, we'll regroup and try something different for the release after. Thanks, Aaron On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Bruce Snyder wrote: On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote: I think it will help to have the schedule of the release. No one can claim IBM has a secret agenda if the time line is laid out there. And it's easy to wink if no one has any idea what the deadlines we're working toward are. I agree with Aaron here - publicity of not only the timeline (i.e., a calendar of release schedules maybe) but also the Road Map may help on all fronts. IMO we should consider publishing and continually revisiting both of these items. I know that this won't be a popular suggestion on the committer side of things because we are a volunteer organization, but it would most certainly help our user community immensely. I have to disagree here. Although I absolutely agree a roadmap is helpful and trackable, the timeline and release issues that Matt has talked about is clearly an issue. On these lists, Matt has made things extremely clear regarding when our releases should be, along with group consensus, and thing have been quietly injected into Geronimo. I share Matt's feelings and frustrations. Minimally, if we cannot hold to a simple date based on agreement on these lists, a roadmap, although helpful, will surely not be a panacea. It is also my hope that there are not private emails going around talking about secret agendas. This would dismay me as I fully expect that we are all adult enough to share our feelings with each other in these lists. If an email like this is being passed around, then we clearly need to be working on our communication skills and have a long way to go on learning to work with each other as a team. I think communication is the primary thing we need to deal with. Jeff A wiki page of the Road Map along with a rough timeline would be a good start. I also think that tying the Road Map to a timeline will cause people to more closely examine the time a particular feature might require. But like the Linux kernel release schedule, determining any kind of regular release schedule may prove to be quite difficult. But IMO it can't hurt to have goals. Just my $0.02. Bruce
Re: Geronimo doesn't startup if restart it using another JDK
Using the ADLER-32 makes much more sence than a hash code. --jason -Original Message- From: Udovichenko, Nellya [EMAIL PROTECTED] Date: Fri, 9 Jun 2006 14:32:43 To:dev@geronimo.apache.org Subject: Geronimo doesn't startup if restart it using another JDK Hello, I have launched Geronimo on Sun JDK. Then I’ve tried to run it with Harmony class library and IBM VM j9. I’ve got the error log below. Also I’ve got the same result when launched Geronimo on Harmony and then - on Sun JDK.š There is a bug in HOWL repaired in howl-1.0.1 by the new parameter (adler32Checksum) adding. At Geronimo startup it checks the log files' validity if they exist. One of verified parameters is the file content control sum. One value of this sum is read from file header and another is calculated by function java.nio.ByteBuffer.hashCode(). So if the algorithms of hash code functions of the JDKs are different Geronimo doesn’t startup. If the parameter adler32Checksum value is false the control sum is calculated by function java.nio.ByteBuffer.hashCode() otherwise it is calculated using ADLER-32 algorithm. Therefore, I think, it would be correct to add this parameter to configs/j2ee-server/src/plan/plan.xml and to gbean org.apache.geronimo.transaction.log.HOWLLog with value 'true'.š Any thoughts? š Thanks, Nellya Udovichenko, Intel Middleware Products Division Error log: $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.4.2_01)... Starting Geronimo Application Server v1.1-20060607 [** ] 11%šš 6s Starting geronimo/j2ee-server/1...14:23:30,3 19 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED s tate: abstractName=geronimo/j2ee-server/1.1-20060607/car?ServiceModule=geronimo /j2ee-server/1.1-20060607/car,j2eeType=TransactionLog,name=HOWLTransactionLog org.objectweb.howl.log.InvalidLogBufferException: CHECKSUM Class: org.objectweb.howl.log.BlockLogBuffer š workerID: š LogFile: C:\Nellya\geronimo-1.1\var\txlog\howl_1.log š HEADER ššš HEADER_ID: 0x484f574c ššš bsn: 0x1 ššš size: 0x8000š should be: 0x8000 ššš data used: 0x4f ššš checkSum: 0x2227d ššš tod: 0x10bb850e3b1 ššš crlf: 0xd0a š FOOTER ššš FOOTER_ID: 0x4c574f48 ššš bsn: 0x1 ššš tod: 0x10bb850e3b1 ššš crlf: 0xd0a ššš at org.objectweb.howl.log.BlockLogBuffer.read(BlockLogBuffer.java:460) ššš at org.objectweb.howl.log.LogFileManager.init(LogFileManager.java:821) ššš at org.objectweb.howl.log.Logger.open(Logger.java:314) ššš at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:893) ššš at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:217) ššš at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:981) ššš at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:267) ššš at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) ššš at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j ava:526) ššš at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) ššš at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) ššš at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe ndency.java:120) ššš at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:173) ššš at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:41) ššš at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) ššš at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:292) ššš at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) ššš at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) ššš at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:540) ššš at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) ššš at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:374) ššš at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) ššš at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:512) ššš at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:493) ššš at
Re: JIRA project for GShell?
Jason Dillon wrote: Can we create a new JIRA project for GShell? I've got a bunch of task/todo items that I would like to track in JIRA so it is easier to prioritize and plan. Thoughts? --jason IMO, if it gets out of the sandbox, it deserves a Jira project. Regards, Alan
Re: Frustrations of a Release Manager
Aaron, Since you asked. First, Can you respond below if you will allow anyone that you have sent a private e-mail to to cut and paste the contents of those messages into other posts on this thread. I think that will help. Second, the geronimoplugins.com which was injected into Geronimo is probably a good place to start. Here is a snip from whois of that domain. I removed the address specific information. Registrant: Address is provided *Removed* Domain Name: GERONIMOPLUGINS.COM Created on: 11-Apr-06 Expires on: 11-Apr-07 Last Updated on: 11-Apr-06 Administrative Contact: Mulder, Erin [EMAIL PROTECTED] Technical Contact: Mulder, Erin [EMAIL PROTECTED] Next we can discuss the hijacking of JIRA for your own purposes. I was working to release 1.1 and you moved over 80 other JIRAs into the release. I don't think that we agreed on how to handle JIRAs but I think it was bad form to assume it was your prioritization mechanism since you were not releasing 1.1. We also discussed how to use JIRA more effectively and you post was all about what YOU wanted which may be unfair to post as you were presenting your opinion but the term I was introduced several times. I can find the post but I suspect its in most people's archives. Shall we begin to discuss the meeting at Java One that you proposed that specifically excluded members of the community. I'd be happy to bring that discussion to the list if you like. Given that IBM paid for the room that the discussion occurred in we are somewhat culpable but given that you were the master mind behind the exclusionary wall I'm happy to have that discussion in the open as well. In the end all I need is a simple e-mail from you to this list allowing folks to paste their private notes from you and we can have it all in the open which was your request. I'm happy to oblige. Bring it on. Matt Aaron Mulder wrote: In the spirit of greater openness and communication, please elaborate on 'thing have been quietly injected into Geronimo'. As far as I can tell, the main source of the 1.1 delay was that the module ID changes (new syntax, groupless or versionless dependencies, etc.) caused a ton of problems, in the TCK, the deployment tools, the console, and so on. When the original deadline came, the product was not stable enough to ship. I'm sure that some of the features I've worked on have contributed -- mainly the keystore changes, which caused some TCK failures until we updated the keystore configuration for it. Still, we've talked about some of the reasons for this, and I think we all want to try to make the 1.2 changes more incremental and keep the TCK passing at all times to avoid major disconnects as we move forward. As far as the release schedule goes, I'm disappointed that we missed the deadline, and then didn't really update our road map... If there was a new target date or plan it seemed pretty informal -- there didn't seem to be anything posted to the dev list or the web site, etc (though based on Jeff's comments it sounds like there was and I missed it?). Now we're trying to put out a release when our only preview/release candidate has been available for less than a week. I contrast that to the SuSE process where there were at least 12 well-defined test builds (9 or more beta builds and 3 or more RC builds) at well-defined interrvals. As a user, I certainly appreciated that I could get and try the latest, submit bug reports, check the release calendar for the date of the next test build, get it and test the fixes, etc. I don't think that one build and 72 hours is sufficient to convince me that 1.1 is a stable release. I don't feel strongly enough to override a majority opinion, if there is one, but I'd like to try a much more SuSE-like release strategy for 1.2 and see how it goes. If that doesn't work so well either, we'll regroup and try something different for the release after. Thanks, Aaron On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Bruce Snyder wrote: On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote: I think it will help to have the schedule of the release. No one can claim IBM has a secret agenda if the time line is laid out there. And it's easy to wink if no one has any idea what the deadlines we're working toward are. I agree with Aaron here - publicity of not only the timeline (i.e., a calendar of release schedules maybe) but also the Road Map may help on all fronts. IMO we should consider publishing and continually revisiting both of these items. I know that this won't be a popular suggestion on the committer side of things because we are a volunteer organization, but it would most certainly help our user community immensely. I have to disagree here. Although I absolutely agree a roadmap is helpful and trackable, the timeline and release issues that Matt has talked about is clearly an issue. On these lists, Matt has made things
Re: DayTrader: Dynamic Ajax-based Web frontend --- update
Cool. :-) --jason -Original Message- From: J. Stan Cox [EMAIL PROTECTED] Date: Thu, 08 Jun 2006 14:14:22 To:dev@geronimo.apache.org Subject: DayTrader: Dynamic Ajax-based Web frontend --- update Hey, I just wanted to send a quick follow up on previous note I sent out about adding a dynamic Web 2.0 interface to DayTrader. Progress has been slow due to other emergencies, but I should have some demo-able code to offer within a couple of weeks. The stock trading theme of DayTrader is perfect for a rich, asynchronous, AJAX based front end. The idea got good support before and I think this will add alot to Geronimo as a sample application. I'm specifically interested in doing some performance analysis to compare the overhead of Web 2.0 over standard request/response style. The original note with the basic design is below. Again, I hope to have some code soon. Stan. J. Stan Cox [EMAIL PROTECTED] Original note: -- Geronimos, I'm one of the original developers of the benchmark Trade that has been donated to Geronimo and is now known as DayTrader. It's amazing what this benchmark has been able to achieve over the last few years and we are very much looking forward to seeing it grow and flourish in the Open Source Geronimo environment. We think it can become a real showcase for Geronimo's performance and capabilities. We are interested in adding a rich, AJAX based Web interface for the DayTrader stock trading services. DayTrader is a perfect type of application to leverage AJAX capablities. We plan to collapse all of the current web pages into a single rich page with dynamic and asynchronous updates of stock prices, user holdings, buys/sells, etc. We would leverage the DoJo AJAX toolkit which is being pulled into Apache MyFaces. So, the basic architecture would look like: browser--- REST--- DayTrader---SOAP--- DayTrader--- Java--- DayTrader (dojo libs, proxy servlet Web services J2EE App javascript) soap/rest transform |--GERONIMO ---| Stan. J. Stan Cox [EMAIL PROTECTED]
Re: Daily post of IRC log to dev?
So far I have not had time to look into this further. I personally want to get a daily email, so when I have time I will set this up. At that time we can discus having it also go to the dev list or not. No worries about tardy replies :-) --jason -Original Message- From: Alan D. Cabrera [EMAIL PROTECTED] Date: Thu, 08 Jun 2006 11:01:57 To:dev@geronimo.apache.org Subject: Re: Daily post of IRC log to dev? Sorry about the tardy reply. I do not think that this is a good idea. It's just noise and I think that people should give appropriate summaries as to what was discussed. Having IRC logs posted to this group is like listening to a recording of a crowded rook w/ multiple conversations going on at the same time. Regards, Alan Jason Dillon wrote: Okay, well so far no one objected... so I am going to look into how we can get this setup. --jason On 5/31/06, Jason Dillon [EMAIL PROTECTED] wrote: Since Apache tends to prefer mailing lists... but IRC is so convent for effective communication. Maybe we should have a daily post of the last days IRC log to the dev list. That was the list can still be used for oversight of stuff that goes on in #geronimo that may have some impact on the project and its health. Just a thought... --jason
Re: Daily post of IRC log to dev?
If you want to start a new list, that would be cool. I would prefer not to have the posting on the dev list. Regards, Alan Jason Dillon wrote: So far I have not had time to look into this further. I personally want to get a daily email, so when I have time I will set this up. At that time we can discus having it also go to the dev list or not. No worries about tardy replies :-) --jason -Original Message- From: "Alan D. Cabrera" [EMAIL PROTECTED] Date: Thu, 08 Jun 2006 11:01:57 To:dev@geronimo.apache.org Subject: Re: Daily post of IRC log to dev? Sorry about the tardy reply. I do not think that this is a good idea. It's just noise and I think that people should give appropriate summaries as to what was discussed. Having IRC logs posted to this group is like listening to a recording of a crowded rook w/ multiple conversations going on at the same time. Regards, Alan Jason Dillon wrote: Okay, well so far no one objected... so I am going to look into how we can get this setup. --jason On 5/31/06, Jason Dillon [EMAIL PROTECTED] wrote: Since Apache tends to prefer mailing lists... but IRC is so convent for effective communication. Maybe we should have a daily post of the last days IRC log to the dev list. That was the list can still be used for oversight of stuff that goes on in #geronimo that may have some impact on the project and its health. Just a thought... --jason
Re: Frustrations of a Release Manager
I like that model too, as long as we can still deliver more than one release a year and we allow more people to have commit access to the sandbox area for more collaboration on major enhancements and changes... -Donald Jason Dillon wrote: I think SuSE-like would be a good idea too. --jason -Original Message- From: Aaron Mulder [EMAIL PROTECTED] Date: Fri, 9 Jun 2006 09:34:39 To:dev@geronimo.apache.org Subject: Re: Frustrations of a Release Manager In the spirit of greater openness and communication, please elaborate on 'thing have been quietly injected into Geronimo'. As far as I can tell, the main source of the 1.1 delay was that the module ID changes (new syntax, groupless or versionless dependencies, etc.) caused a ton of problems, in the TCK, the deployment tools, the console, and so on. When the original deadline came, the product was not stable enough to ship. I'm sure that some of the features I've worked on have contributed -- mainly the keystore changes, which caused some TCK failures until we updated the keystore configuration for it. Still, we've talked about some of the reasons for this, and I think we all want to try to make the 1.2 changes more incremental and keep the TCK passing at all times to avoid major disconnects as we move forward. As far as the release schedule goes, I'm disappointed that we missed the deadline, and then didn't really update our road map... If there was a new target date or plan it seemed pretty informal -- there didn't seem to be anything posted to the dev list or the web site, etc (though based on Jeff's comments it sounds like there was and I missed it?). Now we're trying to put out a release when our only preview/release candidate has been available for less than a week. I contrast that to the SuSE process where there were at least 12 well-defined test builds (9 or more beta builds and 3 or more RC builds) at well-defined interrvals. As a user, I certainly appreciated that I could get and try the latest, submit bug reports, check the release calendar for the date of the next test build, get it and test the fixes, etc. I don't think that one build and 72 hours is sufficient to convince me that 1.1 is a stable release. I don't feel strongly enough to override a majority opinion, if there is one, but I'd like to try a much more SuSE-like release strategy for 1.2 and see how it goes. If that doesn't work so well either, we'll regroup and try something different for the release after. Thanks, Aaron On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Bruce Snyder wrote: On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote: I think it will help to have the schedule of the release. No one can claim IBM has a secret agenda if the time line is laid out there. And it's easy to wink if no one has any idea what the deadlines we're working toward are. I agree with Aaron here - publicity of not only the timeline (i.e., a calendar of release schedules maybe) but also the Road Map may help on all fronts. IMO we should consider publishing and continually revisiting both of these items. I know that this won't be a popular suggestion on the committer side of things because we are a volunteer organization, but it would most certainly help our user community immensely. I have to disagree here. Although I absolutely agree a roadmap is helpful and trackable, the timeline and release issues that Matt has talked about is clearly an issue. On these lists, Matt has made things extremely clear regarding when our releases should be, along with group consensus, and thing have been quietly injected into Geronimo. I share Matt's feelings and frustrations. Minimally, if we cannot hold to a simple date based on agreement on these lists, a roadmap, although helpful, will surely not be a panacea. It is also my hope that there are not private emails going around talking about secret agendas. This would dismay me as I fully expect that we are all adult enough to share our feelings with each other in these lists. If an email like this is being passed around, then we clearly need to be working on our communication skills and have a long way to go on learning to work with each other as a team. I think communication is the primary thing we need to deal with. Jeff A wiki page of the Road Map along with a rough timeline would be a good start. I also think that tying the Road Map to a timeline will cause people to more closely examine the time a particular feature might require. But like the Linux kernel release schedule, determining any kind of regular release schedule may prove to be quite difficult. But IMO it can't hurt to have goals. Just my $0.02. Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: [RTC] : Migrate remote-deploy to m2
I don't think this is quite ready for a vote yet, and I'm not convinced it requires a vote. First, it really should include more of a description of what the purpose of the change is, such as: Due to bugs in the web app classloader in 1.0, the remote deploy war was split into 2 modules. Since that classloader bug has been resolved in 1.1 it's time to merge this stuff back into one module Second, when a patch moves a file, it should not be applied as a patch. The patch might be OK to look at, but we have to preserve svn history, so whoever is going to apply the patch needs to know the svn commands that resulted in the patch. Here we need something like Run these svn commands: svn mv modules/remote-deploy-lib/src/java/..java modules/remote- deploy/src/java/ ... svn rm modules/remote-deploy-lib Other adjustments to make the build work again should be in a patch that does not include the effects of the svn commands. Thirdly I don't think this patch fixes the m1 build unfortunately we can't throw it out yet. The reason I don't think this requires a vote is that it does not change any java code and is part of the bug fix to the web app classloading. However I think since you proposed a vote and we haven't had much practice voting yet it would be a good idea to go through the vote process on this small uncontroversial change. Many thanks david jencks On Jun 9, 2006, at 9:23 AM, Prasad Kashyap wrote: Merged remote-deploy-lib with remote-deploy. Migrated remote-deploy to M2. http://issues.apache.org/jira/browse/GERONIMO-2098
[jira] Updated: (GERONIMO-2098) Application migration to Maven 2: remote-deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2098?page=all ] Prasad Kashyap updated GERONIMO-2098: - Attachment: remote-deploy-v2.patch Instriuctions: - 1. svn mv geronimo\applications\remote-deploy-lib\src\java\org\apache\geronimo\deployment\remote\*.java geronimo\applications\remote-deploy\src\java\org\apache\geronimo\deployment\remote 2. svn rm geronimo\applications\remote-deploy-lib 3. apply patch remote-deploy-v2.patch from geronimo dir. Application migration to Maven 2: remote-deploy --- Key: GERONIMO-2098 URL: http://issues.apache.org/jira/browse/GERONIMO-2098 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: application client Versions: 1.2 Reporter: Prasad Kashyap Assignee: David Jencks Fix For: 1.2 Attachments: remote-deploy-v2.patch, remote-deploy.patch Merge remote-deploy-lib with remote-deploy Migrate remote-deploy to M2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Frustrations of a Release Manager
On 6/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Aaron, Since you asked. First, Can you respond below if you will allow anyone that you have sent a private e-mail to to cut and paste the contents of those messages into other posts on this thread. I think that will help. Sure. Second, the geronimoplugins.com which was injected into Geronimo is probably a good place to start. Here is a snip from whois of that domain. I removed the address specific information. Registrant: Address is provided *Removed* Domain Name: GERONIMOPLUGINS.COM Created on: 11-Apr-06 Expires on: 11-Apr-07 Last Updated on: 11-Apr-06 Administrative Contact: Mulder, Erin [EMAIL PROTECTED] Technical Contact: Mulder, Erin [EMAIL PROTECTED] Yes, of course, that's a domain we got, because the project needs one, and it can't be at Apache (due to the LGPL issue). I've offered a number of times to give people accounts to help manage the site, and so far, no one's taken me up on it. My goals are to provide a Maven repository (=HTTP site) that can hold *all* plugins, ASF, LGPL, GPL, proprietary. Since I didn't see one out there, Erin was gracious enoguh to provide one. And now you're jumping on her for it? That's gratitude! Also, recall that the file defining the available plugin repositories is hosted by the ASF, so the ASF can change the list of available sites away from geronimoplugins.com at any time. What is your counter-proposal? Next we can discuss the hijacking of JIRA for your own purposes. I was working to release 1.1 and you moved over 80 other JIRAs into the release. I don't think that we agreed on how to handle JIRAs but I think it was bad form to assume it was your prioritization mechanism since you were not releasing 1.1. Gosh, I didn't really think I was hijacking Jira. I thought I was using it for its intended purpose, which is to say, tracking the issues with the project, what should be worked on, and who was willing to work on what. Including, of course, a todo list for myself. I honestly had no idea that as release manager, you considered Jira to be your domain, and didn't want people using without what -- your approval? By all means, if you object to something I do like that, please say something! Aaron, I'm trying to use Jira to track the tasks for 1.1, please don't put anything in there unless it's *definitely* going to happen in the next 2 weeks or whatever. I don't remember having those discussions until well after the fact. We also discussed how to use JIRA more effectively and you post was all about what YOU wanted which may be unfair to post as you were presenting your opinion but the term I was introduced several times. I can find the post but I suspect its in most people's archives. Yes of course. I was explaining how I want to use an issue-tracking system. (Were your posts about how Jeff wants to use an issue tracking system?) I thought the point of the thread was for everyone to say what they're looking for so we can then decide the best way to do it as a group. Shall we begin to discuss the meeting at Java One that you proposed that specifically excluded members of the community. I'd be happy to bring that discussion to the list if you like. Given that IBM paid for the room that the discussion occurred in we are somewhat culpable but given that you were the master mind behind the exclusionary wall I'm happy to have that discussion in the open as well. Well, actually, it was kind of a joint idea between myself and a few other people who thought there were some things we ought to talk about so long as we were all together. I'm sorry that there's a perception of an exclusionary wall. It was on us to pay for the food, which at hotel rates was $100 per person for the day, so naturally I wasn't able to invite the entire Geronimo community. I apologize to everyone in the community who wasn't able to be at JavaOne or who wasn't invited, but it seemed like an ideal scenario for many of us to get together and discuss some of the current issues and then take the discussion points to the mailing list. If you objected, why am I first hearing about it now? And anyway, what is the perception of the right thing to do? If it's not economically feasible for every user, contributor, committer, and PMC member to get together does that mean no meeting should happen? If so, will IBM immediately cease having any meetings or phone calls discussing Geronimo issues? Or are you going to provide an international dial-in for every one, and hold them in the middle of the night for the convenience of the Asian community? I don't see what's wrong with a group of folks interested in Gernoimo getting together to talk about Geronimo. So long as it's positioned as discussion not decision-making, of course -- which, as I recall, it was. In the end all I need is a simple e-mail from you to this list allowing folks to paste
Oracle XA Driver in Console (via Plugin)
Here's an attempt to do two things: - demonstrate plugins in action - provide easier access to the Oracle XA driver This will only work on 1.1, specifically http://people.apache.org/dist/geronimo/unstable/1.1-412854 or a future 1.1 build, and you'll need the full J2EE distribution because Little G does not include the console. If you install the plugin called Oracle XA Driver for Console (Jetty/Tomcat) then you'll get an Oracle XA (Test) entry in the console database pool database list. You'll also need to put an Oracle JDBC driver into the Geronimo repository (e.g. Oracle JDBC 9.0.5 for Java 1.4), since we can't redistribute the Oracle JDBC drivers, but the plugin will install the TranQL connector for you and make the configuration screen available. There's still the issue that the TranQL Oracle XA connector RAR does not include any documentation on the settings it uses, and there are a lot of them, so I'm not sure how you'll need to configure it, but hopefully someone here knows. :) Thanks, Aaron
Re: Anschluss - CORBA specs new home
Good point. Maybe we should wait till we graduate. Who knows, Yoko could be a TLP as well. Regards, Alan John Sisson wrote: Don't they have to have incubator as part of the file names and then when they exit the incubator they can remove incubator from the name. Sounds like it may create extra work changing Geronimo POMs to point to the correct files at different stages. Are the groupIDs changing too? John Dain Sundstrom wrote: Projects in the incubator can do releases. They do have a restriction until the IP is cleared, but once that is done they can release using the normal release process. -dain On Jun 5, 2006, at 6:29 PM, Matt Hogstrom wrote: I'm ok with it but would prefer to turn them over after Yoko graduates. My understanding is that an incubator project can't release anything. I expect they don't change a whole lot but that would be my only reservation. Alan D. Cabrera wrote: I think that it's time that we, Yoko, take responsibility for the CORBA spec jars. After Geronimo releases v1.1, let's plan on moving them over to Yoko. Thoughts? Regards, Alan
Sandbox ACL question
Can we modify the Sandbox ACL so people in the contributors group can have svn write authority? It seems that allowing contributors into the sandbox would be a great way for us to provide more complex patches and enhancements while proving our worth towards becoming a committer -Donald smime.p7s Description: S/MIME Cryptographic Signature
Re: Frustrations of a Release Manager
Sigh! :( Looks like all efforts are down the drain. On 6/9/06, Aaron Mulder [EMAIL PROTECTED] wrote: I don't see what's wrong with a group of folks interested in Gernoimo getting together to talk about Geronimo. So long as it's positioned as discussion not decision-making, of course -- which, as I recall, it was.
[jira] Created: (GERONIMO-2099) Source for Console Oracle XA plugin
Source for Console Oracle XA plugin --- Key: GERONIMO-2099 URL: http://issues.apache.org/jira/browse/GERONIMO-2099 Project: Geronimo Type: New Feature Security: public (Regular issues) Components: Plugins Versions: 1.1 Reporter: Aaron Mulder Here's the code used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Plugin versioning problems
Inline below. Aaron Mulder wrote: On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote: BTW - How can we add new Plugins to the geronimoplugins website? Are we going to setup a Geronimo subproject (like Daytrader) with the site framework checked into svn, along with any scripts needed to build the plugins? It seems convoluted to have samples and plugin builds in the main Geronimo tree, which are not shipped with the server or automatically pushed to geronimoplugins. Wouldn't it be easier to maintain if we moved all the samples out to /trunk/samples/modules and all the equivalent plugin configs to /trunk/samples/plugins? That way, the Samples and plugins can be built, published and enhanced separate from the server development Currently, to get a plugin added to the web site, you can mail it to me. If you want to help out there, it would be great to have a script that read the plugin.xml files and emitted the various PHP files with all the plugin info! Currently it's a little more manual. :) We should definitely have a separate are in the SVN tree for the samples. There's no reason they should be tied to the Geronimo release schedule. We also need a non-Apache space where we can write the plugin wrappers for various interesting LGPL projects. If you create a project on Sourceforge or Javaforge, I'll come and help. How about project=geronimoplugins to match the website name? -Donald Thanks, Aaron Aaron Mulder wrote: On 6/7/06, Donald Woods [EMAIL PROTECTED] wrote: Why shouldn't the Plugin support be as robust as module dependencies and allow the user providing the plugin to decide if they can support geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only support predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to me and doesn't follow previous email threads about not deviating from Maven2 versioning behavior... But what you've said here is why shouldn't the plugin support be as robust as A and allow B where A != B. Module dependencies let you specify an exact version or no version. Plugin dependencies also let you specify an exact version or no version. Neither of these support 1.* or 1.1*. Just as with the Tomcat JSP/Servlet Examples, you could easily provide a Plugin which should work on all 1.x releases My preference it to opt-in supported version, not opt-out unsupported versions. So I'd like the plugin developer to try a plugin on a Geronimo version and if it works, list that version as supported. The alternative will most likely lead to Geronimo being willing to install a plugin but the plugin not working. If we get fancier version dependencies we can consider things like 1.1.* but I'm not sure I like that. I'm willing to be convinced, but I'd want to hear from more plugin developers/maintainers. Thanks, Aaron smime.p7s Description: S/MIME Cryptographic Signature
[jira] Updated: (GERONIMO-2099) Source for Console Oracle XA plugin
[ http://issues.apache.org/jira/browse/GERONIMO-2099?page=all ] Aaron Mulder updated GERONIMO-2099: --- Attachment: console-tranql-oracle-xa-plugin.zip Source for Console Oracle XA plugin --- Key: GERONIMO-2099 URL: http://issues.apache.org/jira/browse/GERONIMO-2099 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: Plugins Versions: 1.1 Reporter: Aaron Mulder Attachments: console-tranql-oracle-xa-plugin.zip Here's the code used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Plugin versioning problems
Sourceforge is kind of slow, which is my main objection. But perhaps we can use it as a start. What's Javaforge? Thanks, Aaron On 6/9/06, Donald Woods [EMAIL PROTECTED] wrote: Inline below. Aaron Mulder wrote: On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote: BTW - How can we add new Plugins to the geronimoplugins website? Are we going to setup a Geronimo subproject (like Daytrader) with the site framework checked into svn, along with any scripts needed to build the plugins? It seems convoluted to have samples and plugin builds in the main Geronimo tree, which are not shipped with the server or automatically pushed to geronimoplugins. Wouldn't it be easier to maintain if we moved all the samples out to /trunk/samples/modules and all the equivalent plugin configs to /trunk/samples/plugins? That way, the Samples and plugins can be built, published and enhanced separate from the server development Currently, to get a plugin added to the web site, you can mail it to me. If you want to help out there, it would be great to have a script that read the plugin.xml files and emitted the various PHP files with all the plugin info! Currently it's a little more manual. :) We should definitely have a separate are in the SVN tree for the samples. There's no reason they should be tied to the Geronimo release schedule. We also need a non-Apache space where we can write the plugin wrappers for various interesting LGPL projects. If you create a project on Sourceforge or Javaforge, I'll come and help. How about project=geronimoplugins to match the website name? -Donald Thanks, Aaron Aaron Mulder wrote: On 6/7/06, Donald Woods [EMAIL PROTECTED] wrote: Why shouldn't the Plugin support be as robust as module dependencies and allow the user providing the plugin to decide if they can support geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only support predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to me and doesn't follow previous email threads about not deviating from Maven2 versioning behavior... But what you've said here is why shouldn't the plugin support be as robust as A and allow B where A != B. Module dependencies let you specify an exact version or no version. Plugin dependencies also let you specify an exact version or no version. Neither of these support 1.* or 1.1*. Just as with the Tomcat JSP/Servlet Examples, you could easily provide a Plugin which should work on all 1.x releases My preference it to opt-in supported version, not opt-out unsupported versions. So I'd like the plugin developer to try a plugin on a Geronimo version and if it works, list that version as supported. The alternative will most likely lead to Geronimo being willing to install a plugin but the plugin not working. If we get fancier version dependencies we can consider things like 1.1.* but I'm not sure I like that. I'm willing to be convinced, but I'd want to hear from more plugin developers/maintainers. Thanks, Aaron
[jira] Updated: (GERONIMO-2099) Source for Console Oracle XA plugin
[ http://issues.apache.org/jira/browse/GERONIMO-2099?page=all ] Aaron Mulder updated GERONIMO-2099: --- Description: Here's the code used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/(category)/(plugin)/trunk... in SVN It's a little cheesy in that it uses a couple class files from the console, but it seems like we need to move those classes out of the console WAR in order to refer to them from a child module classpath. was:Here's the code used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/... Source for Console Oracle XA plugin --- Key: GERONIMO-2099 URL: http://issues.apache.org/jira/browse/GERONIMO-2099 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: Plugins Versions: 1.1 Reporter: Aaron Mulder Attachments: console-tranql-oracle-xa-plugin.zip Here's the code used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/(category)/(plugin)/trunk... in SVN It's a little cheesy in that it uses a couple class files from the console, but it seems like we need to move those classes out of the console WAR in order to refer to them from a child module classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Frustrations of a Release Manager
On 6/9/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Sigh! :( Looks like all efforts are down the drain. I'm not sure what this means. Can you elaborate? Thanks, Aaron On 6/9/06, Aaron Mulder [EMAIL PROTECTED] wrote: I don't see what's wrong with a group of folks interested in Gernoimo getting together to talk about Geronimo. So long as it's positioned as discussion not decision-making, of course -- which, as I recall, it was.
Re: Frustrations of a Release Manager
I have entered my own comments below... Aaron Mulder wrote: On 6/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Aaron, Since you asked. First, Can you respond below if you will allow anyone that you have sent a private e-mail to to cut and paste the contents of those messages into other posts on this thread. I think that will help. Sure. Second, the geronimoplugins.com which was injected into Geronimo is probably a good place to start. Here is a snip from whois of that domain. I removed the address specific information. Registrant: Address is provided *Removed* Domain Name: GERONIMOPLUGINS.COM Created on: 11-Apr-06 Expires on: 11-Apr-07 Last Updated on: 11-Apr-06 Administrative Contact: Mulder, Erin [EMAIL PROTECTED] Technical Contact: Mulder, Erin [EMAIL PROTECTED] Yes, of course, that's a domain we got, because the project needs one, and it can't be at Apache (due to the LGPL issue). I've offered a number of times to give people accounts to help manage the site, and so far, no one's taken me up on it. My goals are to provide a Maven repository (=HTTP site) that can hold *all* plugins, ASF, LGPL, GPL, proprietary. Since I didn't see one out there, Erin was gracious enoguh to provide one. And now you're jumping on her for it? That's gratitude! Also, recall that the file defining the available plugin repositories is hosted by the ASF, so the ASF can change the list of available sites away from geronimoplugins.com at any time. What is your counter-proposal? I brought this up as an issue originally as it bothered me. This has nothing to do with Erin, so let's not obfuscate the issue. The point here is there was absolutely no discussion about this, as this was clearly a fairly large decision that we, as a community, should have been involved in. Unless I missed something, I do not recall anyone talking about registering a site with Geronimo plugins before it occurred. This also bothered me as a peer, since a lot of the work I did on the Directory server integration was taken out of Geronimo, then wrapped up into a plugin and placed on this external site, without input from others, as well as those who did the hard work on integration. Although nothing in the Apache License prohibits you from doing this, it would have been prudent and shown respect to your peers who put together the example applications and the Directory integration, to have had some discussions about doing this and how they felt about it. Its more of a ethical and respect issue, IMHO. As for your question, my counter proposal is having significant discussion with others before taking action. Relative to the private emails, I received an email from you privately after I brought up the geronimoplugins that was very aggressive, along with verbiage that bordered on threatening language. Your private email to me started out with Watch your tone. This is the intimidation stuff that I have referred to in the past, and it concerns me quite a bit. Shall we begin to discuss the meeting at Java One that you proposed that specifically excluded members of the community. I'd be happy to bring that discussion to the list if you like. Given that IBM paid for the room that the discussion occurred in we are somewhat culpable but given that you were the master mind behind the exclusionary wall I'm happy to have that discussion in the open as well. Well, actually, it was kind of a joint idea between myself and a few other people who thought there were some things we ought to talk about so long as we were all together. I'm sorry that there's a perception of an exclusionary wall. It was on us to pay for the food, which at hotel rates was $100 per person for the day, so naturally I wasn't able to invite the entire Geronimo community. I apologize to everyone in the community who wasn't able to be at JavaOne or who wasn't invited, but it seemed like an ideal scenario for many of us to get together and discuss some of the current issues and then take the discussion points to the mailing list. If you objected, why am I first hearing about it now? I attended for a total of about an hour. I am speaking from hearsay here...but was Geir's presence, or lack-there-of discussed? I was told by someone that it was actually discussed at the meeting. And anyway, what is the perception of the right thing to do? If it's not economically feasible for every user, contributor, committer, and PMC member to get together does that mean no meeting should happen? If so, will IBM immediately cease having any meetings or phone calls discussing Geronimo issues? Or are you going to provide an international dial-in for every one, and hold them in the middle of the night for the convenience of the Asian community? I don't see what's wrong with a group of folks interested in Gernoimo getting together to talk about Geronimo. So
Re: Frustrations of a Release Manager
On 6/9/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Sigh! :( Looks like all efforts are down the drain. On 6/9/06, Aaron Mulder [EMAIL PROTECTED] wrote: I don't see what's wrong with a group of folks interested in Gernoimo getting together to talk about Geronimo. So long as it's positioned as discussion not decision-making, of course -- which, as I recall, it was. Dims, statements like that don't work to bring the community together, they only cause more animosity. Let's try to move beyond the jabs and let the people with unresolved issues air their concerns so that they can work together. Yet again I'm now thoroughly confused on this whole topic. Does this mean that nobody can even talk about Geronimo unless it's on-list in some way? Does this mean if someone at a client site or a local JUG or anywhere asks me questions about Geronimo that I must either tell them to ask on the list because I'm not allowed to talk about it or post my conversation to the list after the fact? I really am seriously confused because of so many mixed messages from so many people about this topic. Please help me understand. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: Frustrations of a Release Manager
I just saw this thread and want to say my 2c, I haven't yet read the other threads and have to run out so sorry if this statement has been repeated. The most important thing we can do to make the project succeed is to ship, and to ship often. Moving forward we need to have a fixed interval of when we release and based on those intervals each of us need to be accountable on what we can commit. We desperately need to be able to give-up function, meaning we must be willing to modify our roadmap of contained items and defer items if they cannot be contained within the schedule, rather then push out the schedule which seems to be the easy answer. If we can prove to our users that they can constantly expect releases at consistent intervals this would be a huge win. Take a look at the Callisto effort in Eclipse. Not only has the Eclipse project not missed a release date in who knows how long (if ever), but now they are releasing 10 top level projects simultaneously. I say we learn from the eclipse model, follow it, and tweak the process to our needs. -sachin On Jun 9, 2006, at 9:34 AM, Aaron Mulder wrote: In the spirit of greater openness and communication, please elaborate on 'thing have been quietly injected into Geronimo'. As far as I can tell, the main source of the 1.1 delay was that the module ID changes (new syntax, groupless or versionless dependencies, etc.) caused a ton of problems, in the TCK, the deployment tools, the console, and so on. When the original deadline came, the product was not stable enough to ship. I'm sure that some of the features I've worked on have contributed -- mainly the keystore changes, which caused some TCK failures until we updated the keystore configuration for it. Still, we've talked about some of the reasons for this, and I think we all want to try to make the 1.2 changes more incremental and keep the TCK passing at all times to avoid major disconnects as we move forward. As far as the release schedule goes, I'm disappointed that we missed the deadline, and then didn't really update our road map... If there was a new target date or plan it seemed pretty informal -- there didn't seem to be anything posted to the dev list or the web site, etc (though based on Jeff's comments it sounds like there was and I missed it?). Now we're trying to put out a release when our only preview/release candidate has been available for less than a week. I contrast that to the SuSE process where there were at least 12 well-defined test builds (9 or more beta builds and 3 or more RC builds) at well-defined interrvals. As a user, I certainly appreciated that I could get and try the latest, submit bug reports, check the release calendar for the date of the next test build, get it and test the fixes, etc. I don't think that one build and 72 hours is sufficient to convince me that 1.1 is a stable release. I don't feel strongly enough to override a majority opinion, if there is one, but I'd like to try a much more SuSE-like release strategy for 1.2 and see how it goes. If that doesn't work so well either, we'll regroup and try something different for the release after. Thanks, Aaron On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Bruce Snyder wrote: On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote: I think it will help to have the schedule of the release. No one can claim IBM has a secret agenda if the time line is laid out there. And it's easy to wink if no one has any idea what the deadlines we're working toward are. I agree with Aaron here - publicity of not only the timeline (i.e., a calendar of release schedules maybe) but also the Road Map may help on all fronts. IMO we should consider publishing and continually revisiting both of these items. I know that this won't be a popular suggestion on the committer side of things because we are a volunteer organization, but it would most certainly help our user community immensely. I have to disagree here. Although I absolutely agree a roadmap is helpful and trackable, the timeline and release issues that Matt has talked about is clearly an issue. On these lists, Matt has made things extremely clear regarding when our releases should be, along with group consensus, and thing have been quietly injected into Geronimo. I share Matt's feelings and frustrations. Minimally, if we cannot hold to a simple date based on agreement on these lists, a roadmap, although helpful, will surely not be a panacea. It is also my hope that there are not private emails going around talking about secret agendas. This would dismay me as I fully expect that we are all adult enough to share our feelings with each other in these lists. If an email like this is being passed around, then we clearly need to be working on our communication skills and have a long way to go on learning to work with each other as a team. I think communication is the primary thing we need to
Re: Frustrations of a Release Manager
Aaron, Sure. I assumed for a bit that the RTC [1] and PMC Changes [2] instituted by our pmc chair had sent a strong signal and wrongfully thought that had its desired effect, which is to help improve collaboration and make sure there are no exclusionary walls w.r.t participating in Geronimo development. -- dims [1] http://marc.theaimsgroup.com/?l=geronimo-devm=114825592721785w=2 [2] http://geronimo.apache.org/contributors.html On 6/9/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 6/9/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Sigh! :( Looks like all efforts are down the drain. I'm not sure what this means. Can you elaborate? Thanks, Aaron On 6/9/06, Aaron Mulder [EMAIL PROTECTED] wrote: I don't see what's wrong with a group of folks interested in Gernoimo getting together to talk about Geronimo. So long as it's positioned as discussion not decision-making, of course -- which, as I recall, it was. -- Davanum Srinivas : http://wso2.com/blogs/
[jira] Updated: (GERONIMO-2098) Application migration to Maven 2: remote-deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2098?page=all ] Prasad Kashyap updated GERONIMO-2098: - Attachment: remote-deploy-v3.patch Please apply remote-deploy-v3.patch. It takes care of the configs too in an m1 build. This has been deployed on an m1 server and it starts. Application migration to Maven 2: remote-deploy --- Key: GERONIMO-2098 URL: http://issues.apache.org/jira/browse/GERONIMO-2098 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: application client Versions: 1.2 Reporter: Prasad Kashyap Assignee: David Jencks Fix For: 1.2 Attachments: remote-deploy-v2.patch, remote-deploy-v3.patch, remote-deploy.patch Merge remote-deploy-lib with remote-deploy Migrate remote-deploy to M2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Frustrations of a Release Manager
On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: I brought this up as an issue originally as it bothered me. This has nothing to do with Erin, so let's not obfuscate the issue. The point here is there was absolutely no discussion about this, as this was clearly a fairly large decision that we, as a community, should have been involved in. Unless I missed something, I do not recall anyone talking about registering a site with Geronimo plugins before it occurred. Um... OK. I didn't think setting up a site to hold the plugins was that big a deal. If it bothered you, I'm sorry. Let's talk about it. What do you recommend? The constraints I see are that is should be able to host Apache, GPL, LGPL, and commercial code. Do you agree? Disagree? What do you recommend for a hosting site? This also bothered me as a peer, since a lot of the work I did on the Directory server integration was taken out of Geronimo, then wrapped up into a plugin and placed on this external site, without input from others, as well as those who did the hard work on integration. I find this extra-confusing. I took a piece of Geronimo which was hard-coded into the product (e.g. via our assembly system) and made it a modular part of the product (e.g. a plugin that you can install or not as you please). And you feel that as the primary author of the code, you should have been consulted? That I'm somehow using your own hard work to my advantage instead of to improve the product as a whole? I'm sorry for offending you. But I don't understand your objection. Although nothing in the Apache License prohibits you from doing this, it would have been prudent and shown respect to your peers who put together the example applications and the Directory integration, to have had some discussions about doing this and how they felt about it. Its more of a ethical and respect issue, IMHO. I think we agreed that it was a mistake to include so much (samples, LDAP, etc.) in the base Geronimo distribution. The Java 5 stack trace in Geronimo 1.0 was directly attributable to this, plus we've been working hard to slim down our distributions. I am pretty sure we agreed on that in discussions on the list, though it's been a while. But I still don't understand how changing or repackaging code is showing disrespect. We're all in this together, and it's not your code or my code, it's our code. I promise, if you make the console more modular so it runs in Little G just as well as Big G, I won't be offended, I'll buy you a beer. As for your question, my counter proposal is having significant discussion with others before taking action. Well, OK, as I said, let's have the discussion. Sorry it wasn't sooner, but better late than never, eh? Relative to the private emails, I received an email from you privately after I brought up the geronimoplugins that was very aggressive, along with verbiage that bordered on threatening language. Your private email to me started out with Watch your tone. This is the intimidation stuff that I have referred to in the past, and it concerns me quite a bit. Yeah, I admit, I was a little fired up after you posted my address to the list. :) Sorry. I attended for a total of about an hour. I am speaking from hearsay here...but was Geir's presence, or lack-there-of discussed? I was told by someone that it was actually discussed at the meeting. This in-and-of-itself is the issue. Knowing Geir was in town, and especially knowing the fact that he was responsible for obtaining a speaker pass for you at JavaOne, I am having a difficult time understanding how or why he would be excluded from the event. JavaOne is a time many of us (Geronimo) come together, and I believe we all should have the opportunity to be together, regardless of our feelings (positive or negative) about each other. For those who could not attend, a dial-in probably could have been arranged. This should have been more open, and I am myself guilty for attending this when I noticed not everyone was there. We have all earned the privilege to be on Geronimo due to our dedication, contributions, and commitments we have made to Apache and Geronimo. We all should have the opportunity to engage as well. I am sure there were a number of people at JavaOne who were not invited, Geir and others. True, it would have been smart to arrange a dial-in. Ideally, many of the non-committers would have been involved as well, as their dedication and contributions should not be overlooked either. If the outcome of this is that no one should have a meeting unless the whole community is invited, I can work with that (but I don't think that's necessarily reasonable). I talked to another committer at a different conference recently, and we brainstormed some ideas for improving the product. Was that wrong? Where's the line? Is 5 people OK but 15 isn't? If there was some policy, believe me, I'd work with it. Perhaps we should organize a series of
Re: 1.1 Release plan
So as I understand this, the plan is: - new release candidate today, no more non-critical patches - begin voting for that release candidate today - if critical bugs are found within 72 hours, someone will -1 the vote, we will fix and cut a new release candidate, and start a new 72-hour vote I'm OK with that for this release (I don't think it's ideal, but I agree that it will be nice to get this release out the door, so I'm on board). I hope someone will look at the weird web services error during deployment, because I don't know what to make of that (if it's reproduceable and how significant it is). If I'm right about the release plan, I think we should create a SVN home for 1.1.1-SNAPSHOT now so there's a place to put non-critical patches. It will be annoying to put critical patches into 3 places, but we're hoping there aren't any of those. Thanks, Aaron On 6/8/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Final Items for 1.1 I would like to release Geronimo 1.1 on June 12th. Yes, that is three days away. If we can't make that date then it will be 72 hours away from each candidate build. Problem that are found need to be addressed if they are deemed critical. Otherwise they will be tracked and solved in a follow on release. That said. I sent a note earlier today announcing the freeze to branches/1.1. Changes to this branch should be limited to bug fixes only. The little changes are the ones that generally burn you. At 1400 ET the Inn is closed and I will spin up a release that will be our release candidate. The issues that have been raised from the previous build were Guillaume's observation of the problem when running Geronimo under CygWin as well as the license and Notice issues. Since Geronimo is a multifaceted project there are several things that need to be voted on. They are Geronimo itself, the specification jars and DayTrader. Geronimo itself is the significant component that will carry the other items so I believe a vote for Geronimo in this context is a vote for all three items. *There is a concern about the specification jars* David Jencks raised this issue in another note on the list. The jars have not been released but they have had a tag cut and the resulting compilation has been placed on http://people.apache.org/repository. One of the issues I found with the spec is that there are different spec releases in the 1_1 tag. I would prefer that all jars have the same version suffix. Right now it includes 1.0, 1.0.1, 1.1 and others. I think this is confusing. We release Geronimo with all the same module versions even if nothing has changed. I would like to move that we recut a 1_2 tag with all spec jars having a 1.2 suffix. *DayTrader* Day Trader is currently a 1.1-SNAPSHOT as well. We will release the DayTrader Ear (separate from Geronimo) as a 1.1 version as well. This way the build will be in sync. *Issues* 1. It was noted earlier today that there is a problem with Geronimo under CygWin. Guillaume noted that an issue exists where a file is not renamed (config.xml). Given that CygWin is a hybrid environment I think we should investigate this problem but not hold up the release. 2. Guillaume also pointed out the lack of a License and Notices file. I will include the two files from the SVN geronimo/branches/1.1 in the build tomorrow. 3. Numerous bug fixes are being addressed. Excellent. Apart from Spec issue above I think we have most everything addressed. Does this list of outstanding items and release plan make sense? Matt
Re: Frustrations of a Release Manager
Aaron Mulder wrote: On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: I brought this up as an issue originally as it bothered me. This has nothing to do with Erin, so let's not obfuscate the issue. The point here is there was absolutely no discussion about this, as this was clearly a fairly large decision that we, as a community, should have been involved in. Unless I missed something, I do not recall anyone talking about registering a site with Geronimo plugins before it occurred. Um... OK. I didn't think setting up a site to hold the plugins was that big a deal. If it bothered you, I'm sorry. Let's talk about it. What do you recommend? The constraints I see are that is should be able to host Apache, GPL, LGPL, and commercial code. Do you agree? Disagree? What do you recommend for a hosting site? Lets make this another thread...I have several thoughts on this. Thanks for asking. This also bothered me as a peer, since a lot of the work I did on the Directory server integration was taken out of Geronimo, then wrapped up into a plugin and placed on this external site, without input from others, as well as those who did the hard work on integration. I find this extra-confusing. I took a piece of Geronimo which was hard-coded into the product (e.g. via our assembly system) and made it a modular part of the product (e.g. a plugin that you can install or not as you please). And you feel that as the primary author of the code, you should have been consulted? That I'm somehow using your own hard work to my advantage instead of to improve the product as a whole? I'm sorry for offending you. But I don't understand your objection. There is no obligation for you to consult me to take the Directory integration, re-package it, and place it on geronimoplugins.com. But out of basic respect, opening up the discussion of others on the idea, and then yes, as your friend, and colleague, asking me how I felt about taking the package and placing it on gp.com (which I did write and spend my time putting together), probably would have been most appropriate. It is kind of demoralizing for me to see the work that I did, end up on the geronoimplugins site w/o discussion from a colleague of mine. I hope that makes sense... Although nothing in the Apache License prohibits you from doing this, it would have been prudent and shown respect to your peers who put together the example applications and the Directory integration, to have had some discussions about doing this and how they felt about it. Its more of a ethical and respect issue, IMHO. I think we agreed that it was a mistake to include so much (samples, LDAP, etc.) in the base Geronimo distribution. The Java 5 stack trace in Geronimo 1.0 was directly attributable to this, plus we've been working hard to slim down our distributions. I am pretty sure we agreed on that in discussions on the list, though it's been a while. But I still don't understand how changing or repackaging code is showing disrespect. We're all in this together, and it's not your code or my code, it's our code. I promise, if you make the console more modular so it runs in Little G just as well as Big G, I won't be offended, I'll buy you a beer. Yes...nothing wrong with the removal. It was the sudden appearance on geronimoplugins.com that I took issue with. This was purely a communication thing for me. As for your question, my counter proposal is having significant discussion with others before taking action. Well, OK, as I said, let's have the discussion. Sorry it wasn't sooner, but better late than never, eh? Yes, and thanks for acknowledging this. Relative to the private emails, I received an email from you privately after I brought up the geronimoplugins that was very aggressive, along with verbiage that bordered on threatening language. Your private email to me started out with Watch your tone. This is the intimidation stuff that I have referred to in the past, and it concerns me quite a bit. Yeah, I admit, I was a little fired up after you posted my address to the list. :) Sorry. Its ok...we sometimes read into things deeper than we should. As I have told you on the side, and I will publicly state again...I meant nothing by this negatively. It was a cut and paste from the publicly available whois database, and assumed it was purely public...and I certainly did not know it was your address (I assumed it may have been an office or other), but in retrospect, I agree I shouldn't have done that and I apologized publicly for it. I attended for a total of about an hour. I am speaking from hearsay here...but was Geir's presence, or lack-there-of discussed? I was told by someone that it was actually discussed at the meeting. This in-and-of-itself is the issue. Knowing Geir was in town, and especially knowing the fact that he was responsible for obtaining a speaker pass for you at JavaOne,
Re: [RTC] : Migrate remote-deploy to m2
Sounds good. As per your comments I have attached instructions in the comments and a patch (remote-deploy-v3.patch) that will also take into account m1 build. Please review and vote. Cheers Prasad On 6/9/06, David Jencks [EMAIL PROTECTED] wrote: I don't think this is quite ready for a vote yet, and I'm not convinced it requires a vote. First, it really should include more of a description of what the purpose of the change is, such as: Due to bugs in the web app classloader in 1.0, the remote deploy war was split into 2 modules. Since that classloader bug has been resolved in 1.1 it's time to merge this stuff back into one module Second, when a patch moves a file, it should not be applied as a patch. The patch might be OK to look at, but we have to preserve svn history, so whoever is going to apply the patch needs to know the svn commands that resulted in the patch. Here we need something like Run these svn commands: svn mv modules/remote-deploy-lib/src/java/..java modules/remote- deploy/src/java/ ... svn rm modules/remote-deploy-lib Other adjustments to make the build work again should be in a patch that does not include the effects of the svn commands. Thirdly I don't think this patch fixes the m1 build unfortunately we can't throw it out yet. The reason I don't think this requires a vote is that it does not change any java code and is part of the bug fix to the web app classloading. However I think since you proposed a vote and we haven't had much practice voting yet it would be a good idea to go through the vote process on this small uncontroversial change. Many thanks david jencks On Jun 9, 2006, at 9:23 AM, Prasad Kashyap wrote: Merged remote-deploy-lib with remote-deploy. Migrated remote-deploy to M2. http://issues.apache.org/jira/browse/GERONIMO-2098
Re: Frustrations of a Release Manager
On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: There is no obligation for you to consult me to take the Directory integration, re-package it, and place it on geronimoplugins.com. But out of basic respect, opening up the discussion of others on the idea, and then yes, as your friend, and colleague, asking me how I felt about taking the package and placing it on gp.com (which I did write and spend my time putting together), probably would have been most appropriate. It is kind of demoralizing for me to see the work that I did, end up on the geronoimplugins site w/o discussion from a colleague of mine. I hope that makes sense... Some code that you wrote and licensed using the Apache License got reused and you find it demoralizing? This is completely in the letter and the spirit of the Apace License. How is such reuse demoralizing? Not only is this legal, it's encouraged. Please help me understand this sentiment. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: Frustrations of a Release Manager
Bruce Snyder wrote: On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: There is no obligation for you to consult me to take the Directory integration, re-package it, and place it on geronimoplugins.com. But out of basic respect, opening up the discussion of others on the idea, and then yes, as your friend, and colleague, asking me how I felt about taking the package and placing it on gp.com (which I did write and spend my time putting together), probably would have been most appropriate. It is kind of demoralizing for me to see the work that I did, end up on the geronoimplugins site w/o discussion from a colleague of mine. I hope that makes sense... Some code that you wrote and licensed using the Apache License got reused and you find it demoralizing? This is completely in the letter and the spirit of the Apace License. How is such reuse demoralizing? Not only is this legal, it's encouraged. Please help me understand this sentiment. Bruce, Perhaps I am not being very good at communicating...let me paste what I wrote before, and you can perhaps show me the error of my feelings... Although nothing in the Apache License prohibits you from doing this, it would have been prudent and shown respect to your peers who put together the example applications and the Directory integration, to have had some discussions about doing this and how they felt about it. Its more of a ethical and respect issue, IMHO. The words I am trying to convey here are ethical, respect, and prudent. Being that we are all friends, I think we can abide by the spirit of the law, rather than the letter. Would you agree? Jeff Bruce
[jira] Created: (SM-449) Create a set of annotations for a JBI binding for jaxws
Create a set of annotations for a JBI binding for jaxws --- Key: SM-449 URL: https://issues.apache.org/activemq/browse/SM-449 Project: ServiceMix Type: New Feature Components: servicemix-jsr181 Reporter: Guillaume Nodet It would require hacking a bit XFire to also generate the needed wsdl binding infos. Not sure if it is really needed however. We also need a wsdl-java which can handle a wsdl without a soap binding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Frustrations of a Release Manager
On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Bruce Snyder wrote: On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: There is no obligation for you to consult me to take the Directory integration, re-package it, and place it on geronimoplugins.com. But out of basic respect, opening up the discussion of others on the idea, and then yes, as your friend, and colleague, asking me how I felt about taking the package and placing it on gp.com (which I did write and spend my time putting together), probably would have been most appropriate. It is kind of demoralizing for me to see the work that I did, end up on the geronoimplugins site w/o discussion from a colleague of mine. I hope that makes sense... Some code that you wrote and licensed using the Apache License got reused and you find it demoralizing? This is completely in the letter and the spirit of the Apace License. How is such reuse demoralizing? Not only is this legal, it's encouraged. Please help me understand this sentiment. Bruce, Perhaps I am not being very good at communicating...let me paste what I wrote before, and you can perhaps show me the error of my feelings... Although nothing in the Apache License prohibits you from doing this, it would have been prudent and shown respect to your peers who put together the example applications and the Directory integration, to have had some discussions about doing this and how they felt about it. Its more of a ethical and respect issue, IMHO. The words I am trying to convey here are ethical, respect, and prudent. Being that we are all friends, I think we can abide by the spirit of the law, rather than the letter. Would you agree? Well I think we're just going to have to agree to disagree on this topic. I don't care if my code is reused, twisted, refactored, deleted or otherwise. When I apply the Apache License to my code, I hope that others reuse it in some way. I actually do consider this reuse ethical and respectful. I take it as the highest complement that someone would reuse my code because it means that I saved them the trouble of reinventing the wheel. I think that it's our interpretations that differ. Are you simply looking for a tip of the hat type of thing or something more? Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: Frustrations of a Release Manager
Comment below... Bruce Snyder wrote: On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Bruce Snyder wrote: On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: There is no obligation for you to consult me to take the Directory integration, re-package it, and place it on geronimoplugins.com. But out of basic respect, opening up the discussion of others on the idea, and then yes, as your friend, and colleague, asking me how I felt about taking the package and placing it on gp.com (which I did write and spend my time putting together), probably would have been most appropriate. It is kind of demoralizing for me to see the work that I did, end up on the geronoimplugins site w/o discussion from a colleague of mine. I hope that makes sense... Some code that you wrote and licensed using the Apache License got reused and you find it demoralizing? This is completely in the letter and the spirit of the Apace License. How is such reuse demoralizing? Not only is this legal, it's encouraged. Please help me understand this sentiment. Bruce, Perhaps I am not being very good at communicating...let me paste what I wrote before, and you can perhaps show me the error of my feelings... Although nothing in the Apache License prohibits you from doing this, it would have been prudent and shown respect to your peers who put together the example applications and the Directory integration, to have had some discussions about doing this and how they felt about it. Its more of a ethical and respect issue, IMHO. The words I am trying to convey here are ethical, respect, and prudent. Being that we are all friends, I think we can abide by the spirit of the law, rather than the letter. Would you agree? Well I think we're just going to have to agree to disagree on this topic. I don't care if my code is reused, twisted, refactored, deleted or otherwise. When I apply the Apache License to my code, I hope that others reuse it in some way. I actually do consider this reuse ethical and respectful. I take it as the highest complement that someone would reuse my code because it means that I saved them the trouble of reinventing the wheel. I think that it's our interpretations that differ. Are you simply looking for a tip of the hat type of thing or something more? No Bruce, thats not it at all. Its simply discussing what he was going to do. This all comes back to the lack of communication issue. Bruce
Re: Geronimo doesn't startup if restart it using another JDK
As jason pointed out using a hash code isn't portable. This is a known problem in Howl and IIRC they added an optional flag in howl to use a specified hash algorithm. Anyway, please create a JIRA (http:// issues.apache.org/jira/browse/GERONIMO) for this issue. -dain On Jun 9, 2006, at 3:32 AM, Udovichenko, Nellya wrote: Hello, I have launched Geronimo on Sun JDK. Then I’ve tried to run it with Harmony class library and IBM VM j9. I’ve got the error log below. Also I’ve got the same result when launched Geronimo on Harmony and then - on Sun JDK. There is a bug in HOWL repaired in howl-1.0.1 by the new parameter (adler32Checksum) adding. At Geronimo startup it checks the log files' validity if they exist. One of verified parameters is the file content control sum. One value of this sum is read from file header and another is calculated by function java.nio.ByteBuffer.hashCode (). So if the algorithms of hash code functions of the JDKs are different Geronimo doesn’t startup. If the parameter adler32Checksum value is false the control sum is calculated by function java.nio.ByteBuffer.hashCode() otherwise it is calculated using ADLER-32 algorithm. Therefore, I think, it would be correct to add this parameter to configs/j2ee-server/src/plan/plan.xml and to gbean org.apache.geronimo.transaction.log.HOWLLog with value 'true'. Any thoughts? Thanks, Nellya Udovichenko, Intel Middleware Products Division Error log: $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.4.2_01)... Starting Geronimo Application Server v1.1-20060607 [** ] 11% 6s Starting geronimo/j2ee-server/ 1...14:23:30,3 19 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED s tate: abstractName=geronimo/j2ee-server/1.1-20060607/car? ServiceModule=geronimo /j2ee-server/1.1-20060607/ car,j2eeType=TransactionLog,name=HOWLTransactionLog org.objectweb.howl.log.InvalidLogBufferException: CHECKSUM Class: org.objectweb.howl.log.BlockLogBuffer workerID: LogFile: C:\Nellya\geronimo-1.1\var\txlog\howl_1.log HEADER HEADER_ID: 0x484f574c bsn: 0x1 size: 0x8000 should be: 0x8000 data used: 0x4f checkSum: 0x2227d tod: 0x10bb850e3b1 crlf: 0xd0a FOOTER FOOTER_ID: 0x4c574f48 bsn: 0x1 tod: 0x10bb850e3b1 crlf: 0xd0a at org.objectweb.howl.log.BlockLogBuffer.read (BlockLogBuffer.java:460) at org.objectweb.howl.log.LogFileManager.init (LogFileManager.java:821) at org.objectweb.howl.log.Logger.open(Logger.java:314) at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:893) at org.apache.geronimo.transaction.log.HOWLLog.doStart (HOWLLog.java:217) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start (GBeanInstance.j ava:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency $1.running(GBeanDepe ndency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor $RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:512) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:493) at
Re: JIRA project for GShell?
On Jun 9, 2006, at 9:35 AM, Alan D. Cabrera wrote: Jason Dillon wrote: Can we create a new JIRA project for GShell? I've got a bunch of task/todo items that I would like to track in JIRA so it is easier to prioritize and plan. Thoughts? --jason IMO, if it gets out of the sandbox, it deserves a Jira project. I seen no reason not to give it a JIRA. If it dies in the sandbox, we can always delete the JIRA. -dain
Some features for 1.1.1 -- module/deployment extensions
FYI, I plan to address http://issues.apache.org/jira/browse/GERONIMO-1873 as soon as possible in 1.1.1. I'd like plugins to be able to define new deployment unit formats (e.g. JBI service assemblies, a Spring deployment unit, a Quartz job as a deployment unit, or a Jasper report as a deployment unit). Any of those will probably need a geronimo-XYZ.xml deployment plan, to supply a module ID and dependencies if nothing else. And currently, the deploy tool doesn't know how to crack open an arbitrary deployment unit and figure out its module ID, which is necessary to support redeployment when the plan is embedded in the archive (it has to know what existing module(s) to replace). There are two possible solutions: one is to stop using JSR-88 for deployment and just pass the archive to the server and let it do its thing; the other is to let each deployer indicate the name of its deployment plan (when the plan is packed in the module). I'd lean toward the second approach for 1.1.1, as it's a fairly trivial change. A related question is whether we should let you pack non-J2EE deployment units in an EAR. That is, if we define a JasperReports report deployment unit, should your EAR be able to contain a WAR, an EJB JAR, and 2 reports? I would think so, though we may choose to implement a wrapper that would hold the EAR and the 2 reports instead. I'm not sure how extensive a change this might require -- we seem to have some special handling for classpaths for modules within an EAR, and I don't know where that happens and what's likely to break. If we do nothing, the alternative is that you'd only be able to redeploy new types of modules if you pass either the module ID or the plan on the command line along with the archive (no packing plan in archive), and if you had a J2EE app and a handful of other modules that all work together, you would still have to deploy/redeploy them all individually. Thanks, Aaron
Re: Frustrations of a Release Manager
On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: No Bruce, thats not it at all. Its simply discussing what he was going to do. This all comes back to the lack of communication issue. So you would have preferred that he send an email to the list explaining the work he was doing on the code? Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: Anschluss - CORBA specs new home
Changing a released jar in the repository is a bad idea. There is no real down side to having some old releases with incubator in the name, and we when the project graduated we would just update the poms to their new name. Anyway, as Alan pointed out, it most likely isn't worth the effort to move the code now. -dain On Jun 8, 2006, at 11:38 PM, John Sisson wrote: Don't they have to have incubator as part of the file names and then when they exit the incubator they can remove incubator from the name. Sounds like it may create extra work changing Geronimo POMs to point to the correct files at different stages. Are the groupIDs changing too? John Dain Sundstrom wrote: Projects in the incubator can do releases. They do have a restriction until the IP is cleared, but once that is done they can release using the normal release process. -dain On Jun 5, 2006, at 6:29 PM, Matt Hogstrom wrote: I'm ok with it but would prefer to turn them over after Yoko graduates. My understanding is that an incubator project can't release anything. I expect they don't change a whole lot but that would be my only reservation. Alan D. Cabrera wrote: I think that it's time that we, Yoko, take responsibility for the CORBA spec jars. After Geronimo releases v1.1, let's plan on moving them over to Yoko. Thoughts? Regards, Alan
Database Pool Creation error
Hello all, I don't know if anyone has had any issues creating database pools with the snapshot from Wednesday. But, began testing today and I cannot create a new database pool using the wizard (mySQL connection) Log output for 'show plan' and 'deploy plan' below. If anyone has a patch that corrects this please let me know. Thanks, Jay McHugh logs follow --- When I attempt to 'show plan' prior to deploying the plan (created with the wizard) I get the following log output: 15:53:22,969 ERROR [DatabasePoolPortlet] Unable to save connection pool java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:876) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) 15:53:23,112 ERROR [DatabasePoolPortlet] Unable to render portlet java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderPlan(DatabasePoolPortlet.java:831) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:679) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at
Re: Sandbox ACL question
FWIU, having commit access to svn at apache requires you to have an apache account which means you need to be a committer on some apache project. I believe that apache only has the one process to get committ access. Sorry, -dain On Jun 9, 2006, at 11:04 AM, Donald Woods wrote: Can we modify the Sandbox ACL so people in the contributors group can have svn write authority? It seems that allowing contributors into the sandbox would be a great way for us to provide more complex patches and enhancements while proving our worth towards becoming a committer -Donald
Re: Frustrations of a Release Manager
On 6/9/06, Bruce Snyder [EMAIL PROTECTED] wrote: On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: No Bruce, thats not it at all. Its simply discussing what he was going to do. This all comes back to the lack of communication issue. So you would have preferred that he send an email to the list explaining the work he was doing on the code? But... there was no work on the code. All I did was add configs/src/plan/geronimo-plugin.xml to the 4 directory-related configs (directory, ldap-realm, ldap-demo-jetty and ldap-demo-tomcat). And then put the CAR files on the plugin site so instead of requiring someone to manually locate the various module files and deployment plans and 20 prerequisite JARs and apply them all in the correct order, you can click through the console (or deploy tool) and it does the heavy lifting for you. I guess I fixed a bug in the POM too where ldap-realm didn't depend on directory, or something like that. Thanks, Aaron
Re: [jira] Updated: (GERONIMO-2099) Source for Console Oracle XA plugin
Very cool example of what can be done with plugins :-) Can we use G2099 to start creating a new subproject space for ASL 2.0 based Samples and Plugins in SVN? Something that fits into the normal Maven model of - /geronimo /samples /trunk /modules - dir would contain sample app dirs like magicgball /plugins - dir would contain config/plugin dirs for samples and other external ASL apps like DirectoryServer and JetSpeed2 Maybe we can start by creating the structure in Sandbox and then vote to move it over when everything is building? -Donald Aaron Mulder (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2099?page=all ] Aaron Mulder updated GERONIMO-2099: --- Description: Here's the code used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/(category)/(plugin)/trunk... in SVN It's a little cheesy in that it uses a couple class files from the console, but it seems like we need to move those classes out of the console WAR in order to refer to them from a child module classpath. was:Here's the code used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/... Source for Console Oracle XA plugin --- Key: GERONIMO-2099 URL: http://issues.apache.org/jira/browse/GERONIMO-2099 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: Plugins Versions: 1.1 Reporter: Aaron Mulder Attachments: console-tranql-oracle-xa-plugin.zip Here's the code used to create the console TranQL/Oracle XA plugin. I'm not sure where it should go, perhaps we should create geronimo/plugins/(category)/(plugin)/trunk... in SVN It's a little cheesy in that it uses a couple class files from the console, but it seems like we need to move those classes out of the console WAR in order to refer to them from a child module classpath. smime.p7s Description: S/MIME Cryptographic Signature
Re: Frustrations of a Release Manager
Bruce Snyder wrote: On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: No Bruce, thats not it at all. Its simply discussing what he was going to do. This all comes back to the lack of communication issue. So you would have preferred that he send an email to the list explaining the work he was doing on the code? I think it was clear what was wanted and needed...communication. Lets go back to your statement that we can agree to disagree...we are beating a dead horse here... Bruce
Re: Plugin versioning problems
If we really need it, I think the syntax 1.1.* would be ok since it
would easily be parseable and translated to [1.1-1.2) in a formal
version syntax. For the patch, I'm thinking of something like
if (version.equals(gerVersion) ||
(gerVersion.endsWith(.*
version.startsWith(gerVersion.substring(0, gerVersion.length
() - 2))) {
match = true;
break;
}
Don't trust that code; I free styled it in this email, but you get
the idea.
I do think this is too risky for 1.1 since this code could easily
have unintended consequences.
-dain
On Jun 9, 2006, at 5:59 AM, Paul McMahan wrote:
That's a good idea and it would be pretty straightforward. But now
that Dain has brought our attention to GERONIMO-1637 I'm concerned
about deviating from the G 1.2 activities where the full syntax of
maven version ranges will be introduced. I don't know much about
maven version ranges - there may be some subset that can be
implemented during G 1.1.x that addresses our specific concerns about
forcing plugins to continually update their geronimo-plugin.xml.
Best wishes,
Paul
On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote:
Paul, what if we tweaked your proposed patch and allowed the
plugin to
provide an optional attribute of exactVersion=required, which would
control the behavior?
-Donald
Paul McMahan wrote:
I definitely agree that a full fledged solution for version
ranges is
out of scope for G 1.1.x. I was thinking that a minor change to
the
plugin installer's version checking could at least partially
address
Donald's concerns and also avoid the version mismatch problem
Dave C.
found in the candidate build. Here's a patch that makes the plugin
installer only check the digits of geronimo's version that the
plugin's xml specifies. So if the plugin specifies
geronimo-version1.1/geronimo-version then it can be
installed into
1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
Best wishes,
Paul
Index:
modules/system/src/java/org/apache/geronimo/system/plugin/
PluginInstallerGBean.java
===
---
modules/system/src/java/org/apache/geronimo/system/plugin/
PluginInstallerGBean.java
(revision
412744)
+++
modules/system/src/java/org/apache/geronimo/system/plugin/
PluginInstallerGBean.java
(working
copy)
@@ -1409,7 +1409,7 @@
if(gerVersion == null || gerVersion.equals()) {
throw new IllegalStateException(geronimo-version
should not be empty!);
}
-if(gerVersion.equals(version)) {
+if(version.startsWith(gerVersion)) {
match = true;
break;
}
On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote:
Perhaps I was unclear; I didn't mean to say this was a bad
idea, only
that our code doesn't currently support it. I expect version
ranges
are on the road map, but if you want to work on them, you're
more than
welcome to. :)
I don't think this is a G 1.1.x discussion, since AFAIK it would
require kernel changes.
Thanks,
Aaron
On 6/8/06, Paul McMahan [EMAIL PROTECTED] wrote:
On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote:
What I meant by 1.1.* was the Maven behavior of private
builds like
1.1-1 being taken as newer than 1.1. Also, being able to
use the
behavior of 1.1-starting with any alpha is less than 1.1.
Basically,
I should be able to specify 1.1 in the plugin and have it
work on
1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but
doesn't on
1.1.1,
then I'd argue that we broke something in 1.1.1, given it
should
only be
a maintenance release and app/plan breaking changes should
only go
into 1.2.
+1 This approach is similar to how eclipse plugin
versioning works.
From http://www.eclipse.org/equinox/documents/plugin-
versioning.html :
How to specify plug-in requirements
Plug-ins that require other plug-ins must qualify their
requirements
with a version range since the absence of a version range
means that
any version can satisfy the dependency. Given that all the
changes
between the version x.0.0 and the version x+1.0.0 excluded
must be
compatible (given the previous guidelines); the recommended
range
includes the minimal required version up-to but not including
the next
major release.
IMHO geronimo should adopt eclipse's strategy for plugin
versioning
where possible since the two sets of base requirements are quite
similar and eclipse is a few years ahead in this area. The
document
referenced above spells out their strategy in detail.
Best wishes,
Paul
Re: Database Pool Creation error
Thanks for testing the pre-release! This bug was identified and fixed after the Wednesday build. You can get a build incorporating the fix here: http://people.apache.org/dist/geronimo/unstable/1.1-412854 (though that's an unstable build and I understand another release candidate will be coming quite soon). Alternately, if you don't want to reinstall all of Geronimo, you can undeploy the console (if you do it from the console itself you'll get a stack trace but it will work), and then get the latest console build from the plugin repository like this: java -jar bin/deployer.jar search-plugins http://www.geronimoplugins.com/repository/geronimo-1.1 Then pick the number for Geronimo Admin Console, and it should download and install the most current console build and you can try again. Let me know if you need help with this. Thanks, Aaron On 6/9/06, Jay D. McHugh [EMAIL PROTECTED] wrote: Hello all, I don't know if anyone has had any issues creating database pools with the snapshot from Wednesday. But, began testing today and I cannot create a new database pool using the wizard (mySQL connection) Log output for 'show plan' and 'deploy plan' below. If anyone has a patch that corrects this please let me know. Thanks, Jay McHugh logs follow --- When I attempt to 'show plan' prior to deploying the plan (created with the wizard) I get the following log output: 15:53:22,969 ERROR [DatabasePoolPortlet] Unable to save connection pool java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:876) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at
Re: Plugin versioning problems
My main objection to that is then there's no way to say 1.1 only.
We would have to call 1.1 1.1.0 so that 1.1 and 1.1.* would be
different. Or, I suppose, change your patch to gerVersion.length()-1
and encourage 1.1* not 1.1.*
Thanks,
Aaron
On 6/9/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
If we really need it, I think the syntax 1.1.* would be ok since it
would easily be parseable and translated to [1.1-1.2) in a formal
version syntax. For the patch, I'm thinking of something like
if (version.equals(gerVersion) ||
(gerVersion.endsWith(.*
version.startsWith(gerVersion.substring(0, gerVersion.length
() - 2))) {
match = true;
break;
}
Don't trust that code; I free styled it in this email, but you get
the idea.
I do think this is too risky for 1.1 since this code could easily
have unintended consequences.
-dain
On Jun 9, 2006, at 5:59 AM, Paul McMahan wrote:
That's a good idea and it would be pretty straightforward. But now
that Dain has brought our attention to GERONIMO-1637 I'm concerned
about deviating from the G 1.2 activities where the full syntax of
maven version ranges will be introduced. I don't know much about
maven version ranges - there may be some subset that can be
implemented during G 1.1.x that addresses our specific concerns about
forcing plugins to continually update their geronimo-plugin.xml.
Best wishes,
Paul
On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote:
Paul, what if we tweaked your proposed patch and allowed the
plugin to
provide an optional attribute of exactVersion=required, which would
control the behavior?
-Donald
Paul McMahan wrote:
I definitely agree that a full fledged solution for version
ranges is
out of scope for G 1.1.x. I was thinking that a minor change to
the
plugin installer's version checking could at least partially
address
Donald's concerns and also avoid the version mismatch problem
Dave C.
found in the candidate build. Here's a patch that makes the plugin
installer only check the digits of geronimo's version that the
plugin's xml specifies. So if the plugin specifies
geronimo-version1.1/geronimo-version then it can be
installed into
1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
Best wishes,
Paul
Index:
modules/system/src/java/org/apache/geronimo/system/plugin/
PluginInstallerGBean.java
===
---
modules/system/src/java/org/apache/geronimo/system/plugin/
PluginInstallerGBean.java
(revision
412744)
+++
modules/system/src/java/org/apache/geronimo/system/plugin/
PluginInstallerGBean.java
(working
copy)
@@ -1409,7 +1409,7 @@
if(gerVersion == null || gerVersion.equals()) {
throw new IllegalStateException(geronimo-version
should not be empty!);
}
-if(gerVersion.equals(version)) {
+if(version.startsWith(gerVersion)) {
match = true;
break;
}
On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote:
Perhaps I was unclear; I didn't mean to say this was a bad
idea, only
that our code doesn't currently support it. I expect version
ranges
are on the road map, but if you want to work on them, you're
more than
welcome to. :)
I don't think this is a G 1.1.x discussion, since AFAIK it would
require kernel changes.
Thanks,
Aaron
On 6/8/06, Paul McMahan [EMAIL PROTECTED] wrote:
On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote:
What I meant by 1.1.* was the Maven behavior of private
builds like
1.1-1 being taken as newer than 1.1. Also, being able to
use the
behavior of 1.1-starting with any alpha is less than 1.1.
Basically,
I should be able to specify 1.1 in the plugin and have it
work on
1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but
doesn't on
1.1.1,
then I'd argue that we broke something in 1.1.1, given it
should
only be
a maintenance release and app/plan breaking changes should
only go
into 1.2.
+1 This approach is similar to how eclipse plugin
versioning works.
From http://www.eclipse.org/equinox/documents/plugin-
versioning.html :
How to specify plug-in requirements
Plug-ins that require other plug-ins must qualify their
requirements
with a version range since the absence of a version range
means that
any version can satisfy the dependency. Given that all the
changes
between the version x.0.0 and the version x+1.0.0 excluded
must be
compatible (given the previous guidelines); the recommended
range
includes the minimal required version up-to but not including
the next
major release.
IMHO geronimo should adopt eclipse's strategy for plugin
versioning
where possible since the two sets of base requirements are quite
similar and eclipse is a few years ahead in this area. The
document
referenced above spells out their strategy in
Re: 1.1 Release plan
On Jun 9, 2006, at 12:02 AM, John Sisson wrote: Matt Hogstrom wrote: Final Items for 1.1 I would like to release Geronimo 1.1 on June 12th. Yes, that is three days away. If we can't make that date then it will be 72 hours away from each candidate build. Problem that are found need to be addressed if they are deemed critical. Otherwise they will be tracked and solved in a follow on release. Unfortunately I will be off-line for the next three days. Not everybody has every weekend free, so how about another 3 days so everyone has plenty of notice and there will be less chance of complaints. The only thing that I had outstanding was changes to the scripts (GERONIMO-1638) as discussed at http://www.mail-archive.com/ dev@geronimo.apache.org/msg22807.html . Have made changes (not committed) but they need to be tested on windows, cygwin and unix, so with my time constraints it looks like this is going to be for 1.1.1 . Probably need something in the release notes saying that use of the GERONIMO_BASE environment variables probably won't work and the new org.apache.geronimo.server.dir and org.apache.geronimo.server.name system properties are subject to change as they are experimental. If they are experimental, they should start with a X character. Matt and John is that something we should change? -dain
Re: 1.1 Release plan
On Jun 9, 2006, at 12:40 PM, Aaron Mulder wrote: If I'm right about the release plan, I think we should create a SVN home for 1.1.1-SNAPSHOT now so there's a place to put non-critical patches. It will be annoying to put critical patches into 3 places, but we're hoping there aren't any of those. I just attached mine to JIRAs assigned to 1.1.1. I know it's not idea but is it better than leaving them on my laptop. -dain
Re: Plugin versioning problems
http://www.javaforge.com/ - It's another opensource based *forge hosting site, which seems to be open to anyone to use. The only reason I found it, was the Luntbuild project we use for building (http://www.javaforge.com/proj/summary.do?proj_id=70) started using it awhile back. I would rather use the more common sourceforge, even if its a little slow at times -Donald Aaron Mulder wrote: Sourceforge is kind of slow, which is my main objection. But perhaps we can use it as a start. What's Javaforge? Thanks, Aaron On 6/9/06, Donald Woods [EMAIL PROTECTED] wrote: Inline below. Aaron Mulder wrote: On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote: BTW - How can we add new Plugins to the geronimoplugins website? Are we going to setup a Geronimo subproject (like Daytrader) with the site framework checked into svn, along with any scripts needed to build the plugins? It seems convoluted to have samples and plugin builds in the main Geronimo tree, which are not shipped with the server or automatically pushed to geronimoplugins. Wouldn't it be easier to maintain if we moved all the samples out to /trunk/samples/modules and all the equivalent plugin configs to /trunk/samples/plugins? That way, the Samples and plugins can be built, published and enhanced separate from the server development Currently, to get a plugin added to the web site, you can mail it to me. If you want to help out there, it would be great to have a script that read the plugin.xml files and emitted the various PHP files with all the plugin info! Currently it's a little more manual. :) We should definitely have a separate are in the SVN tree for the samples. There's no reason they should be tied to the Geronimo release schedule. We also need a non-Apache space where we can write the plugin wrappers for various interesting LGPL projects. If you create a project on Sourceforge or Javaforge, I'll come and help. How about project=geronimoplugins to match the website name? -Donald Thanks, Aaron Aaron Mulder wrote: On 6/7/06, Donald Woods [EMAIL PROTECTED] wrote: Why shouldn't the Plugin support be as robust as module dependencies and allow the user providing the plugin to decide if they can support geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only support predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to me and doesn't follow previous email threads about not deviating from Maven2 versioning behavior... But what you've said here is why shouldn't the plugin support be as robust as A and allow B where A != B. Module dependencies let you specify an exact version or no version. Plugin dependencies also let you specify an exact version or no version. Neither of these support 1.* or 1.1*. Just as with the Tomcat JSP/Servlet Examples, you could easily provide a Plugin which should work on all 1.x releases My preference it to opt-in supported version, not opt-out unsupported versions. So I'd like the plugin developer to try a plugin on a Geronimo version and if it works, list that version as supported. The alternative will most likely lead to Geronimo being willing to install a plugin but the plugin not working. If we get fancier version dependencies we can consider things like 1.1.* but I'm not sure I like that. I'm willing to be convinced, but I'd want to hear from more plugin developers/maintainers. Thanks, Aaron smime.p7s Description: S/MIME Cryptographic Signature
Re: Frustrations of a Release Manager
Okay, after reading the e-mails thus far ( I haven't read through all of them yet ) here are my responses inline. Aaron Mulder wrote: On 6/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Aaron, Since you asked. First, Can you respond below if you will allow anyone that you have sent a private e-mail to to cut and paste the contents of those messages into other posts on this thread. I think that will help. Sure. Thanks. Second, the geronimoplugins.com which was injected into Geronimo is probably a good place to start. Here is a snip from whois of that domain. I removed the address specific information. Registrant: Address is provided *Removed* Domain Name: GERONIMOPLUGINS.COM Created on: 11-Apr-06 Expires on: 11-Apr-07 Last Updated on: 11-Apr-06 Administrative Contact: Mulder, Erin [EMAIL PROTECTED] Technical Contact: Mulder, Erin [EMAIL PROTECTED] Yes, of course, that's a domain we got, because the project needs one, and it can't be at Apache (due to the LGPL issue). I've offered a number of times to give people accounts to help manage the site, and so far, no one's taken me up on it. My goals are to provide a Maven repository (=HTTP site) that can hold *all* plugins, ASF, LGPL, GPL, proprietary. Since I didn't see one out there, Erin was gracious enoguh to provide one. And now you're jumping on her for it? That's gratitude! Also, recall that the file defining the available plugin repositories is hosted by the ASF, so the ASF can change the list of available sites away from geronimoplugins.com at any time. What is your counter-proposal? Create a zone at Apache that will service this concept. This would require talking to the infra team to do this. Perhaps this was already done and we didn't see the traffic on the dev list. If ther ewaw I apologize for the assertion. Next we can discuss the hijacking of JIRA for your own purposes. I was working to release 1.1 and you moved over 80 other JIRAs into the release. I don't think that we agreed on how to handle JIRAs but I think it was bad form to assume it was your prioritization mechanism since you were not releasing 1.1. Gosh, I didn't really think I was hijacking Jira. I thought I was using it for its intended purpose, which is to say, tracking the issues with the project, what should be worked on, and who was willing to work on what. Including, of course, a todo list for myself. I honestly had no idea that as release manager, you considered Jira to be your domain, and didn't want people using without what -- your approval? By all means, if you object to something I do like that, please say something! Aaron, I'm trying to use Jira to track the tasks for 1.1, please don't put anything in there unless it's *definitely* going to happen in the next 2 weeks or whatever. I don't remember having those discussions until well after the fact. Fair enough that you hadn't considered JIRA as a release management tool. We3 never discussed it and perhaps from my perspective it seemed obvious. Teh point is you used it for your purposes without a prior e-mail to the community about your intentions. When you did move things back in I assumed a different strategy on how to manage the release. Your intent being declared prior to moving the JIRAs would have allowed the community to interact and decided on a common course. We also discussed how to use JIRA more effectively and you post was all about what YOU wanted which may be unfair to post as you were presenting your opinion but the term I was introduced several times. I can find the post but I suspect its in most people's archives. Yes of course. I was explaining how I want to use an issue-tracking system. (Were your posts about how Jeff wants to use an issue tracking system?) I thought the point of the thread was for everyone to say what they're looking for so we can then decide the best way to do it as a group. Perhaps this was an unfair example. You used the terms I an I need so I took that to be more focused on your desires rather than community focused. If I mis-understood then I apologize. Shall we begin to discuss the meeting at Java One that you proposed that specifically excluded members of the community. I'd be happy to bring that discussion to the list if you like. Given that IBM paid for the room that the discussion occurred in we are somewhat culpable but given that you were the master mind behind the exclusionary wall I'm happy to have that discussion in the open as well. Well, actually, it was kind of a joint idea between myself and a few other people who thought there were some things we ought to talk about so long as we were all together. I'm sorry that there's a perception of an exclusionary wall. It was on us to pay for the food, which at hotel rates was $100 per person for the day, so naturally I wasn't able to invite the entire Geronimo community. I
Re: Geronimo doesn't startup if restart it using another JDK
BTW migrating to howl 1.0.1 is waiting on a maven upload request... http://jira.codehaus.org/browse/MAVENUPLOAD-930 As of a couple days ago these were stalled indefinitely. thanks david jencks On Jun 9, 2006, at 1:48 PM, Dain Sundstrom wrote: As jason pointed out using a hash code isn't portable. This is a known problem in Howl and IIRC they added an optional flag in howl to use a specified hash algorithm. Anyway, please create a JIRA (http://issues.apache.org/jira/browse/GERONIMO) for this issue. -dain On Jun 9, 2006, at 3:32 AM, Udovichenko, Nellya wrote: Hello, I have launched Geronimo on Sun JDK. Then I’ve tried to run it with Harmony class library and IBM VM j9. I’ve got the error log below. Also I’ve got the same result when launched Geronimo on Harmony and then - on Sun JDK. There is a bug in HOWL repaired in howl-1.0.1 by the new parameter (adler32Checksum) adding. At Geronimo startup it checks the log files' validity if they exist. One of verified parameters is the file content control sum. One value of this sum is read from file header and another is calculated by function java.nio.ByteBuffer.hashCode (). So if the algorithms of hash code functions of the JDKs are different Geronimo doesn’t startup. If the parameter adler32Checksum value is false the control sum is calculated by function java.nio.ByteBuffer.hashCode() otherwise it is calculated using ADLER-32 algorithm. Therefore, I think, it would be correct to add this parameter to configs/j2ee-server/src/plan/plan.xml and to gbean org.apache.geronimo.transaction.log.HOWLLog with value 'true'. Any thoughts? Thanks, Nellya Udovichenko, Intel Middleware Products Division Error log: $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.4.2_01)... Starting Geronimo Application Server v1.1-20060607 [** ] 11% 6s Starting geronimo/j2ee-server/ 1...14:23:30,3 19 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED s tate: abstractName=geronimo/j2ee-server/1.1-20060607/car? ServiceModule=geronimo /j2ee-server/1.1-20060607/ car,j2eeType=TransactionLog,name=HOWLTransactionLog org.objectweb.howl.log.InvalidLogBufferException: CHECKSUM Class: org.objectweb.howl.log.BlockLogBuffer workerID: LogFile: C:\Nellya\geronimo-1.1\var\txlog\howl_1.log HEADER HEADER_ID: 0x484f574c bsn: 0x1 size: 0x8000 should be: 0x8000 data used: 0x4f checkSum: 0x2227d tod: 0x10bb850e3b1 crlf: 0xd0a FOOTER FOOTER_ID: 0x4c574f48 bsn: 0x1 tod: 0x10bb850e3b1 crlf: 0xd0a at org.objectweb.howl.log.BlockLogBuffer.read (BlockLogBuffer.java:460) at org.objectweb.howl.log.LogFileManager.init (LogFileManager.java:821) at org.objectweb.howl.log.Logger.open(Logger.java:314) at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:893) at org.apache.geronimo.transaction.log.HOWLLog.doStart (HOWLLog.java:217) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start (GBeanInstance.j ava:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency $1.running(GBeanDepe ndency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor $RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) at
Re: Some features for 1.1.1 -- module/deployment extensions
On Jun 9, 2006, at 1:51 PM, Aaron Mulder wrote: FYI, I plan to address http://issues.apache.org/jira/browse/GERONIMO-1873 as soon as possible in 1.1.1. I'd like plugins to be able to define new deployment unit formats (e.g. JBI service assemblies, a Spring deployment unit, a Quartz job as a deployment unit, or a Jasper report as a deployment unit). Depending on what this requires in terms of changes in Geronimo it sounds like a new feature. I know we haven't discussed it at all, but I assume that dot releases don't get new features. (I'm not saying it is a feature just sounds like one to me). Any of those will probably need a geronimo-XYZ.xml deployment plan, to supply a module ID and dependencies if nothing else. And currently, the deploy tool doesn't know how to crack open an arbitrary deployment unit and figure out its module ID, which is necessary to support redeployment when the plan is embedded in the archive (it has to know what existing module(s) to replace). That sucks. Is there something else we could do to avoid needing the module id? I'm guessing not. There are two possible solutions: one is to stop using JSR-88 for deployment and just pass the archive to the server and let it do its thing; the other is to let each deployer indicate the name of its deployment plan (when the plan is packed in the module). I'd lean toward the second approach for 1.1.1, as it's a fairly trivial change. I like the first one. JSR-88 seems to have to have a myopic view of the world and I really starting to feel constrained by the spec. Do you think it will be able to support everything we want to do in the future? A related question is whether we should let you pack non-J2EE deployment units in an EAR. That is, if we define a JasperReports report deployment unit, should your EAR be able to contain a WAR, an EJB JAR, and 2 reports? I would think so, though we may choose to implement a wrapper that would hold the EAR and the 2 reports instead. I'm not sure how extensive a change this might require -- we seem to have some special handling for classpaths for modules within an EAR, and I don't know where that happens and what's likely to break. I think we should allow arbitrary nesting, and I think it will require a major change to deployment. If we do nothing, the alternative is that you'd only be able to redeploy new types of modules if you pass either the module ID or the plan on the command line along with the archive (no packing plan in archive), and if you had a J2EE app and a handful of other modules that all work together, you would still have to deploy/redeploy them all individually. I would lean towards a multiphase rollout of this feature. A small work around for 1.1.1, and depending on timing maybe split the rest across 1.2 and 1.3. That is just my $0.02. -dain
Re: Frustrations of a Release Manager
On Jun 8, 2006, at 5:44 PM, Aaron Mulder wrote: I propose for 1.2 we drive it more by time than by features. That is, we lay out a schedule including builds every 2-3 weeks, initially milestone builds, becoming beta and RC builds. We try to get people to test and provide feedback on the builds as we go, and we expect that we'll have some issues early to mid-way through the process but have clear dates for feature freeze, no bugs fixes except blockers, branch for the next release, etc. We may have to adjust the schedule depending on what develops, but at least we'll know what we're targeting at all times. Then we'll have to huddle after the 1.2 release and decide whether this was an improvement over the 1.1 process or not, and decide how to go for 1.3/2.0. Sounds good. Can you put together a time table representation of this idea? It would help me understand the nuances. Thanks, -dain
Re: Plugin versioning problems
On Jun 9, 2006, at 2:13 PM, Aaron Mulder wrote:
My main objection to that is then there's no way to say 1.1 only.
We would have to call 1.1 1.1.0 so that 1.1 and 1.1.* would be
different. Or, I suppose, change your patch to gerVersion.length()-1
and encourage 1.1* not 1.1.*
I guess my code was bad. My intention was you could call out
specific versions. Here is a table of what I wanted to happen:
Input Version Range
- -
1.1 1.1
1.1.* [1.1-1.2)
1.1.1 1.1.1
1.1.1.* [1.1.1-1.1.2)
and here is the code I posted for those that don't wan to read back
in the thread:
if (version.equals(gerVersion) ||
(gerVersion.endsWith(.*
version.startsWith(gerVersion.substring(0, gerVersion.length
() - 2))) {
With that if statement, the glob part of the match only executes if
the version ended with .* otherwise it must be an exact match.
-dain
Re: Frustrations of a Release Manager
Bruce Snyder wrote: On 6/9/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Sigh! :( Looks like all efforts are down the drain. On 6/9/06, Aaron Mulder [EMAIL PROTECTED] wrote: I don't see what's wrong with a group of folks interested in Gernoimo getting together to talk about Geronimo. So long as it's positioned as discussion not decision-making, of course -- which, as I recall, it was. Dims, statements like that don't work to bring the community together, they only cause more animosity. Let's try to move beyond the jabs and let the people with unresolved issues air their concerns so that they can work together. Yet again I'm now thoroughly confused on this whole topic. Does this mean that nobody can even talk about Geronimo unless it's on-list in some way? Does this mean if someone at a client site or a local JUG or anywhere asks me questions about Geronimo that I must either tell them to ask on the list because I'm not allowed to talk about it or post my conversation to the list after the fact? I don't think that an all list requirement is appropriate. We have to allow for people having conversations that are not privy to everyone's consumption. However, where those discussion turn into a collusion about how the project should unfold then I think it has turned to an innapropriate level. I really am seriously confused because of so many mixed messages from so many people about this topic. Please help me understand. Bruce
Re: Plugin versioning problems
Heh heh... you're right.
Thanks,
Aaron
On 6/9/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
On Jun 9, 2006, at 2:13 PM, Aaron Mulder wrote:
My main objection to that is then there's no way to say 1.1 only.
We would have to call 1.1 1.1.0 so that 1.1 and 1.1.* would be
different. Or, I suppose, change your patch to gerVersion.length()-1
and encourage 1.1* not 1.1.*
I guess my code was bad. My intention was you could call out
specific versions. Here is a table of what I wanted to happen:
Input Version Range
- -
1.1 1.1
1.1.* [1.1-1.2)
1.1.1 1.1.1
1.1.1.* [1.1.1-1.1.2)
and here is the code I posted for those that don't wan to read back
in the thread:
if (version.equals(gerVersion) ||
(gerVersion.endsWith(.*
version.startsWith(gerVersion.substring(0, gerVersion.length
() - 2))) {
With that if statement, the glob part of the match only executes if
the version ended with .* otherwise it must be an exact match.
-dain
Re: Frustrations of a Release Manager
Aaron Mulder wrote: On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: I brought this up as an issue originally as it bothered me. This has nothing to do with Erin, so let's not obfuscate the issue. The point here is there was absolutely no discussion about this, as this was clearly a fairly large decision that we, as a community, should have been involved in. Unless I missed something, I do not recall anyone talking about registering a site with Geronimo plugins before it occurred. Um... OK. I didn't think setting up a site to hold the plugins was that big a deal. If it bothered you, I'm sorry. Let's talk about it. What do you recommend? The constraints I see are that is should be able to host Apache, GPL, LGPL, and commercial code. Do you agree? Disagree? What do you recommend for a hosting site? This also bothered me as a peer, since a lot of the work I did on the Directory server integration was taken out of Geronimo, then wrapped up into a plugin and placed on this external site, without input from others, as well as those who did the hard work on integration. I find this extra-confusing. I took a piece of Geronimo which was hard-coded into the product (e.g. via our assembly system) and made it a modular part of the product (e.g. a plugin that you can install or not as you please). And you feel that as the primary author of the code, you should have been consulted? That I'm somehow using your own hard work to my advantage instead of to improve the product as a whole? I'm sorry for offending you. But I don't understand your objection. Although nothing in the Apache License prohibits you from doing this, it would have been prudent and shown respect to your peers who put together the example applications and the Directory integration, to have had some discussions about doing this and how they felt about it. Its more of a ethical and respect issue, IMHO. I think we agreed that it was a mistake to include so much (samples, LDAP, etc.) in the base Geronimo distribution. The Java 5 stack trace in Geronimo 1.0 was directly attributable to this, plus we've been working hard to slim down our distributions. I am pretty sure we agreed on that in discussions on the list, though it's been a while. But I still don't understand how changing or repackaging code is showing disrespect. We're all in this together, and it's not your code or my code, it's our code. I promise, if you make the console more modular so it runs in Little G just as well as Big G, I won't be offended, I'll buy you a beer. As for your question, my counter proposal is having significant discussion with others before taking action. Well, OK, as I said, let's have the discussion. Sorry it wasn't sooner, but better late than never, eh? Relative to the private emails, I received an email from you privately after I brought up the geronimoplugins that was very aggressive, along with verbiage that bordered on threatening language. Your private email to me started out with Watch your tone. This is the intimidation stuff that I have referred to in the past, and it concerns me quite a bit. Yeah, I admit, I was a little fired up after you posted my address to the list. :) Sorry. I attended for a total of about an hour. I am speaking from hearsay here...but was Geir's presence, or lack-there-of discussed? I was told by someone that it was actually discussed at the meeting. This in-and-of-itself is the issue. Knowing Geir was in town, and especially knowing the fact that he was responsible for obtaining a speaker pass for you at JavaOne, I am having a difficult time understanding how or why he would be excluded from the event. JavaOne is a time many of us (Geronimo) come together, and I believe we all should have the opportunity to be together, regardless of our feelings (positive or negative) about each other. For those who could not attend, a dial-in probably could have been arranged. This should have been more open, and I am myself guilty for attending this when I noticed not everyone was there. We have all earned the privilege to be on Geronimo due to our dedication, contributions, and commitments we have made to Apache and Geronimo. We all should have the opportunity to engage as well. I am sure there were a number of people at JavaOne who were not invited, Geir and others. True, it would have been smart to arrange a dial-in. Ideally, many of the non-committers would have been involved as well, as their dedication and contributions should not be overlooked either. If the outcome of this is that no one should have a meeting unless the whole community is invited, I can work with that (but I don't think that's necessarily reasonable). I talked to another committer at a different conference recently, and we brainstormed some ideas for improving the product. Was that wrong? Where's the line? Is 5 people OK but 15 isn't? I think two or 50 is fine. The issue was that some people wanted to
Re: Frustrations of a Release Manager
Would it make any difference to anyone if IBM proposed that we put http://www.ibm.com/wasce/plugins as the default option. I think there would be many eye brows raised at that one. Let's be consistent in our interpretations. Jeff Genender wrote: Bruce Snyder wrote: On 6/9/06, Jeff Genender [EMAIL PROTECTED] wrote: No Bruce, thats not it at all. Its simply discussing what he was going to do. This all comes back to the lack of communication issue. So you would have preferred that he send an email to the list explaining the work he was doing on the code? I think it was clear what was wanted and needed...communication. Lets go back to your statement that we can agree to disagree...we are beating a dead horse here... Bruce
