November 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - aop-mc-int tests take too long

by adrian＠jboss.org

It is nice to have the different builds of the aop-mc-int tests but they take too long. Is there a way we can choose one set of the tests for the normal build with the other configurations optional? Or some way to disable all but one when doing a release? During the release process it wants to build and run the tests multiple times. Not including the normal build during manual preparation for the release: 1) Test with the release profile mvn -Prelease install 2) Dry run of the release mvn release:prepare -DdryRun=true 3) Preparation of the release mvn release:prepare With the current tests in aop-mc-int this would take hours. And you can't pass -Daop.tests.skip to these plugins. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107490#4107490 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107490

18 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: 2.0.0-beta7 release

by adrian＠jboss.org

I couldn't do the maven release because of this issue: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107488#4107488 I've tagged it in svn and released it manually in the old repository for the appserver. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107489#4107489 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107489

18 years, 4 months

1
0
0 / 0

[Design of JBoss Build System] - Can't do a release because of bogus dependency issue

by adrian＠jboss.org

I'm trying to release to 2.0.0.Beta7 of the microcontainer, but the maven release plugin is failing because it wants this release to already exist? Specifically the test artifiacts: | [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) | [INFO] ------------------------------------------------------------------------ | [ERROR] BUILD ERROR | [INFO] ------------------------------------------------------------------------ | [INFO] Failed to resolve artifact. | | Missing: | ---------- | 1) org.jboss.microcontainer:jboss-kernel:test-jar:tests:2.0.0.Beta7 | | Try downloading the file manually from the project website. | | Then, install it using the command: | mvn install:install-file -DgroupId=org.jboss.microcontainer -DartifactId=jboss-kernel \ | -Dversion=2.0.0.Beta7 -Dpackaging=test-jar -Dfile=/path/to/file | | Path to dependency: | 1) org.jboss.microcontainer:jboss-aop-mc-int:jar:2.0.0.Beta7 | 2) org.jboss.microcontainer:jboss-kernel:test-jar:tests:2.0.0.Beta7 | | ---------- | 1 required artifact is missing. | | for artifact: | org.jboss.microcontainer:jboss-aop-mc-int:jar:2.0.0.Beta7 | | from the specified remote repositories: | central (http://repo1.maven.org/maven2), | jboss-snapshots (http://snapshots.jboss.org/maven2), | repository.jboss.org (http://repository.jboss.org/maven2/), | snapshots.jboss.org (http://snapshots.jboss.org/maven2/), | jboss (http://repository.jboss.org/maven2) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107488#4107488 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107488

18 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: 2.0.0-beta7 release

by alesj

