Re: Axis2 build??

2010-01-28 Thread Ruwan Linton
Andreas,

maven.test.skip property doesn't hold off for single mode tests. There are
some tests in axis2 of that sort but jaxws-integration tests are not.

Thanks,
Ruwan

On Thu, Jan 28, 2010 at 5:44 PM, Andreas Veithen
wrote:

> So this only happens with maven.test.skip=true? There is an open issue
> (AXIS2-3290) saying that maven.test.skip is not effective anyway and
> that to skip the tests, one should use test=false.
>
> Andreas
>
> On Thu, Jan 28, 2010 at 04:43, Ruwan Linton 
> wrote:
> > Hi Andreas and all,
> >
> > I sort of figured out the issue, this occurs when you skip tests using
> the
> > maven.test.skip system property. According to the maven documentation
> > maven.test.skip system property not only by passes running tests but also
> by
> > passes compiling tests as well.
> >
> > In this particular case, if the tests are not compiled, the build will be
> > failing because at the tes-compile phase, the ant-run plugin tries to
> create
> > a service archive out those compiled test classes, which is failing. Note
> > that, even though the above property by-passes compiling tests, it does
> not
> > by-pass the maven phase. (There is no way to by-pass phases in maven,
> AFAIK)
> >
> > Then I tried to put this ant task bit into a profile and tried to
> activate
> > it only when the tests are enabled, but maven doesn't seem to give me an
> > option to check whether the tests are enabled or not. Though I can track
> the
> > test disabled scenario, I cannot track the test enabled scenario.
> >
> > As the last option I tried to use the file based profile activation, to
> see
> > the compiled test classes exists or not to activate the ant task. This
> > approach also failed, since maven decides the activated profile at the
> start
> > of the execution at which point the file exists decision is wrong,
> ideally
> > if the profile activation decision should have been taken at the desired
> > phase, but I think there are technical limitations for maven to do so.
> >
> > So with the above analysis I couldn't get this solved, but fortunately
> maven
> > has an option to ask not to run the tests, but let it compile the tests,
> > using the system property called "skipTests".
> >
> > So the conclusion is use;
> >
> > mvn clean install -DskipTests
> >
> > instead of "mvn clean install -Dmaven.test.skip=true" if you want to skip
> > axis2 build tests.
> >
> > Thanks,
> > Ruwan
> >
> > On Thu, Jan 28, 2010 at 1:00 AM, Andreas Veithen <
> andreas.veit...@gmail.com>
> > wrote:
> >>
> >> For the moment I don't have any idea how to debug this. I was going to
> >> suggest setting the verbose option to true on the
> >> maven-compiler-plugin, but that doesn't seem to work.
> >>
> >> Andreas
> >>
> >> On Tue, Jan 26, 2010 at 02:40, Ruwan Linton 
> >> wrote:
> >> > Also, it is getting compiled when you run maven on the
> jaxws-integration
> >> > module, but not compiling when running on the axis2 build root :-(
> >> >
> >> > Any clue??
> >> >
> >> > Thanks,
> >> > Ruwan
> >> >
> >> > On Tue, Jan 26, 2010 at 7:38 AM, Ruwan Linton  >
> >> > wrote:
> >> >>
> >> >> Andreas,
> >> >>
> >> >> I drilled down the problem to not compiling the following test
> packages
> >> >> of
> >> >> jaxws-integration module on my machine;
> >> >>
> >> >> org.apache.axis2.jaxws.type_substitution
> >> >>
> >> >> Because of this the classes that are required for the
> >> >> AppleFinderService
> >> >> creating ant task is missing and cause the above error. I wonder
> >> >> whether the
> >> >> '_' character in the package name causes this issue.
> >> >>
> >> >> Trying to resolve the issue.
> >> >>
> >> >> Thanks,
> >> >> Ruwan
> >> >>
> >> >> On Tue, Jan 26, 2010 at 3:29 AM, Andreas Veithen
> >> >>  wrote:
> >> >>>
> >> >>> Ruwan,
> >> >>>
> >> >>> I just tested with the following combination, which is very close to
> >> >>> what you have (except for the OS):
> >> >>>
> >> >>> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> >> >>> Java version: 1.6.0_17
> >> >>> Java home:
> >> >>> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> >> >>> Default locale: en_US, platform encoding: MacRoman
> >> >>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
> >> >>>
> >> >>> Result: the build succeeds without any problems, so we still have no
> >> >>> clue what causes this issue.
> >> >>>
> >> >>> Andreas
> >> >>>
> >> >>> On Mon, Jan 25, 2010 at 17:37, Ruwan Linton  >
> >> >>> wrote:
> >> >>> >
> >> >>> >
> >> >>> > On Mon, Jan 25, 2010 at 9:03 PM, Andreas Veithen
> >> >>> > 
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> On Mon, Jan 25, 2010 at 15:30, Ruwan Linton
> >> >>> >> 
> >> >>> >> wrote:
> >> >>> >> > Andreas,
> >> >>> >> >
> >> >>> >> > I don't have maven 2.0 right now to test this, but I was having
> >> >>> >> > this
> >> >>> >> > issue
> >> >>> >> > with maven 2.1.0 and JDK 1.5 as well. Does this means that you
> >> >>> >> > are
> >> >>> >> > not
> >> >>> >> > getting this failure on maven 2.0 and JDK 1.5??
> >>

[jira] Commented: (AXIS-2316) Connection reset when called again and again

2010-01-28 Thread deepster (JIRA)

[ 
https://issues.apache.org/jira/browse/AXIS-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806161#action_12806161
 ] 

deepster commented on AXIS-2316:


How will switching to "CommonsHTTPSender" help??

> Connection reset when called again and again
> 
>
> Key: AXIS-2316
> URL: https://issues.apache.org/jira/browse/AXIS-2316
> Project: Axis
>  Issue Type: Bug
>  Components: Basic Architecture
>Affects Versions: 1.3
> Environment: WIN 2000 & SOLARIS 8
>Reporter: Heemanshu Jain
>Priority: Blocker
>
> Hi, 
> I am using Apache Axis 1.3 and JDK 1.5 to consume web services from a 
> SOAP webserver. 
> I have a loop which executes every 5 seconds and makes a call to the web 
> service. 
> The code works fine for a few requests but I get this error after some 
> requests at regular intervals. Nearly 1 failure in 50 requests. 
> I have another program written in plain java code. This program is 
> executing with no errors. This proves that there is no problem at the server 
> side. (This program has hardcoded SOAP request so cannot use this plain java 
> code for production). 
>  Is this a known bug. Is there any workaround for the same 
> AxisFault 
>  faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException 
>  faultSubcode: 
>  faultString: java.net.SocketException: Connection reset 
>  faultActor: 
>  faultNode: 
>  faultDetail: 
> {http://xml.apache.org/axis/}stackTrace:java.net.SocketException: 
> Connec 
> tion reset 
> at java.net.SocketInputStream.read(Unknown Source) 
> at java.io.BufferedInputStream.fill(Unknown Source) 
> at java.io.BufferedInputStream.read(Unknown Source) 
> at 
> org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPS 
> ender.java:583) 
> at 
> org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143) 
> at 
> org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrateg 
> y.java:32) 
> at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) 
> at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) 
> at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165) 
> at org.apache.axis.client.Call.invokeEngine(Call.java:2784) 
> at org.apache.axis.client.Call.invoke(Call.java:2767) 
> at org.apache.axis.client.Call.invoke(Call.java:2443) 
> at org.apache.axis.client.Call.invoke(Call.java:2366) 
> at org.apache.axis.client.Call.invoke(Call.java:1812) 
> at 
> com.bt.www.mta._2005._09.MTASoapPortStub.requestCheck(MTASoapPortStub 
> .java:298) 
> at com.bt.www.mta.types._2005._09.Main4test.main(Main4test.java:92) 
> {http://xml.apache.org/axis/}hostname:DSCP07364 
> java.net.SocketException: Connection reset 
> at org.apache.axis.AxisFault.makeFault(AxisFault.java:101) 
> at 
> org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:154) 
> at 
> org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrateg 
> y.java:32) 
> at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) 
> at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) 
> at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165) 
> at org.apache.axis.client.Call.invokeEngine(Call.java:2784) 
> at org.apache.axis.client.Call.invoke(Call.java:2767) 
> at org.apache.axis.client.Call.invoke(Call.java:2443) 
> at org.apache.axis.client.Call.invoke(Call.java:2366) 
> at org.apache.axis.client.Call.invoke(Call.java:1812) 
> at 
> com.bt.www.mta._2005._09.MTASoapPortStub.requestCheck(MTASoapPortStub 
> .java:298) 
> at com.bt.www.mta.types._2005._09.Main4test.main(Main4test.java:92) 
> Caused by: java.net.SocketException: Connection reset 
> at java.net.SocketInputStream.read(Unknown Source) 
> at java.io.BufferedInputStream.fill(Unknown Source) 
> at java.io.BufferedInputStream.read(Unknown Source) 
> at 
> org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPS 
> ender.java:583) 
> at 
> org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143) 
> ... 11 more 
> Please help. 
> I need to have this running asap. 
> Thanks in advance. 
> Heemanshu 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (AXIS-2498) TypeMappingImpl is not thread safe

