[Design the new POJO MicroContainer] - Re: Aliases tests
by adrian@jboss.org
The "generic" tests are in the dependency module:
1) Add an alias for a context with a "bad" ObjectName
org.jboss.test.dependency.controller.test.CrossContextDependencyBadObjectName2TestCase
2) Rewrite the "iDepend" on when it is a "bad" ObjectName
org.jboss.test.dependency.controller.test.CrossContextDependencyBadObjectNameTestCase
These should handle all the problems (and remove the need to do this in system-jmx)
but we need similar concrete tests that the "inject", "depends", etc. actually
work in the POJO metadata.
It should just be a case of "copying" all the basic dependency tests in
org.jboss.test.kernel.dependency.test.*
to make two new tests that follow the same pattern as the generic tests.
i.e.
1) good dependency name depends on bad bean name
2) bad dependency name depends on good bean name
All those tests could really do with some refactoring to make them more easily
extendable and reusable (and remove OldAbstractDependencyTest).
Besides not being easily extensible, there's also lots of repeated code
in them as well. :-(
But that is an optional part of the task. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034602#4034602
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034602
17 years, 9 months
[Design the new POJO MicroContainer] - Bean as a value to a deployment level classloader
by adrian@jboss.org
This test is failing because there is no "rewrite" of the ClassLoaderMetaData
to unwrap the embedded BeanMetaDataFactory.
| java.lang.IllegalStateException: Bean not found cl at state ControllerState@120d62b{Installed}
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.getControllerContext(MicrocontainerTestDelegate.java:152)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.getBean(MicrocontainerTestDelegate.java:125)
| at org.jboss.test.kernel.junit.MicrocontainerTest.getBean(MicrocontainerTest.java:93)
| at org.jboss.test.kernel.junit.MicrocontainerTest.getBean(MicrocontainerTest.java:80)
| at org.jboss.test.kernel.deployment.test.BeanMetaDataWithClassloaderTestCase.testBeanAsValueMetaData(BeanMetaDataWithClassloaderTestCase.java:48)
|
i.e. replace
| <classloader>
| <bean name="cl" class="org.jboss.test.kernel.deployment.support.NullClassLoader" />
| </classloader>
|
with
| <classloader>
| <inject bean="cl"/>
| </classloader>
|
| <bean name="cl" class="org.jboss.test.kernel.deployment.support.NullClassLoader" />
|
This needs to get done somewhere in AbstractKernelDeployer.deployBeans()
with deployBean() using any modified version.
We don't want to modify the ClassLoaderMetaData set on the deployment by the user!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034576#4034576
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034576
17 years, 9 months
[Design the new POJO MicroContainer] - Re: Target directory is not correct for tests in new Maven b
by adrian@jboss.org
If I understand the code to the eclipse plugin correctly, it is not possible
to have a seperate output directory for tests unless you also build eclipse
classes into the same place as the normal maven build puts things:
org.apache.maven.plugin.eclipse.EclipsePlugin.buildDirectoryList(...)
| // If using the standard output location, don't mix the test output into it.
| String testOutput = null;
| boolean useStandardOutputDir = buildOutputDirectory
| .equals( new File( project.getBuild().getOutputDirectory() ) );
| if ( useStandardOutputDir )
| {
| testOutput = IdeUtils.toRelativeAndFixSeparator( projectBaseDir, new File( project.getBuild()
| .getTestOutputDirectory() ), false );
| }
|
There's only one parameter that controls output so it is all or nothing.
We have this configured in jboss-parent
| <plugin>
| <groupId>org.apache.maven.plugins</groupId>
| <artifactId>maven-eclipse-plugin</artifactId>
| <configuration>
| <downloadSources>true</downloadSources>
| <buildOutputDirectory>target/eclipse-classes</buildOutputDirectory>
| </configuration>
| </plugin>
|
What we really want is the non-existant:
| <testOutputDirectory>target/eclipse-classes-tests</testOutputDirectory>
|
as well.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034552#4034552
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034552
17 years, 9 months
[Design of JBoss Build System] - Build Automation Stuff
by pgier
Mark Proctor requested a few features to automate more of the maven build process. This thread can be used to discuss these ideas.
Update the jboss maven2 repo - currently the maven deploy plugin handles several protocols for deployment (ftp, ssh, webdav, etc) but it doesn't include the ability to commit to cvs or svn the way that we are currently set up. So that is a manual step.
IT has set up a snapshot respository (http://snapshots.jboss.org) which can be updated via webdav. The ability to upload to this repo will be included in version 2 of the jboss-parent pom.
Copy dists to downloads.jboss.com - This can be done either with a new custom plugin, or we might be able to configure the deploy plugin as part of the release profile to upload these distributions the way we want. The deploy plugin will automatically pick up any artifacts that are attached to the build, such as custom assemblies for distribution. So we would just have to use one of the existing protocols that downloads.jboss.com has available.
Update the labs.jboss.org site - depending on what information we want on the labs, this might be a combination of the maven site plugin (which creates a default web site for a project) and our own custom plugin which creates the info that we can't get though configuring the default site plugin.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034522#4034522
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034522
17 years, 9 months