And just as an aside, we are not supposed to be using SPn as a qualifier for any releases as well. ----- Original Message ----- > From: "Andrew Lee Rubinger&quot;&lt;andrew.rubinger(a)redhat.com&gt; > To: jboss-as7-dev(a)lists.jboss.org > Sent: Thursday, March 24, 2011 11:09:18 PM > Subject: [jboss-as7-dev] AS7 Arquillian and OSGi > 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 _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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

Oops, I hadn't read this and committed https://github.com/bstansberry/jboss-as/commit/5431043cc0a7d9f1e6b18bdd6a... I can revert that and put in a different fix if need be. On 3/25/11 12: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

3) Never, ever fork an upstream project for specialized retrofitting to AS.

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