[jboss-as7-dev] AS7 Arquillian and OSGi

[Thomas Diesler]

Hi Andrew,

the ARQ fork (https://github.com/jbosgi/arquillian/tree/jbosgi) exists 
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.

I'm more than happy to work with you to get this silly ARQ-SP issue 
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.

cheers
-thomas

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
> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx