[jbossws-dev] [Design of JBoss Web Services] - Re: JBossWS Test Approach

alessio.soldano@jboss.com do-not-reply at jboss.com
Mon Mar 9 06:30:07 EDT 2009


"richard.opalka at jboss.com" wrote : "alessio.soldano at jboss.com" wrote : what would you suggest instead of that? I don't like that much the idea of specifying the surefire additionalClasspath  with a list of jar from the curent AS... any other idea? 
  | I'm thinking exactly about that ;) But I have to googlize this problem much more. I don't believe we're the first one facing this problem.
  | 
OK, let's see if there's a better solution :-)

anonymous wrote : "alessio.soldano at jboss.com" wrote : 
  |   | After all, we also get advantages from using maven dependencies to build test classpath, otherwise we need keep track of jar changes (names, position), addition of jars (while we simply get the new dependency for free when somebody updates the dependency in an artifact we include), etc.
  | Wrong point of view. I'd maintain all this staff like we did it before JBossWS mavenization and like we do it now (see our binary distribution) and be sure we're using proper jars directly from AS than using current approach which is broken.
  | 
  | Current approach doesn't save anything. It just makes me sleep really very bad :(
  | I have a nightmare regularly at nights where I'm debugging for hours/days something and finally solving the problem with conclusion we're using wrong client classpath and hotfixing it with one maven dependencies exclusion in our testsuite pom.xml
  | 

Don't get me wrong, I'm not saying there's not a problem and we have an easy life with this way of working ;-) Just trying to evaluate the situation, let's think about alternatives (at least given the current state of the AS).

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216146#4216146

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216146



More information about the jbossws-dev mailing list