2010-01-28 Thread eddie esquivel (JIRA)

[ 
https://issues.apache.org/jira/browse/AXIS-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806104#action_12806104
 ] 

eddie esquivel commented on AXIS-2498:
--

Hello. I can confirm that this is still an active issue. Our production 
environments (multi-cpu) are having this same issue:

(StuckThreadMaxTime) of "600" seconds. Stack trace:
java.util.HashMap.put(HashMap.java:385)
org.apache.axis.encoding.TypeMappingImpl.internalRegister(TypeMappingImpl.java:269)

org.apache.axis.encoding.TypeMappingImpl.register(TypeMappingImpl.java:221) 
   
org.apache.axis.encoding.TypeMappingDelegate.register(TypeMappingDelegate.java:73)
org.apache.axis.client.Call.registerTypeMapping(Call.java:2285)
org.apache.axis.client.Call.registerTypeMapping(Call.java:2322)

Any ideas on when this will be fixed?

Thanks


> TypeMappingImpl is not thread safe
> --
>
> Key: AXIS-2498
> URL: https://issues.apache.org/jira/browse/AXIS-2498
> Project: Axis
>  Issue Type: Bug
>  Components: Serialization/Deserialization
>Affects Versions: 1.4
>Reporter: Manuel Mall
> Attachments: AXIS-2498.patch, SynchronizedMap.java, 
> TypeMappingImpl.java
>
>
> This issue originates from 
> http://marc.theaimsgroup.com/?l=axis-user&m=114993403032512&w=2.
> Original report and Cyrille's initial response below:
> 
>Hello Manuel,
>My understanding is the Stub#createCall invokes methods on an
> instance of TypeMapping that is shared by the AxisEngine via the
> TypeMappingRegistry. Unfortunately, this TypeMappingImpl is not
> threadsafe.
>Here is a a draft patch that should fix it waiting for an official
> patch. Note that I didn't succeed in reproducing the deadlock, I
> patched according to my understanding of the problem.
>Moreover, I preferred to send you this draft/emergency patch before
> doing extensive testings. It works on my samples but I didn't look at
> the impact on performances (it should be limited ).
> HOW TO US THIS PATCH ?
>Here is a draft patch to fix this issue. To use it, the easiest way
> is to unzip axis-1.4-threadSafetyPatch.jar under /WEB-INF/classes
> (classloader order).
> PATCH DESCRIPTION
> TypeMappingImpl.java is the only modified class. Modifications:
> - use synchronized maps instead of plain HashMaps
> - synchronize internalRegister() method to ensure atomicity of access
> to maps in modification
> - synchronize access to "namespaces" variable in setSupportedEncodings
> to ensure atomicity of the clear-add sequence
>Hope this helps,
>Cyrille
> -- 
> Cyrille Le Clerc
> cyrille.lecl...@pobox.com
> cyrille.lecl...@fr.ibm.com
> +33 6.61.33.69.86
> On 6/10/06, Manuel Mall  wrote:
> > I am aware that this topic has been discussed a number of times, e.g.
> > http://marc.theaimsgroup.com/?l=axis-user&m=113771126214607&w=2.
> >
> > I followed the advice that the locator is thread safe but the stub is
> > not and as I have only stateless calls I have therefore a single
> > instance of the serviceLocator and a new instance of the stub for each
> > call.
> >
> > However, when I have many simultaneous client calls I get
> > random "lock-ups" of the system. The threads always end up stuck in the
> > same state, that is in a call to HashMap.containsKey (see below). The
> > trace snippet is taken from a 'kill -3' output. There were around 20
> > threads all with the identical trace. The only difference being the
> > address in the '- locked <...> (a ...)' line, which is to be expected
> > as I have separate instances of the stub.
> >
> > I had hoped that the fix to
> > https://issues.apache.org/jira/browse/AXIS-2284 which is in Axis 1.4
> > had addressed this issue. But even after switching to Axis 1.4 the
> > problem remains. So it seems to me that there is another concurrent
> > HashMap modification problem left in the Axis code in the area of the
> > Type Mapping Registry.
> >
> > Needless to say that the problem only occurs on a multi CPU system.
> >
> > As I am really not familiar enough with the Axis internals I am
> > wondering if anyone with more insight has a suggestion how to avoid
> > this.
> >
> > Thanks
> >
> > Manuel
> > -
> > "LandataWebPollRequestEventSlave:" prio=1 tid=0x8b48f0a0 nid=0x25cf
> > runnable [0x8ac74000..0x8ac745f0]
> > at java.util.HashMap.containsKey(HashMap.java:349)
> > at java.util.HashMap$KeySet.contains(HashMap.java:873)
> > at
> > org.apache.axis.encoding.TypeMappingImpl.isRegistered(TypeMappingImpl.java:195)
> > at
> > org.apache.axis.encoding.TypeMappingDelegate.isRegistered(TypeMappingDelegate.java:136)
> > at org.apache.axis.client.Call.registerTypeMapping(Call.java:2280)
> > at org.apache.axis.client.Call.registerTypeMapping(Call.java:2322)
> > at
> > au.com.anstat.oscar.landata.webservices.