This is the change I was talking about (AbstractRealDeployer): | public final void deploy(DeploymentUnit unit) throws DeploymentException | { | internalDeploy(unit); | | if (isControllerContextNameCandidate(unit)) | { | addControllerContextName(unit); | } | } | | /** | * Should we set controller context name on unit? | * | * @param unit the dpeloyment unit | * @return true if we should use unit's name as controller context name | */ | protected boolean isControllerContextNameCandidate(DeploymentUnit unit) | { | return useUnitName && unit.isComponent(); | } | | /** | * Deploy a deployment | * | * @param unit the unit | * @throws DeploymentException for any error | */ | protected abstract void internalDeploy(DeploymentUnit unit) throws DeploymentException; | | /** | * Add controller context name. | * | * @param unit the deployment unit | */ | protected void addControllerContextName(DeploymentUnit unit) | { | unit.addControllerContextName(unit.getName()); | } | | /** | * Remove controller context name. | * | * @param unit the deployment unit | */ | protected void removeControllerContextName(DeploymentUnit unit) | { | unit.removeControllerContextName(unit.getName()); | } | | public final void undeploy(DeploymentUnit unit) | { | try | { | if (isControllerContextNameCandidate(unit)) | { | removeControllerContextName(unit); | } | } | catch (Throwable t) | { | if (log.isTraceEnabled()) | log.trace("Exception while removing unit name: " + t); | } | | internalUndeploy(unit); | } | | /** | * Undeploy an deployment | * | * @param unit the unit | */ | protected void internalUndeploy(DeploymentUnit unit) | { | // nothing | } | | /** | * Should we use unit name for controller context name. | * | * @return true if usage is allowed | */ | public boolean isUseUnitName() | { | return useUnitName; | } | | /** | * Set use unit name for controller context name. | * | * @param useUnitName flag to allow unit name usage | */ | public void setUseUnitName(boolean useUnitName) | { | this.useUnitName = useUnitName; | } | Since I want to explicitly force this name registration on the real deployers - hence making the deploy/undeploy methods final. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107422#4107422 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107422

18 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by scott.stark＠jboss.org

"vickyk" wrote : | The JCAMetaDataRepository(repository) is updated in the Parser deployer for Connector AND MCF . Actually the repository should be added in the deploy(..) of the real deployers (for Connector AND MCF). | The undeploy(....) of the real deployers should remove the entry from the repository also , this is missing right now . | | Sounds right, probably just have not sufficiently decomposed the deployer logic into the correct aspects yet. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107421#4107421 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107421

18 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: 2.0.0-beta7 release

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : "alesj" wrote : | | I also looked at the http://jira.jboss.com/jira/browse/JBMICROCONT-184, which seems to be better candidate for earlier inclusion into JBossAS. | | But would need some guidance, specially with the current metadata rewrite, and how merging is/should be handled ... | | That's to tidyup the stupid way the ejb-jar.xml and jboss.xml (and equivalents | for ears and wars) are parsed. | | 1) They're in seperate parsing deployers which isn't going to work | properly when you have predefined metadata. The hack Scott put in | will always reparse jboss.xml | | The reparse option should not be needed for any parsing deployer with the metadata rewrite because the metadata has one to one representations with the descriptors, and merged views into the jboss metadata. For cases where multiple descriptors are merged like standardjboss.xml, jboss.xml, there are wrapping proxy classes that combine the two views. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107416#4107416 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107416

18 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by vickyk

"vickyk" wrote : | PS : I understand that the RARMetaDataRepository is basically named as JCAMetaDataRepository . | http://anonsvn.jboss.org/repos/jbossas/trunk/connector/src/main/org/jboss... No there is a RARMetaDataRepository , I am wrong here so this post should be related to JCAMetaDataRepository refactoring topic . http://anonsvn.jboss.org/repos/jbossas/trunk/connector/src/main/org/jboss... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107407#4107407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107407

18 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by vickyk

While going though the simple deployment/undeployment process in the Jboss5 I observed 1) jboss.jca:name=DefaultJCAMetaDataRepository,service=JCAMetaDataRepository MBean exists and the operations like listDeploymentsForConnector() did not give the results as expected . I deployed a sample.rar and a connection factory my-ds.xml for this rar . I keyed in "sample.ear" for the listDeploymentForConnector() and found that it did not returned any values as I was expecting the info regadring the my-ds.xml . Before doing this I verified the deployment success by looking required MBean's at the jmx-console . 2) ConnectorMetaDataCount () and ManagedConnectionFactoryCount() are not reducing the count once the rar/-ds.xml file is undeployed . After looking into the code I found that JCAMetaDataRepository did not have methods defined for removal . The JCAMetaDataRepository(repository) is updated in the Parser deployer for Connector AND MCF . Actually the repository should be added in the deploy(..) of the real deployers (for Connector AND MCF). The undeploy(....) of the real deployers should remove the entry from the repository also , this is missing right now . PS : I understand that the RARMetaDataRepository is basically named as JCAMetaDataRepository . http://anonsvn.jboss.org/repos/jbossas/trunk/connector/src/main/org/jboss... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107402#4107402 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107402

18 years, 4 months

1
0
0 / 0

[Design of JBoss Build System] - Strange dependency issue

by adrian＠jboss.org

