Re: [jbossws-dev] JBossWS testsuite reorganization
On 12/17/2014 06:17 PM, Alessio Soldano wrote:
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.
But it's better than nothing.
Besides that, we can always print a
message and ask user to built it by himself if it's not available. At
the moment , if we choose wildfly900 snapshot container, we have to
build wildfly first, then we can start our jbossws test suite first.When
we locally run the test suite, I need to either manually download a
wildfly9 snapshot or update wildfly upsream and build it by myself, I'd
expect this can be automatically handled in our build process.
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.
If there is wildfly900 snapshot is deployed, it is not that complex to
run with wildfly900.
As for our release criteria, btw, the testsuite is required to pass
against all supported target containers, which are all relevant.
I agree with this
and no doubt. Choose profile to default not means, we
don't need to make sure others are not supported.
>> 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).
At the moment , wildfly900 build can be make sure not broken. Each PR
will be checked before merge.
>
> 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