Fwd: WSDL optional attributes

2010-01-28 Thread Luis Rivera
Hi,

This is my send try. I guess I will need to open JIRA bug for this, since
nobody seems to know what this happens!

I have a problem with the wsdl2java code generation in axis2 for optional
attributes

In short, how can I make it generate Objects instead of primitives for
OPTIONAL ATTRIBUTES?

Axis1 would generate them as Objects, which was great since I could look for
nulls as a sign that the client had not include them in the message.

However, with Axis2, the class end up with primitives, instead of objects
(e.g. int instead of Integer).

. Take the following extract from my WSDL schema:

...

 
 
 
 
 

 
 
 
 
 















...

So, how could I coerce the axis2 generator to behave like axis1 in this
particular issue?

Thanks in advance,
--Luis R.


Re: Axis213 Soap request and response logging issue

2010-01-28 Thread Andreas Veithen
http://www.catb.org/~esr/faqs/smart-questions.html

On Thu, Jan 28, 2010 at 05:31,  wrote:

>
> Anyone pease respond.
>
> Thanks & Regards,
> Arockia
>
> This email message and any attachments may contain confidential,
> proprietary or non-public information.  The information is intended solely
> for the designated recipient(s).  If an addressing or transmission error has
> misdirected this email, please notify the sender immediately and destroy
> this email.  Any review, dissemination, use or reliance upon this
> information by unintended recipients is prohibited.  Any opinions expressed
> in this email are those of the author personally.
>
>
>  From: arockia.s...@aciworldwide.com To:
> axis-dev@ws.apache.org
> Date: 01/27/2010 03:01 AM
>  Subject: Re: Axis213  Soap request and response logging issue
>
> --
>
>
>
>
> Thanks & Regards,
> Arockia
>
> This email message and any attachments may contain confidential,
> proprietary or non-public information.  The information is intended solely
> for the designated recipient(s).  If an addressing or transmission error has
> misdirected this email, please notify the sender immediately and destroy
> this email.  Any review, dissemination, use or reliance upon this
> information by unintended recipients is prohibited.  Any opinions expressed
> in this email are those of the author personally.
>
>   From: arockia.s...@aciworldwide.com  To: axis-dev@ws.apache.org  Date: 
> 01/26/2010
> 11:10 PM  Subject: Re: Axis213  Soap request and response logging issue
>
>  --
>
>
>
>
> Thanks & Regards,
> Arockia
>
> This email message and any attachments may contain confidential,
> proprietary or non-public information.  The information is intended solely
> for the designated recipient(s).  If an addressing or transmission error has
> misdirected this email, please notify the sender immediately and destroy
> this email.  Any review, dissemination, use or reliance upon this
> information by unintended recipients is prohibited.  Any opinions expressed
> in this email are those of the author personally.
>   From: arockia.s...@aciworldwide.com  To: axis-dev@ws.apache.org  Date: 
> 01/26/2010
> 10:57 PM  Subject: Re: Axis213  Soap request and response logging issue
>
>
>  --
>
>
>
>
> Thanks & Regards,
> Arockia
>
> This email message and any attachments may contain confidential,
> proprietary or non-public information.  The information is intended solely
> for the designated recipient(s).  If an addressing or transmission error has
> misdirected this email, please notify the sender immediately and destroy
> this email.  Any review, dissemination, use or reliance upon this
> information by unintended recipients is prohibited.  Any opinions expressed
> in this email are those of the author personally.  From:
> arockia.s...@aciworldwide.com  To: axis-dev@ws.apache.org  Date: 01/26/2010
> 07:36 PM  Subject: Axis213  Soap request and response logging issue
>
>
>
>  --
>
>
>
>
> Hi All,
>
> In axis213 for Soap REQUEST AND RESPONSE LOGGING I put the below entry in
> the configuration file called balilogger.lcf.
>
> # To log SOAP Messages enable this
> log4j.logger.org.apache.axis2.transport.http=DEBUG, LOGFILE
>
> # LOGFILE is set to be a File appender using a PatternLayout.
> log4j.appender.LOGFILE=bali.utils.BaliRollingFileAppender
> log4j.appender.LOGFILE.File=..//logs//${currentDate}//axismessages.log
> log4j.appender.LOGFILE.MaxFileSize=200MB
> log4j.appender.LOGFILE.MaxBackupIndex=100
> log4j.appender.LOGFILE.LogRetentionDays=7
> log4j.appender.LOGFILE.Append=true
> log4j.appender.LOGFILE.layout=org.apache.log4j.PatternLayout
> log4j.appender.LOGFILE.layout.ConversionPattern=%d{DATE};[%t];%p;%m%n
>
>
> It is not logging soap envelop and soap body. It logs some other related
> information in axismessages.log file
>
>
> But in Axis1 architecture it works fine.It is logging soap envelop and soap
> body also with other related information .
> I just put log4j.logger.org.apache.axis.transport.http=DEBUG, LOGFILE
>
> so please help me to find out the issue.
>
>
>
> Thanks & Regards,
> Arockia
>
> This email message and any attachments may contain confidential,
> proprietary or non-public information.  The information is intended solely
> for the designated recipient(s).  If an addressing or transmission error has
> misdirected this email, please notify the sender immediately and destroy
> this email.  Any review, dissemination, use or reliance upon this
> information by unintended recipients is prohibited.  Any opinions expressed
> in this email are those of the author personally.
>
>
>
>
>