When I resynched with the microcontainer project this morning, it was giving me all lots of errors running the aop-mc-int tests. (This was on a clean build). I figured out it was building against the wrong version jboss-container (a snapshot from a couple of days ago). I decided to go through and fix the problems reported by dependecy:analyze but it is giving me a strange message related to jboss-container in aop-mc-int which is probably related to what I saw, although I can't reproduce it now. | [INFO] ---------------------------------------------------------------------------- | [INFO] Building JBoss Microcontainer AOP MC INT | [INFO] task-segment: [dependency:analyze] | [INFO] ---------------------------------------------------------------------------- | [INFO] Preparing dependency:analyze | [INFO] [resources:resources] | [INFO] Using default encoding to copy filtered resources. | [INFO] [compiler:compile] | [INFO] Nothing to compile - all classes are up to date | [INFO] [resources:testResources] | [INFO] Using default encoding to copy filtered resources. | [INFO] [compiler:testCompile] | [INFO] Nothing to compile - all classes are up to date | [INFO] [dependency:analyze] | [INFO] Used declared dependencies: | [INFO] org.jboss:jbossxb:jar:2.0.0.CR4:compile | [INFO] junit:junit:jar:3.8.1:compile | [INFO] org.jboss:jboss-test:jar:1.0.4.GA:compile | [INFO] org.jboss:javassist:jar:3.6.0.GA:compile | [INFO] apache-xerces:xml-apis:jar:2.7.1:compile | [INFO] org.jboss.microcontainer:jboss-dependency:jar:2.0.0-SNAPSHOT:compile | [INFO] org.jboss.microcontainer:jboss-kernel:jar:2.0.0-SNAPSHOT:compile | [INFO] jboss:jboss-logging-spi:jar:2.0.3.GA:compile | [INFO] org.jboss.aop:jboss-aop:jar:2.0.0.beta1:compile | [INFO] org.jboss.microcontainer:jboss-kernel:test-jar:tests:2.0.0-SNAPSHOT:test | [INFO] org.jboss:jboss-common-core:jar:2.2.1.GA:compile | [INFO] Used undeclared dependencies: | [WARNING] org.jboss.microcontainer:jboss-container:jar:2.0.0-SNAPSHOT:compile | [INFO] Unused declared dependencies: | [INFO] None | [WARNING] Potential problems discovered. | [INFO] Found Resolved Dependency / DependencyManagement mismatches: | [INFO] Ignoring Direct Dependencies. | [INFO] None | jboss-container is explicitly declared. I'd guess this has something to do with it being excluded on the aop artifact? But jboss-dependency is also excluded there and comes in via the same dependency/artifact, jboss-kernel. If I exclude it from the jboss-dependency and jboss-kernel artifacts, the spurious error goes away. e.g. see the commented out sections in the pom | <dependency> | <groupId>org.jboss.microcontainer</groupId> | <artifactId>jboss-dependency</artifactId> |  | </dependency> | <dependency> | <groupId>org.jboss.microcontainer</groupId> | <artifactId>jboss-kernel</artifactId> |  | </dependency> | But why don't I also need to exclude jboss-dependency from jboss-kernel in the same way? Or more accurately, why do I need to exclude anything since these are in the build. When do we get the ability to | <exclude-all-transitive/> | | | so we're forced to specify consistent dependencies in build/pom.xml | | instead of getting "random" dependencies from unknown places. | | | | It's a real pain going though all the poms changing, e.g. | | | | | <dependency> | | | <groupId>org.jboss</groupId> | | | <artifactId>jbossxb</artifactId> | | | <exclusions> | | | <exclusion> | | | <groupId>jboss</groupId> | | | <artifactId>jboss-common-core</artifactId> | | | </exclusion> | | | <exclusion> | | | <groupId>jboss</groupId> | | | <artifactId>jboss-common-logging-spi</artifactId> | | | </exclusion> | | | </exclusions> | | | </dependency> | | | | | | <dependency> | | | <groupId>org.jboss</groupId> | | | <artifactId>jboss-common-core</artifactId> | | | <exclusions> | | | <exclusion> | | | <groupId>jboss</groupId> | | | <artifactId>jboss-common-logging-spi</artifactId> | | | </exclusion> | | | </exclusions> | | | </dependency> | | | <dependency> | | | <groupId>org.jboss</groupId> | | | <artifactId>jboss-test</artifactId> | | | <exclusions> | | | <exclusion> | | | <groupId>jboss</groupId> | | | <artifactId>jboss-common-core</artifactId> | | | </exclusion> | | | <exclusion> | | | <groupId>jboss</groupId> | | | <artifactId>jboss-common-logging-spi</artifactId> | | | </exclusion> | | | </exclusions> | | | </dependency> | | | | | | | | | | over and over again. | | | | The exclusions (to get a consistent set of dependencies across the projects) | | are getting to be most of the poms. :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107378#4107378 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107378

18 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Clone

by msandoz

quite right Koen, i mean to copy the nodes at design time. Since this is for cut/copy/paste functionality i will need to copy the action handler and its data, as well as other node attributes. For other types I will have to copy their attributes as well. i will also need to copy included transitions - that is those whose endpoints are both within the selection set. if i decide to support it for the tree as well, i'll need to also be able to copy things like actions, tasks, etc though that is a secondary concern right now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107376#4107376 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107376

18 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2007