Thanks for this, Richard. Inline.
On 03/29/2011 03:15 AM, Thomas Diesler wrote:
the ARQ fork (https://github.com/jbosgi/arquillian/tree/jbosgi
since we looked at using ARQ for OSGi testing (Sep-2010). It was
intended to be short lived feature branch like any other. The various
pull requests to get OSGi support upstream never went through however.
This is for one reason or another that we don't need to go into.
Thanks for the history. Agreed we only need to go forward.
I'm more than happy to work with you to get this silly ARQ-SP
resolved. A good starting point would be to copy the test cases in the
osgi embedded container upstream. They should cover the complete set of
functionality that we need. Another good source of information are the
ARQ Jira issues that I created/resolved. There are also a number of
elaborate forum posts (pull requests) that I can dig up for you if needed.
In case you find a change that is not well documented and reasoned
about, please let me know - I'll explain and fix the docs.
In most cases, I'm finding the JavaDocs and test cases pretty
self-explanatory. The only problem for me is in resolving the gap
between what's currently in the OSGi ARQ branch, and what will be able
to stay there for upstream. So for the past few days I've just been
toying with moving things around. :)
My plan of attack is this, and I think it's working reasonably well:
* For now, change none of the implementation. What's in place is a
working ARQ connector/container for AS7.
* Move the bits that can't get into ARQ API upstream under the AS7 tree
* Update AS7 to bring in the latest ARQ release, refactor as necessary
* Then we can together comb through the stuff under the AS7/arquillian
subsystem to see what we want to keep, and what we wanna rework.
So not too complex yet; just keeping the stuff that was
working...working. Mostly my time's spent finding/moving files without
losing commit history, so this has been a fun Git exercise as well.
Dare I say that SVN makes moving easier? :P
On 03/26/2011 07:53 AM, Andrew Lee Rubinger wrote:
> 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
> 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.
> On 03/25/2011 01:09 AM, Andrew Lee Rubinger wrote:
>> I'm looking to upgrade ARQ in AS:
>> ...but AS is using a fork of Arquillian:
>> First, I can't find the source location for this tag. Closest I can see is:
>> ...and also there's some ARQ branch:
>> 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:
>> 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.
>> jboss-as7-dev mailing list
> jboss-as7-dev mailing list