[jira] Assigned: (AXIS2-4601) AddressingOutHandler performance improvements

2010-01-28 Thread Brian DePradine (JIRA)

 [ 
https://issues.apache.org/jira/browse/AXIS2-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian DePradine reassigned AXIS2-4601:
--

Assignee: Brian DePradine

> AddressingOutHandler performance improvements
> -
>
> Key: AXIS2-4601
> URL: https://issues.apache.org/jira/browse/AXIS2-4601
> Project: Axis2
>  Issue Type: Improvement
>  Components: Addressing
>Reporter: Katherine Sanders
>Assignee: Brian DePradine
> Attachments: AXIS2-4601.patch
>
>
> We should omit optional WS-A headers to avoid unnecessary axiom element 
> serialization.  Therefore we should stop sending messageID and noneURI 
> replyTo headers on response messages.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (AXIS2-4601) AddressingOutHandler performance improvements

2010-01-28 Thread Katherine Sanders (JIRA)

 [ 
https://issues.apache.org/jira/browse/AXIS2-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Katherine Sanders updated AXIS2-4601:
-

Attachment: AXIS2-4601.patch

Updated the patch to remove the messageID changes since they caused async 
failures (due to AddressingValidationHandler checking for the messageID on 
inbound messages).  I'll open a separate Jira for those changes once I've 
figured out how to make it work.

> AddressingOutHandler performance improvements
> -
>
> Key: AXIS2-4601
> URL: https://issues.apache.org/jira/browse/AXIS2-4601
> Project: Axis2
>  Issue Type: Improvement
>  Components: Addressing
>Reporter: Katherine Sanders
> Attachments: AXIS2-4601.patch
>
>
> We should omit optional WS-A headers to avoid unnecessary axiom element 
> serialization.  Therefore we should stop sending messageID and noneURI 
> replyTo headers on response messages.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (AXIS2-4601) AddressingOutHandler performance improvements

2010-01-28 Thread Katherine Sanders (JIRA)

 [ 
https://issues.apache.org/jira/browse/AXIS2-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Katherine Sanders updated AXIS2-4601:
-

Attachment: (was: AXIS2-4601.patch)

> AddressingOutHandler performance improvements
> -
>
> Key: AXIS2-4601
> URL: https://issues.apache.org/jira/browse/AXIS2-4601
> Project: Axis2
>  Issue Type: Improvement
>  Components: Addressing
>Reporter: Katherine Sanders
>
> We should omit optional WS-A headers to avoid unnecessary axiom element 
> serialization.  Therefore we should stop sending messageID and noneURI 
> replyTo headers on response messages.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: Axis2 build??

2010-01-28 Thread Andreas Veithen
So this only happens with maven.test.skip=true? There is an open issue
(AXIS2-3290) saying that maven.test.skip is not effective anyway and
that to skip the tests, one should use test=false.

Andreas

On Thu, Jan 28, 2010 at 04:43, Ruwan Linton  wrote:
> Hi Andreas and all,
>
> I sort of figured out the issue, this occurs when you skip tests using the
> maven.test.skip system property. According to the maven documentation
> maven.test.skip system property not only by passes running tests but also by
> passes compiling tests as well.
>
> In this particular case, if the tests are not compiled, the build will be
> failing because at the tes-compile phase, the ant-run plugin tries to create
> a service archive out those compiled test classes, which is failing. Note
> that, even though the above property by-passes compiling tests, it does not
> by-pass the maven phase. (There is no way to by-pass phases in maven, AFAIK)
>
> Then I tried to put this ant task bit into a profile and tried to activate
> it only when the tests are enabled, but maven doesn't seem to give me an
> option to check whether the tests are enabled or not. Though I can track the
> test disabled scenario, I cannot track the test enabled scenario.
>
> As the last option I tried to use the file based profile activation, to see
> the compiled test classes exists or not to activate the ant task. This
> approach also failed, since maven decides the activated profile at the start
> of the execution at which point the file exists decision is wrong, ideally
> if the profile activation decision should have been taken at the desired
> phase, but I think there are technical limitations for maven to do so.
>
> So with the above analysis I couldn't get this solved, but fortunately maven
> has an option to ask not to run the tests, but let it compile the tests,
> using the system property called "skipTests".
>
> So the conclusion is use;
>
> mvn clean install -DskipTests
>
> instead of "mvn clean install -Dmaven.test.skip=true" if you want to skip
> axis2 build tests.
>
> Thanks,
> Ruwan
>
> On Thu, Jan 28, 2010 at 1:00 AM, Andreas Veithen 
> wrote:
>>
>> For the moment I don't have any idea how to debug this. I was going to
>> suggest setting the verbose option to true on the
>> maven-compiler-plugin, but that doesn't seem to work.
>>
>> Andreas
>>
>> On Tue, Jan 26, 2010 at 02:40, Ruwan Linton 
>> wrote:
>> > Also, it is getting compiled when you run maven on the jaxws-integration
>> > module, but not compiling when running on the axis2 build root :-(
>> >
>> > Any clue??
>> >
>> > Thanks,
>> > Ruwan
>> >
>> > On Tue, Jan 26, 2010 at 7:38 AM, Ruwan Linton 
>> > wrote:
>> >>
>> >> Andreas,
>> >>
>> >> I drilled down the problem to not compiling the following test packages
>> >> of
>> >> jaxws-integration module on my machine;
>> >>
>> >> org.apache.axis2.jaxws.type_substitution
>> >>
>> >> Because of this the classes that are required for the
>> >> AppleFinderService
>> >> creating ant task is missing and cause the above error. I wonder
>> >> whether the
>> >> '_' character in the package name causes this issue.
>> >>
>> >> Trying to resolve the issue.
>> >>
>> >> Thanks,
>> >> Ruwan
>> >>
>> >> On Tue, Jan 26, 2010 at 3:29 AM, Andreas Veithen
>> >>  wrote:
>> >>>
>> >>> Ruwan,
>> >>>
>> >>> I just tested with the following combination, which is very close to
>> >>> what you have (except for the OS):
>> >>>
>> >>> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
>> >>> Java version: 1.6.0_17
>> >>> Java home:
>> >>> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
>> >>> Default locale: en_US, platform encoding: MacRoman
>> >>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>> >>>
>> >>> Result: the build succeeds without any problems, so we still have no
>> >>> clue what causes this issue.
>> >>>
>> >>> Andreas
>> >>>
>> >>> On Mon, Jan 25, 2010 at 17:37, Ruwan Linton 
>> >>> wrote:
>> >>> >
>> >>> >
>> >>> > On Mon, Jan 25, 2010 at 9:03 PM, Andreas Veithen
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >> On Mon, Jan 25, 2010 at 15:30, Ruwan Linton
>> >>> >> 
>> >>> >> wrote:
>> >>> >> > Andreas,
>> >>> >> >
>> >>> >> > I don't have maven 2.0 right now to test this, but I was having
>> >>> >> > this
>> >>> >> > issue
>> >>> >> > with maven 2.1.0 and JDK 1.5 as well. Does this means that you
>> >>> >> > are
>> >>> >> > not
>> >>> >> > getting this failure on maven 2.0 and JDK 1.5??
>> >>> >>
>> >>> >> I've never seen the AppleFinderService failure myself, and I use
>> >>> >> Maven
>> >>> >> 2.0 with JDK 1.5. Searching the mailing list archives for
>> >>> >> "AppleFinderService" indicates that the issue only occurs in
>> >>> >> particular build environments, since for most people the build just
>> >>> >> runs fine.
>> >>> >>
>> >>> >> > Anyway if this is failing on at least one environment we should
>> >>> >> > get
>> >>> >> > that
>> >>> >> > fixed.
>> >>> >>
>> >>> >> +1, but to be able to fix it, we first need to re

[jira] Commented: (AXIS2-3290) surefire is still run even if maven.test.skip is true

2010-01-28 Thread Andreas Veithen (JIRA)

[ 
https://issues.apache.org/jira/browse/AXIS2-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805883#action_12805883
 ] 

Andreas Veithen commented on AXIS2-3290:


The reason for the particular approach used by the Axis2 build is probably 
related to [1].

[1] http://markmail.org/message/2l7gfuj7ef6lgdbo

> surefire is still run even if maven.test.skip is true
> -
>
> Key: AXIS2-3290
> URL: https://issues.apache.org/jira/browse/AXIS2-3290
> Project: Axis2
>  Issue Type: Bug
>  Components: samples, build,site
>Affects Versions: 1.3
> Environment: WinXP. Maven 2.0.4
>Reporter: Kent Tong
>Priority: Minor
>
> "mvn install -Dmaven.test.skip=true" still runs surefire and all the tests. 
> The relevant output is:
> jar:
> [INFO] Executed tasks
> [INFO] [compiler:testCompile]
> [INFO] Not compiling test sources
> [INFO] [antrun:run {execution: test-compile}]
> [INFO] Executing tasks
> testsetup:
> [INFO] Executed tasks
> [INFO] [surefire:test]
> [INFO] Setting reports dir: 
> C:\axis2-1.3\modules\kernel\target/surefire-reports
> ---
>  T E S T S
> ---
> log4j:WARN No appenders could be found for logger 
> (org.apache.axis2.engine.Phase).
> log4j:WARN Please initialize the log4j system properly.
> [surefire] Running org.apache.axis2.addressing.AddressingHelperTest
> [surefire] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.016 sec

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.