[QA of JBoss Portal] - Re: Problems with maven
by bdaw
Second problem is much more weird and refers to maven plugin development.
As was described in previous post I use cargo to deploy OpenDS LDAP server before identity tests are run. The tests are not run using surefire plugin but with our own jboss unit maven plugin. The plugin uses ant Java class (that handles 'java' task in ant) to invoke the tests. It gets proper classpath from MavenProject object using methods like:
| mavenProject.getCompileArtifacts()
| mavenProject.getTestArtifacts()
| mavenProject.getRuntimeArtifacts()
| mavenProject.getSystemArtifacts()
| mavenProject.getDependencyArtifacts()
| mavenProject.getTestResources()
| mavenProject.getTestClasspathElements()
|
Normally it works perfectly. I started having problems when I decided to cleanup module dependencies and marked some of them with
<scope>test</scope>
This is important as when the identity module will be used in other project all such "not needed for compilation" libraries will also be downloaded and used in classpath. So with test scope the code above still returns proper classpath. This happens UNTIL I use cargo maven plugin.... So with cargo most off those dependencies are not present in my plugin classpath. If I don't use test scope for dependencies everything is fine.
Any idea? Before I start to debug maven.... ;)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104970#4104970
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104970
18 years, 4 months
[Design of EJB 3.0] - EJBTHREE-1114 - Cache passivation test and generics again
by adrian＠jboss.org
There were a number of problems in this area.
1) The changes for the Pool/Cache registry broke the test
2) There was no transaction manager available
3) The use of generics in the new Pool/Cache registry was/is wrong/stupid
1) I modified the MockDeployment so the test can actually run.
This looks like a stupid api to me. There should be an EJB3Subsystem class
that selfs bootstraps and is configurable and delegated to by the EJB3Deployer.
Core EJB3 apis shouldn't be directly dependent on the deployment api, it should
be the other way around.
2) I hacked this to use the DummyTransactionManager provided by JBoss Cache
I also had to add jboss clustering into the test classpath.
This obviously needs fixing. We should be providing mock test objects
like the DummyTransactionManager in a shared project.
3) This is confused use of generics again.
There is no need for this to be generic.
| public interface Ejb3CacheFactory<T extends StatefulCache>
| {
| T createCache();
| }
|
| public class NoPassivationCacheFactory implements Ejb3CacheFactory<StatefulCache>
| {
| public StatefulCache createCache()
| {
| return new NoPassivationCache();
| }
| }
|
I could understand it if subclasses actually took advantage
of the generic parameter (even though it is unlikely to be used).
| public class NoPassivationCacheFactory implements Ejb3CacheFactory<NoPassivationCache>
| {
| public NoPassivationCache createCache()
| {
| return new NoPassivationCache();
| }
| }
|
It unnecessary anyway. It works without generics because of Covariant return types
| public interface Ejb3CacheFactory
| {
| StatefulCache createCache();
| }
|
| public class NoPassivationCacheFactory implements Ejb3CacheFactory
| {
| public NoPassivationCache createCache()
| {
| return new NoPassivationCache();
| }
| }
|
The same goes for the registry. The part that should have been
using generics wasn't defined properly. The collections.
Meaning it was unusable without casting (removal of casting is the whole
point of generics :-)
Anyway, I didn't fix this properly in case the interfaces are intended
to be extended where generics would make sense.
Instead there are some horrible constructions that are pointless
and pretty much unreadable. :-)
If there is no real use for the generics, then the whole thing can be simplified to
make this work:
| - HashMap<String, Class<? extends PoolFactory<? extends Pool>>> poolFactories = new HashMap<String, Class<? extends PoolFactory<? extends Pool>>>();
| + HashMap<String, Class<? extends PoolFactory>> poolFactories = new HashMap<String, Class<? extends PoolFactory>>();
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104967#4104967
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104967
18 years, 4 months
[QA of JBoss Portal] - Problems with maven
by bdaw
I have few problem with maven in test and identity modules.
The first one is that Identity module requires JBoss AS to run the tests (integration-test phase). So the situation is that I run AS with cargo in pre-integration-test phase and deploy OpenDS LDAP server. To do this I need to refer to its installation directory. At the moment I use ${env.JBOSS_HOME} but this requires JBOSS_HOME env to be set before doing 'mvn install'. Possible solutions and limitations:
1) Current {enb.JBOSS_HOME} solution - problems are:
- if the JBOSS_HOME env is not set the build will fail with some mess like '${JBOSS_HOME}' directory created somewhere... How could I check if the property is present and break the maven build with some nice help message? It should be possible to handle in it hudson with -DJBOSS_HOME=/... argument but I'm not sure how to prepare AS instance somewhere as hudson doesn't support shell script executions before maven goal invokation AFAIK.
2) Use cargo ZIP installer - this will download JBoss AS zip distribution and unzip it locally. No presets are required to run the build but quite big zip file will be downloaded on the first run and installed somewhere in the home dir...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104958#4104958
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104958
18 years, 4 months