1:53 a.m.
Wanted to let everyone know what I've been working on so we don't take
on any overlap.
I'm considering as a blocker to moving forward on the Integration
TestSuite stuff the issue of resolving the Arquillian OSGi fork. Until
further notice, please consider everything under jboss-as/arquillian frozen.
At first glance, it might appear that we should just merge the stuff in
the ARQ fork upstream, but we've identified a few reasons this cannot be
done:
1) Additions to the ARQ API which shouldn't be there (JMX
DeploymentManager, etc)
2) Reliance from ARQ on ShrinkWrap implementation internals
3) Merge clashes as the fork and ARQ have diverged in both API and
design over time
So what I've got in my local repos is a scenario where I've moved some
of the new OSGi/ARQ modules into the AS tree (testenricher-jmx,
testenricher-msc, etc), and am still finding the proper place for some
of the bits which hook everything together.
Thomas and David do have a series of good ideas in this code:
* Addressing OSGi concerns, but more generically speaking, getting ARQ
to be more aware of a modular ClassLoading environment
* An injectable ArchiveDeployer, such that we can programatically
trigger deployments from within a test via a simple abstraction
* Probably some more stuff I haven't yet uncovered ;)
The main take away from this mail is:
1) Continue to populate the existing integration testsuite as you'd
like. I'll clean up later.
2) Don't touch the arquillian subsystem in the AS tree for now.
3) Never, ever fork an upstream project for specialized retrofitting to AS.
4) I may be rewriting a bunch of the ARQ/AS7 connector stuff as needed.
Once this is done, I'll coordinate whatever changes we need to ARQ into
the upstream w/ the ARQ team, probably in some branch which I'll keep in
sync/rebased with master. We can do interim releases off this branch
for AS until Aslak blesses ARQ Alpha6, at which point we'll be synced up
for the future.
S,
ALR
On 03/25/2011 01:09 AM, Andrew Lee Rubinger wrote:
I'm looking to upgrade ARQ in AS:
https://issues.jboss.org/browse/JBAS-8946
...but AS is using a fork of Arquillian:
<version.org.jboss.arquillian>1.0.0.Alpha4.SP9</version.org.jboss.arquillian>
First, I can't find the source location for this tag. Closest I can see is:
https://github.com/tdiesler/arquillian/commits/1.0.0.Alpha4.SP7
...and also there's some ARQ branch:
https://github.com/arquillian/arquillian/commits/1.0.0.Alpha4-OSGi
It's possible/probable that I missed some discussion on the reasoning
behind this, but I want to put a stop to this kind of forking. Yes, I
know that AS needed a release of ARQ before ARQ was ready for alpha-5.
AS is in a position to fuel Arquillian development, and at the very
least if forks are needed in a clutch, they've got to go into the
authoritative Arquillian repository:
https://github.com/arquillian/arquillian
That said, I'm looking to resolve this and bring any changes that are
demanded by AS back in line with current ARQ upstream/master.
If you can point me at where the SP9 tag lives, I can start a discussion
w/ Aslak about what we need to do to bring these changes into
upstream/master. Perhaps some additional layering will be necessary to
tack on OSGi-specific stuff that shouldn't be in ARQ core, and we should
handle that too.
But long-term, AS is going to need a version of ARQ that's not forked
off current development so that we can do drop-in-place upgrades.
S,
ALR
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev