JIRA updated

[pmuir]

All,

Aslak and I have been through the meetings and the forums and made sure we have JIRA issues for all ideas discussed. I've also been through and reviewed the components, and bucketed the issues into releases. I've kept the releases pretty fine grained (past alpha2), and tried to give them meaningful descriptions. We can change the order of releases, or the purpose, or the granularity :-)

https://jira.jboss.org/jira/secure/BrowseProject.jspa?id=12310885&subset=-1

Comments?

With this in mind, lets try to set a date to get alpha1 out!

[dan.j.allen]

Excellent. I'm excited to get to alpha1, so I say let's move forward.

The only change that I would suggest before alpha1 is to rename the container artifactIds as follows, just so that they are right to start with:

• arquillian-jbossas-remote-60
• arquillian-jbossas-remote-51
• arquillian-jbossas-embedded-60
• arquillian-glassfish-embedded-v3

Or should the prefix be "container-"?

Also, shouldn't the groupId be org.jboss.arquillian.container rather than just org.jboss.arquillian? My concern is that container is not represented in either the groupId or the artifactId, so it is sort of ambiguous.

[aslak]

we should do this before alpha-1, just so we don't start alpha-2 with a big refactoring.

I suggest:

groupid: org.jboss.arquillian.container

artifactid: jbossas-remote-60, jbossas-remote-51, jbossas-embedded-60, glassfish-embedded-v3

And we move the container-* folders down a level to contianer/jboss-as...

I can get on this tomorrow morning if accepted .. ?

[dan.j.allen]

+1

Except that I think we should go ahead and keep the "arquillian-" prefix on the artifactId because, remember, that becomes the name of the JAR file and it is customary to qualify the JAR w/ the project name...at least that's what I'm seeing when I look at other JBoss projects.

So:

groupId: org.jboss.arquillian.container

artifactId: arquillian-jbossas-remote-60, arquillian-jbossas-remote-51, arquillian-jbossas-embedded-60, arquillian-glassfish-embedded-v3

[aslak]

excellent point!

https://jira.jboss.org/jira/browse/ARQ-78

One little problem tho, all the articles use the old names.

Using Arquillian to test a possible bug in Weld - http://community.jboss.org/message/527086

Testing a JMX Portable Extension for CDI - http://community.jboss.org/message/529016

Seam 3 JMS Module Testing with Arquillian - http://community.jboss.org/wiki/Seam3JMSModuleTestingwithArquillian

With admin rights I guess we can just edit them ?

[aslak]

Project structure reorg:

Type	Directory	GroupId	ArtifactId
api/spi/impl	./	org.jboss.arquillian	arquillian-*
packager	./packagers	org.jboss.arquillian.packager	arquillian-packager-*
container	./containers	org.jboss.arquillian.container	arquillian-container-*
testenricher	./testenrichers	org.jboss.arquillian.testenricher	arquillian-testenricher-*
protocol	./protocols	org.jboss.arquillian.protocol	arquillian-protocol-*

https://jira.jboss.org/jira/browse/ARQ-81

https://jira.jboss.org/jira/browse/ARQ-80

https://jira.jboss.org/jira/browse/ARQ-79

https://jira.jboss.org/jira/browse/ARQ-78

[dan.j.allen]

Nice work.

I've got a few nit pick items. Perhaps you just haven't gotten to the last two yet.

