[JBoss JIRA] Created: (ARQ-473) DeployableContainer should not be restricted to only deploy Descriptors or Archives
by Aslak Knutsen (JIRA)
DeployableContainer should not be restricted to only deploy Descriptors or Archives
-----------------------------------------------------------------------------------
Key: ARQ-473
URL: https://issues.jboss.org/browse/ARQ-473
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Base Implementation, Deployable Containers SPI
Affects Versions: 1.0.0.CR1
Reporter: Aslak Knutsen
Fix For: 1.1.0.CR1
To open up for more specialized Containers we should support some type of 'WildCard' Deploy.
Possible by having a Annotation driven DeployableContainer, e.g.
@Deploy
public SomethingExposedInContext(SomeRandomOtherType type)
This will let us e.g. deploy Files/ Images etc directly for non Java/EE type Containers.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (ARQ-417) Support maven deployments
by Adrian Cole (JIRA)
Support maven deployments
-------------------------
Key: ARQ-417
URL: https://issues.jboss.org/browse/ARQ-417
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Configuration
Reporter: Adrian Cole
Microdeployments via ShrinkWrap are a nimble deployment mechanism that allows developers to test bytecode skipping the build. Another usecase is to have ARQ in a CI loop, testing artifacts post-deploy. For this sort of scenario, it would be useful to reuse test cases from the microdeployments, but have them leveraged against code pulled from maven artifacts published in a prior step.
For example, we could have an @Maven annotation which could define the coordinates of an ear file, and place that on a test scenario that performs the war, ejb, cdi, etc tests of from the dependent modules.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (ARQ-600) Improve Tomcat codebase - Managed
by Aslak Knutsen (JIRA)
Improve Tomcat codebase - Managed
---------------------------------
Key: ARQ-600
URL: https://issues.jboss.org/browse/ARQ-600
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Tomcat Containers
Reporter: Aslak Knutsen
Assignee: Karel Piwko
Fix For: tomcat_1.0.0.Final
After the Tomcat Container code clean up, tomcat-common, it seems all the Managed Tomcat containers are identical both in impl and configuration.
We can create a similar tomcat-common-managed that will have the common parts between the different versions.
{note}
If Tomcat Managed 5.5, 6 and 7 are identical, why do we have 3 versions?
{note}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (ARQ-480) Create a Notification SPI
by Aslak Knutsen (JIRA)
Create a Notification SPI
-------------------------
Key: ARQ-480
URL: https://issues.jboss.org/browse/ARQ-480
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Base Implementation, Runtime Enricher SPI
Affects Versions: 1.0.0.Final
Reporter: Aslak Knutsen
Fix For: 1.1.0.Beta1
There should be a way for SPI impls to communicate with executor about what they have done outside of throwing exception.
e.g. TestEnrcihers
* EJBEnricher ran first and couldn't find a specific @EJB, but CDI runs after and can.
** EJBEnricher should not fail on his attempt, but should report what he tried and where he failed
** CDI Enricher should be executed regardless of EJBEnrichers outcome
** Summarize in the end to compare if we have a full Enriched Object
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Created: (ARQ-569) Archive for remote GF-3.1 should not be saved to disk prior to deployment
by Pedro Kowalski (JIRA)
Archive for remote GF-3.1 should not be saved to disk prior to deployment
-------------------------------------------------------------------------
Key: ARQ-569
URL: https://issues.jboss.org/browse/ARQ-569
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: GlassFish Containers
Affects Versions: glassfish_1.0.0.CR1
Environment: Ubuntu 11.04 x86, GlassFish Server Open Source Edition 3.1.1 (build 12)
Reporter: Pedro Kowalski
When I build the deployment archive, it is saved it /tmp/ARCHIVE_FILENAME (I'm running on GNU/Linux box) with chmod 444 (-r--r--r--). If I run the glassfish server as a root or as the same user as the maven than there is no problem. But actually I run a Jenkins build task (user: jenkins) and run the server as another user (user: pedro).
In such case, the Arquillian remote tests fail because the Glassfish cannot use the /tmp/ARCHIVE_FILENAME (permission denied). If you change the chmod and give others the write permission - it will work fine.
Aslak suggested avoiding the FileDataBodyPart during deployment.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months