[jira] Resolved: (SM-1019) support ws-addressing
[
https://issues.apache.org/activemq/browse/SM-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved SM-1019.
--
Resolution: Fixed
support ws-addressing
-
Key: SM-1019
URL: https://issues.apache.org/activemq/browse/SM-1019
Project: ServiceMix
Issue Type: Sub-task
Reporter: Freeman Fang
Assignee: Freeman Fang
already support ws-addressing between cxf bc and external request, as for
things inside jbi container, should refer to how servicemix-http implement
ws-addressing, append how servicemix-http do ws-addressing from wiki
WS-Addressing
When used on a SOAP consumer endpoint, servicemix-http handles the
WS-Adressing Action and To headers.
wsa:Action
The wsa:Action header can be used to specify the target interface name and
operation to use for the JBI exchange.
The header uses the following syntax:
[target namespace][delimiter][interface name][delimiter][operation name]
where:
* [delimiter] is : when the [target namespace] is a URN, otherwise /.
* [target namespace] is the namespace of the interface.
* [interface name] is the name of the interface.
* [operation name] is the name of the operation.
For example, the following header
wsa:Actionhttp://example.com/stockquote/StockQuoteInterface/GetLastTradePrice/wsa:Action
will be used to address the JBI exchange with the following properties:
* interface name: {http://example.com/stockquote\}StockQuoteInterface
* operation name: {http://example.com/stockquote\}GetLastTradePrice
wsa:To
The wsa:To header specifies the target JBI service name and endpoint name.
The header uses the following syntax:
[target namespace][delimiter][service name][delimiter][endpoint name]
where:
* [delimiter] is : when the [target namespace] is a URN, otherwise /.
* [target namespace] is the namespace of the interface.
* [service name] is the name of the service.
* [endpoint name] is the name of the endpoint.
For example, the following header
wsa:Tourn:example:stockquote:StockQuoteService:JBIEndpoint/wsa:To
will be used to address the JBI exchange with the following properties:
* service name: {urn:example:stockquote}StockQuoteService
* endpoint name: JBIEndpoint
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-1018) support ws-security
[ https://issues.apache.org/activemq/browse/SM-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved SM-1018. -- Resolution: Fixed support ws-security --- Key: SM-1018 URL: https://issues.apache.org/activemq/browse/SM-1018 Project: ServiceMix Issue Type: Sub-task Reporter: Freeman Fang Assignee: Freeman Fang should refer to the ws-security implementation in servicemix-soap model -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-1047) rewrite wsdl-first sample with servicemix-cxf-se and servicemix-cxf-bc
rewrite wsdl-first sample with servicemix-cxf-se and servicemix-cxf-bc -- Key: SM-1047 URL: https://issues.apache.org/activemq/browse/SM-1047 Project: ServiceMix Issue Type: Sub-task Reporter: Freeman Fang Assignee: Freeman Fang -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (SM-1047) rewrite wsdl-first sample with servicemix-cxf-se and servicemix-cxf-bc
[ https://issues.apache.org/activemq/browse/SM-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SM-1047 started by Freeman Fang. rewrite wsdl-first sample with servicemix-cxf-se and servicemix-cxf-bc -- Key: SM-1047 URL: https://issues.apache.org/activemq/browse/SM-1047 Project: ServiceMix Issue Type: Sub-task Reporter: Freeman Fang Assignee: Freeman Fang -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ServiceMix graduation postponed
Just FYI, ServiceMix graduation approval by the ASF board is postponed a bit. It has simply been forgotten during the last meeting. The next meeting should be on september the 19th... -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: IRC session
(+1) sure thing, i'll join from the beach. -brian On 8/31/07, Eric Dofonsou [EMAIL PROTECTED] wrote: +4 .. - Original Message From: rs d [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Tuesday, August 28, 2007 6:53:59 PM Subject: Re: IRC session +3 ok. On 8/28/07, Kit Plummer [EMAIL PROTECTED] wrote: On 8/28/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/28/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Unfortunately I will be traveling until Friday evening. What about moving it to Monday instead at the same hour ? 3 pm GMT, 11 am EST, 8 am PST Sorry about that... +1 Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/ +2 ; } -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ -- Brian ONeill Source Equity (http://www.sourceequity.com) jBIZint (http://www.jbizint.org) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com) mobile:215.588.6024
Re: Standalone Geronimo 2.0.1 client
--- David Blevins [EMAIL PROTECTED] wrote:
On Aug 30, 2007, at 5:32 AM, Anita Kulshreshtha wrote:
I have successfully used
props.put(java.naming.provider.url, 127.0.0.1:4201)
to run stand alone remote client to access MEJB. Should we be
using
ejbd://?
We should, yes. If you don't specify a protocol, we assume ejbd.
1 The JNDI name for MEJB is
MEJBGBean/MEJB/javax.management.j2ee.Management.
Is it possible to have it as ejb/mgmt/MEJB?
We can as of the code I checked in yesterday specify a new jndi
format for an ejb-jar. So we could use ejb/mgmt/{deploymentId}
for that resulting in ejb/mgmt/MEJB. If that's what people want.
JSR77.7.1.4 states It is recommended that a default name of
ejb/mgmt/MEJB be used whenever possible. I would like us to use this.
Thanks
Anita
2. Why does MEJB not show up in the JNDIViewer in console?
That I do not know.
-David
Park yourself in front of a world of choices in alternative vehicles. Visit the
Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/
Two observations while testing out DayTrader 1.2 on Geronimo 2.0.1
All... Last night/this morning I tried out DayTrader 1.2 on Geronimo 2.0.1 to make sure everything ran fine. During the effort, I ran into two subtle issues... Anyway, just wanted to pass them along. 1) Geronimo and/or OpenJPA appears to process sun-ejb-jar.xml files. This is a file used by Sun Java App Server 9 to handle resource mappings. I originally added the Sun specific DDs to DayTrader 1.2 for comparison purposes. I had to modify the files slightly to get it to work, but it should still work for both Geronimo and SJAS9. Overall, just wanted to express my surprise that OpenJPA would process this file. Any thoughts? 2) If any type of tracing is done on the OpenJPA components, the KeySequenceBean (in EJB mode) fails to work properly because the tracing performs a toString on the KeyBlock - which in turn spins through all the keys in the block. Consequently, when we attempt to get a key from the block all of them have been used. So... make note... be careful using tracing!!! I plan to update DayTrader 1.2 with a plan file for Geronimo 2.0.1 and also make some small changes for #1 and possibly add somethign to the ReadMe for #2. Chris -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden
Re: Trouble with 2.0.1 main pom and building anything a G dependency
+1 ... Also, I think we'll be in better shape in the future but will always have this issue. Unfortunately, everyone was working at different paces to get to Java EE 5. Of course, the same problem will resurface on Java EE 6 ;-P On Aug 30, 2007, at 10:47 PM, Paul McMahan wrote: On Aug 30, 2007, at 6:05 PM, Jeff Genender wrote: D) Rename our special versions to g-axis-saaj-1.3-r562247 and house those under our own control (org.apache.geronimo...) in central on our next build (2.0.2). (The easy and quick, and very temprary fix!) This option seems most reasonable to me (least ugly :-) Best wishes, Paul
[jira] Reopened: (GERONIMO-2880) TransportDisposedIOException occurs when trying to close ActiveMQ queue
[ https://issues.apache.org/jira/browse/GERONIMO-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aman Nanner reopened GERONIMO-2880: --- This issue is now occurring in Geronimo 2.0.1 TransportDisposedIOException occurs when trying to close ActiveMQ queue --- Key: GERONIMO-2880 URL: https://issues.apache.org/jira/browse/GERONIMO-2880 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.0.x Environment: Windows XP SP2 Reporter: Aman Nanner Fix For: 2.0.x, 2.1 I have discovered some problems with queues while running unittest in our own J2EE app. After sending a message on a queue, when we try to call the close() method on the queue, we get the following exception: org.apache.activemq.transport.TransportDisposedIOException: Peer (vm://localhost#69) disposed. where the number after localhost is different every time. We do not experience this problem with topics. We are using ActiveMQ as part of an embedded configuration with Geronimo. I've done some debugging and the problem occurs at this line in the ActiveMQMessageProducer.close() method: this.session.asyncSendPacket(info.createRemoveCommand()); The queue itself is disposed properly in the dispose() method that is called in the line before, but this sending of the asynchronous packet fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2880) TransportDisposedIOException occurs when trying to close ActiveMQ queue
[ https://issues.apache.org/jira/browse/GERONIMO-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aman Nanner updated GERONIMO-2880: -- Fix Version/s: (was: 1.2) 2.1 2.0.x Priority: Critical (was: Major) Affects Version/s: (was: 1.2) 2.0.x TransportDisposedIOException occurs when trying to close ActiveMQ queue --- Key: GERONIMO-2880 URL: https://issues.apache.org/jira/browse/GERONIMO-2880 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.0.x Environment: Windows XP SP2 Reporter: Aman Nanner Priority: Critical Fix For: 2.0.x, 2.1 I have discovered some problems with queues while running unittest in our own J2EE app. After sending a message on a queue, when we try to call the close() method on the queue, we get the following exception: org.apache.activemq.transport.TransportDisposedIOException: Peer (vm://localhost#69) disposed. where the number after localhost is different every time. We do not experience this problem with topics. We are using ActiveMQ as part of an embedded configuration with Geronimo. I've done some debugging and the problem occurs at this line in the ActiveMQMessageProducer.close() method: this.session.asyncSendPacket(info.createRemoveCommand()); The queue itself is disposed properly in the dispose() method that is called in the line before, but this sending of the asynchronous packet fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2880) TransportDisposedIOException occurs when trying to close ActiveMQ queue
[
https://issues.apache.org/jira/browse/GERONIMO-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524101
]
Aman Nanner commented on GERONIMO-2880:
---
This issue is occuring when we try to close a Queue.
{panel}
10:42:34,957 ERROR [Transaction] Unexpected exception rolling back [EMAIL
PROTECTED]; continuing with rollback
javax.transaction.xa.XAException: Peer (vm://localhost#79) disposed.
at
org.apache.activemq.TransactionContext.toXAException(TransactionContext.java:619)
at
org.apache.activemq.TransactionContext.rollback(TransactionContext.java:420)
at
org.apache.activemq.ra.LocalAndXATransaction.rollback(LocalAndXATransaction.java:127)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:78)
at
org.apache.geronimo.transaction.manager.TransactionImpl.rollbackResources(TransactionImpl.java:581)
at
org.apache.geronimo.transaction.manager.TransactionImpl.rollback(TransactionImpl.java:475)
at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.rollback(TransactionManagerImpl.java:250)
at
org.apache.geronimo.transaction.manager.TransactionManagerImpl$$FastClassByCGLIB$$14ee5fe0.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.transaction.manager.XidImporter$$EnhancerByCGLIB$$abb1517c.rollback(generated)
at
org.apache.geronimo.transaction.GeronimoUserTransaction.rollback(GeronimoUserTransaction.java:74)
.
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:353)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:393)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.jms.JMSException: Peer (vm://localhost#79) disposed.
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:58)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1185)
at
org.apache.activemq.TransactionContext.rollback(TransactionContext.java:409)
... 62 more
Caused by: org.apache.activemq.transport.TransportDisposedIOException: Peer
(vm://localhost#79) disposed.
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:86)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:47)
at
org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:69)
at
org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:74)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1175)
... 63 more
{panel}
TransportDisposedIOException occurs when trying to close ActiveMQ queue
---
Key: GERONIMO-2880
URL:
Re: Plugin stuff
So I have the code compiling but now all the geronimo-plugin.xml files are in the old format... :-( I'm going to look into generating them in the car-maven-plugin along with making a car-maven-plugin configuration that includes the dependencies more directly so we don't spend hours trying to generate them from the maven dependencies. thanks david jencks suffering from feature creep... On Aug 29, 2007, at 12:26 PM, David Jencks wrote: I'm going to take a couple days to see if I can get the plugin installer in better shape. My goals are: - new schema as in GERONIMO-3330 - jaxb based - easier to use the local maven repo as a plugin repo. This might be done by having a scan repo and generate geronimo-plugins.xml from all the plugins we find function. - let plugin xml contain more global bits. Right now it can contain config.xml bits, it should be able to modify other config.xml type files (offline deployer, etc) and artifact_aliases and config-substitutions properties files. The changes to the properties files need to be live so e.g. when the plugin is started the new entries get used. thanks david jencks
[jira] Created: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
Restricted listeners property file not found error logged during Tomcat server startup Key: GERONIMO-3451 URL: https://issues.apache.org/jira/browse/GERONIMO-3451 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x Reporter: Kevan Miller Fix For: 2.0.x During Tomcat server startup, the following log error is displayed on the console: 12:57:32,559 ERROR [[/]] Restricted listeners property file not found Althgough the log message can be ignored, users assume that something is broken... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Discuss] What next?
On 8/31/07, David Jencks [EMAIL PROTECTED] wrote: Getting 2.0.1 out the door was a great step and now might be a good time to start discussing where we want geronimo to head next. Here are some ideas I've had or think are important. If I were to try to write actual sentences about all of this I'd probably never send the email so this is way too fragmentary but maybe can spark more discussion. I'm hoping everyone will chime in with their interests and viewpoints, this is just what I've been thinking about lately. ... Core Better Spring application management Investigate OSGI and figure out how it is different from what we are doing, what it can do better, and what is missing from it. Figure out an integration strategy whether it be run OSGI as an application or replace the kernel with OSGI Don't break stuff if we start using OSGI more :-) Figure out what to do with our config.ser in modules/ configurations. At least get it into real xml, maybe using something like jaxb with schema/gbean. Great list Dave! I couldn't think of any functionality you left out in the list that I could throw in. It's great you added OSGi as well. I've always been thinking of OSGi-like kernel for Geronimo (and convert Geronimo plugins to be based on the OSGi plugin concept), but to be honest I'd need a lot of support to get it done (mentor?). I'm not an OSGi expert, but it seems the issues we're having with classloading could be easily sorted out with OSGi. I wish I could afford more time and energy to the project to make an OSGi kernel done, but am now fully aware of my time incapabilities and with no other people interested in it I don't think I'll do any real developments in this area. I could be of some help, but to lead it...well...it'd be very challenging. I'd also appreciate to hear Dain's view on how OSGi could affect Geronimo as he's one of the very few who are not scared to make changes in the kernel as well as I seem to recall he's been developing xbean-osgi module. Dain? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Created: (GERONIMO-3452) Stateless Session EJBs cannot contain a remove() method
Stateless Session EJBs cannot contain a remove() method
---
Key: GERONIMO-3452
URL: https://issues.apache.org/jira/browse/GERONIMO-3452
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: OpenEJB
Affects Versions: 2.0.x
Environment: Windows XP SP2
Reporter: Aman Nanner
Fix For: 2.0.x, 2.1
We have a stateless session bean that contains a remove(...) method that
takes in a specific type of array as a parameter. It seems that the
EJBObjectProxyHandler confuses this custom business method with the Entity Bean
remove(...) method. Once the logic sees that a method called remove is
being called, it assumes that it is a special method instead of a business
method. Here is a stack trace up to the point where this piece of logic occurs:
{panel}
Thread [http-80-3] (Suspended)
StatelessEjbObjectHandler(EjbObjectProxyHandler)._invoke(Object, Class,
Method, Object[]) line: 62
StatelessEjbObjectHandler(BaseEjbProxyHandler).invoke(Object, Method,
Object[]) line: 320
Jdk13InvocationHandler.invoke(Object, Method, Object[]) line: 49
$Proxy173.remove(FcModelKey[]) line: not available
FCRemoveTest.test() line: 75
{panel}
The following code in the EjbObjectProxyHandler looks up the name of the method
from the dispatch table and sees that it is a special method name. However,
this really only applies to Entity beans and not Session Beans. Therefore,
case 4 is executed, and the StatelessEjbObjectHandler.remove(...) method is
called, which is empty and only returns null.
{code}
Integer operation = (Integer) dispatchTable.get(m.getName());
if (operation == null) {
retValue = businessMethod(interfce, m, a, p);
} else {
switch (operation.intValue()) {
case 1:
retValue = getHandle(m, a, p);
break;
case 2:
retValue = getPrimaryKey(m, a, p);
break;
case 3:
retValue = isIdentical(m, a, p);
break;
case 4:
retValue = remove(interfce, m, a, p);
break;
case 5:
retValue = getEJBHome(m, a, p);
break;
case 6:
retValue = getEJBLocalHome(m, a, p);
break;
default:
throw new RuntimeException(Inconsistent internal
state);
}
}
return retValue;
{code}
We have not run into this problem with JBoss and Weblogic. I do not believe
having a method called remove on a Stateless Session bean is in violation of
any spec, so this should work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-192) Change configuration to module.
Change configuration to module. --- Key: GERONIMODEVTOOLS-192 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-192 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Reporter: Kan Ogawa Since Geronimo server v1.1, the word configuration was replaced to the word module. See the GERONIMO-1987 issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-192) Change configuration to module.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa updated GERONIMODEVTOOLS-192: --- Attachment: GeronimoDevTools-192.patch Change configuration to module. --- Key: GERONIMODEVTOOLS-192 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-192 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Reporter: Kan Ogawa Attachments: GeronimoDevTools-192.patch Since Geronimo server v1.1, the word configuration was replaced to the word module. See the GERONIMO-1987 issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-192) Change configuration to module.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa updated GERONIMODEVTOOLS-192: --- Patch Info: [Patch Available] Change configuration to module. --- Key: GERONIMODEVTOOLS-192 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-192 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.1.0, 1.2.0 Reporter: Kan Ogawa Attachments: GeronimoDevTools-192.patch Since Geronimo server v1.1, the word configuration was replaced to the word module. See the GERONIMO-1987 issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-192) Change configuration to module.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa updated GERONIMODEVTOOLS-192: --- Affects Version/s: 1.1.0 1.2.0 Change configuration to module. --- Key: GERONIMODEVTOOLS-192 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-192 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.1.0, 1.2.0 Reporter: Kan Ogawa Attachments: GeronimoDevTools-192.patch Since Geronimo server v1.1, the word configuration was replaced to the word module. See the GERONIMO-1987 issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-192) Change configuration to module.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-192: --- Fix Version/s: 2.0.x Assignee: Tim McConnell Change configuration to module. --- Key: GERONIMODEVTOOLS-192 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-192 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.1.0, 1.2.0 Reporter: Kan Ogawa Assignee: Tim McConnell Fix For: 2.0.x Attachments: GeronimoDevTools-192.patch Since Geronimo server v1.1, the word configuration was replaced to the word module. See the GERONIMO-1987 issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Trouble with 2.0.1 main pom and building anything a G dependency
Hi Jeff, I'm getting a similar problem when building the Eclipse plugin with a clean repo, except mine is axis2-jaxws-api... 1) org.apache.axis2:axis2-jaxws-api:jar:1.3-r562247 Where is this special repository I should use so that maven can find and download this ?? Thanks Jeff Genender wrote: Hi, I was building a 3rd party application with a dependency on the Geronimo specs (jee)...and I could not get it to build because it was looking for axis-saaj-1.3-r562247 For the life of me, I thought I had that usual maven corrupt repo issues and I wiped out my local repo...a number of times. I began looking through repos and sure enough it didn't exist. Well..I decided to look in our pom and I found: axis2Version1.3-r562247/axis2Version Further discussion with others resulted in finding that we have a special repository that pulls these special versions. (Ok I forgot about that). This is going to be a problem for anyone who has a dependency on our jars (ie. wanting to use the specs jars for a web applications, etc). If I (a committer) had to go through this much trouble trying to figure out how to get that dependency...I can't imagine what the standard user will go through when writing a web or webservices application. The point I am making here is if we are going to have special versions of jars, we need to make these more readily available. Here are some options I thought of: A) Place the special jars in central so they are automatically available to others. (Easiest approach for the user - but we are going to have to convince other projects to put them out into their locations - that may prove difficult). B) Heavily, heavily document how to get around this problem by adding our repo to their pom. This should be easily Googled and placed in a FAQ, because I would hazard to guess this will be a frequent question. (probably the easiest approach for us, but this needs to be a short term solution - and its still a PITA for our users). C) Convince the other projects to get their releases in order and get good versions of their product on central. (Should do this regardless of any other option). D) Rename our special versions to g-axis-saaj-1.3-r562247 and house those under our own control (org.apache.geronimo...) in central on our next build (2.0.2). (The easy and quick, and very temprary fix!) Thoughts? Comments? Thanks, Jeff -- Thanks, Tim McConnell
[jira] Closed: (GERONIMODEVTOOLS-181) Plugin build process should use maven-ant-plugin to download required Eclipse artifacts
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-181. -- Resolution: Fixed Fix Version/s: (was: 2.1.x) 2.0 Fixed with r571684 using suggested manen-antrun-plugin in preparation for release vote Plugin build process should use maven-ant-plugin to download required Eclipse artifacts Key: GERONIMODEVTOOLS-181 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-181 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.0 The Eclipse plugin build process should use maven-ant-plugin to download the required Eclipse artifacts from the Eclipse website rather than copying the artifacts into a local maven repository on people.apache.org -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