1. I would recommend renaming packagers/java-ee to packagers/javaee since that's how Snoracle abbreviates it (see http://java.sun.com/javaee/)
2. The JBoss AS containers should be prefixed jbossas (to be consistent w/ http://jboss.org/jbossas)
3. GlassFish still needs the v3 qualifier

This is a nice step forwards towards looking sharp!

[aslak]

Thank you.. we should probably do the same for openejb and weld containers?

https://jira.jboss.org/jira/browse/ARQ-82

https://jira.jboss.org/jira/browse/ARQ-83

https://jira.jboss.org/jira/browse/ARQ-84

[dan.j.allen]

I would say yes for openejb. I'm not sure about weld, though. Maybe Pete can chime in.

The motivation for adding the major version number is that different major versions of application servers tend to have completely different deployment APIs. There is no real standard there. What works for JBoss AS 6 may not work for JBoss AS 7. (Btw, I'm not sure we need 51 and 60, rather just 5 and 6). Again, I'd like to hear what Pete has to say. The idea is to minimize the artifacts, but w/o causing conflicts.

With weld, we are trying to standardize the bootstrap API, so it is much less likely to change (meaning we wouldn't need two separate implementations).

[pmuir]

Sorry, to respond so late.

Unfortunately JBoss AS has a habit of changing it's deployment API between every release, minor major, so I guess we need to do both 51 and 60.

With Weld, Aslak, what deployment/bootstrap API are you using?

[aslak]

{code:java}
      WeldBootstrap bootstrap = new WeldBootstrap();
      bootstrap.startContainer(Environments.SE, deployment, new ConcurrentHashMapBeanStore())
                  .startInitialization()
                  .deployBeans()
                  .validateBeans()
                  .endInitialization();
 
      WeldManager manager = bootstrap.getManager(beanArchive);
{code}

http://anonsvn.jboss.org/repos/common/arquillian/trunk/containers/weld-embedded/src/main/java/org/jboss/arquillian/weld/WeldSEContainer.java

[dan.j.allen]

Hmm, that could be simplified if Weld#initialize() were overloaded to accept a deployment and WeldContainer#getBeanManager() returned a WeldManager. With these changes in place, the bootstrap code would be simplified to:

WeldContainer weld = new Weld().initialize(deployment);
WeldManager manager = weld.getBeanManager();
...
weld.shutdown();

Should we create an issue for this change in both Weld SE and Arquillian?

[aslak]

Yea i noticed the same when I creating the Weld Container. I made the patch already, but never spoke to Peter Royle about it.

{code:java}
Index: src/main/java/org/jboss/weld/environment/se/Weld.java
===================================================================
--- src/main/java/org/jboss/weld/environment/se/Weld.java     (revision 6123)
+++ src/main/java/org/jboss/weld/environment/se/Weld.java     (working copy)
@@ -20,6 +20,7 @@
 import org.jboss.weld.bootstrap.api.Bootstrap;
 import org.jboss.weld.bootstrap.api.Environments;
 import org.jboss.weld.bootstrap.spi.BeanDeploymentArchive;
+import org.jboss.weld.bootstrap.spi.Deployment;
 import org.jboss.weld.context.api.BeanStore;
 import org.jboss.weld.context.api.helpers.ConcurrentHashMapBeanStore;
 import org.jboss.weld.environment.se.beans.InstanceManager;
@@ -68,12 +69,20 @@
    @PostConstruct
    public WeldContainer initialize()
    {
+      return initialize(
+            new SEWeldDeployment() { }
+      );
+   }
 
-      SEWeldDeployment deployment = new SEWeldDeployment()
-      {
-      };
+   /**
+    * Boots Weld and creates and returns a WeldContainer instance, through which
+    * beans and events can be accesed.
+    */
+   @PostConstruct
+   public WeldContainer initialize(Deployment deployment)
+   {
       bootstrap.startContainer(Environments.SE, deployment, this.applicationBeanStore);
-      final BeanDeploymentArchive mainBeanDepArch = deployment.getBeanDeploymentArchives().get(0);
+      final BeanDeploymentArchive mainBeanDepArch = deployment.getBeanDeploymentArchives().iterator().next();
       this.manager = bootstrap.getManager(mainBeanDepArch);
       bootstrap.startInitialization();
       bootstrap.deployBeans();
@@ -84,7 +93,6 @@
       InstanceManager instanceManager = WeldManagerUtils.getInstanceByType(manager, InstanceManager.class);
 
       return new WeldContainer(instanceManager, manager);
-
    }
 
    /**

{code}

I think the issue that I had with it was that the API didn't really match.

Deployment != BeanManager

It would be a odd limitation in the Weld SE API to only support the first BeanDeploymentArchive

{code:java}
      final BeanDeploymentArchive mainBeanDepArch = deployment.getBeanDeploymentArchives().get(0);
{code}

So I ended up copying how Weld SE did it instead..

[pmuir]

I don't think this is a suitable change to Weld SE - a standard Java SE container has no notion of non-homogenous deployments that I know of, so specifying the deployment structure is uncessary. I also don't think leaking WeldManager onto the Weld SE SPI is a good idea - this is part of the Weld SPI (for container integration) and so shouldn't be used by most containers

The current approach is definitely the one we intended you to take!

[pmuir]

Talking to Aslak on IRC, we reached the following conclusions:

• Current support should be rebadged Weld SE container
• Should add support for a Weld "EE mocks" container that mocks out the EE SPI (like the current TestContainer)
• TestContainer and mocks should be moved into this module when the Weld core tests + TCK is converted to Arqullian (from weld-core-tests)