Re: [jbossws-dev] JBossWS testsuite reorganization
On 17/12/14 10:54, Jim Ma wrote:
On 12/16/2014 05:03 PM, Alessio Soldano wrote:
> Hi Jim,
> actually no, we can't, because when the latest moving target is used
> (wfly900 here, which comes from wfly master), the server.home prop is
> actually required, because the maven repo does not have the
> distribution artifacts.
wildfly upstream is our jbossws project consumer, and we need to first
make sure everything works, like we already did in past. I know
wildfly upstream changes very quick even in each day, deploy the
snapshot artifacts will be time consuming work for their build
machine. But jbossws requires the latest wildfly dist snapshot and
make sure jbossws can work well with wildfly integration layer. To
resolve the wildfly dist snapshot is missing, we can look at download
it directly from our hudson machine. This would be helpful for our
user to try our code, we don't require them to pull whole wildfly
upstream and build all snapshot artifacts before running.
Making the build depend
on the availability of a resource on jbossws
hudson server is definitely a bad idea, sorry. That's a single machine
which can be unpredictably down / not available.
We should not mix different goals / concerns here; if users want to try
the jbossws code and implement something new, we're fine with them
testing with any supported container. If they choose to play with the
latest moving container (which is btw the hardest approach), to me it's
perfectly reasonable to require them to pull it and build it.
As for our release criteria, btw, the testsuite is required to pass
against all supported target containers, which are all relevant.
> Generally speaking, I'm not sure we should single out a
container and
> run the integration testsuite against that; if we actually decide to
> do this, a released target would need to be used (also for future
> build reproducibility, we don't want to default testing against a
> snapshot version)
IMO, this is not a problem when both jbossws and wildfly are snapshots
and in development phrase. When we do release, we only need to release
the deploy stuff against wildfly9's future formal release or
wildfly810/wildfly800.
Anticipating a future release version is not a valid
solution (you never
know... and the build is broken till the release is actually available).
What I want to propose is to simplify our build more. wildfly900 or
wildfly810 profile is required to run test suite, and we can take one
as the default setting. My goal is to use one simple "mvn clean
install" to build jbossws-cxf, deploy to wildfly and run the tests. If
wildfly900 is not a good option here, I am not against take wildfly810
profile as the default test container. Your thoughts ?
I see your point. I can
have a look at enabling by default the most
recent released target container (wfly 810 currently).
Thanks for the feedback!
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss