February 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Build System] - Re: JBossAS CR1 build plan

by pgier

"scott.stark(a)jboss.org" wrote : | 2. Getting the jbossas build to use maven artifacts. Nothing currently validates the jbossas maven artifacts. The first step in doing this is to replace the legacy jbossbuild repo with the maven repo as the source for the thirdparty contents. How we do this using ivy, maven ant tasks, etc. needs to be defined and documented, and the existing build-thirdparty target replaced. | | The next step would be to replace the existing project dependencies (classpaths defined in tools/etc/buildmagic/modules.ent) with the same type of maven repo references as was done for thirdparty. | | At that point the build and testsuite would be based on the exportable artifacts. | Yes, this is basically my current goal with the mavenization, but I probably should have done a better job of communicating this. I just wanted to point out that ivy or maven ant tasks would be needed only for the testsuite. My plan is to create a new testsuite which is basically a copy of the current one except that the classpath points to the maven generated jars instead of the ant ones. We wouldn't need to modify the existing ant build because once the testsuite works for the maven build, we won't need the existing build anymore. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127987#4127987 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127987

18 years, 2 months

1
0
0 / 0

[Design of JBoss Build System] - Re: JBossAS CR1 build plan

by pgier

"scott.stark(a)jboss.org" wrote : | 1. What are the jbossas artifacts and how are they being uploaded to a maven repo as part of the build. One simple issue I already see is that the names of the artifacts are changed in the existing pom.xml files. For example in the system project, while the current build produces jboss-system-client.jar and jboss-system.jar artifacts, the system/pom.xml defines jboss-as-system.jar. | | We need to get to consistent artifact names in both builds as it affects classpaths and configuration files, docs. | | I spent some time the last couple weeks trying to reproduce the various module artifacts from the ant build using the maven assembly plugin. I can reproduce the jars but it might be better to use different names than we currently use. The assembly plugin can create jars with the same names locally (what I tried doing at first), but when the deploy plugin deploys stuff to the maven repository it changes the names to fit the maven standard. I believe the reasoning for this has to do with the dependency resolution. So for example, instead of jboss-system-client.jar we'll end up with jboss-as-system-${version}-client.jar. Where "client" is a maven classifier that can be used to itdentify this jar as a dependency. (http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-system/5.0.0...) See build 8 for an example of the client jar. So while the names are not the same, I tried to follow a pattern in the naming conventions in order to make it easier to find the matching jars. Will this work? I can change jboss-as-system to jboss-system (and follow the pattern for the rest of the artifacts) if it helps. I just chose that convention because I thought it would make it easier to identify app server component vs. mc components, aop components, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127985#4127985 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127985

18 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Upgrading GPD

by msandoz

Thanks Tom I'll try to catch him while I'm there ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127974#4127974 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127974

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Avoiding creating AOPContainter for MC beans

by bstansberry＠jboss.com

Sorry, I wasn't clear. The bean I don't want to have as an AOPContainerProxy is the "ClusteredSSOCacheConfig" not the @JMX annotated "ClusteredSSOCache". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127958#4127958 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127958

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: DS stats

by scott.stark＠jboss.org

I only see the expected 2 errors, on a different os, vm, so I'm calling bs on the failing tests in hudson for now. Tag beta4. If further issues show up in the console testing I'll address them in the JBAS-4396 patch. JBAS-4396 has been postponed to CR1. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127934#4127934 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127934

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Can you create a MetaValue object without an actual valu

by scott.stark＠jboss.org

So the driving factor for this is the fact that the deployment templates can have ManagedPropertys that have no value. Either templates need include initial values for all properties (maybe not reasonable?), or we need to update the MetaType to support a createValue(TypeInfo), or allow a null in convertValue(Object value, TypeInfo type). What is most practical? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127929#4127929 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127929

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Avoiding creating AOPContainter for MC beans

by adrian＠jboss.org

It's because you have an annotation for just that instance (the @JMX annotation) instead of on the class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127928#4127928 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127928

18 years, 2 months

1
0
0 / 0

[Design of JBoss Build System] - JBossAS CR1 build plan

by scott.stark＠jboss.org

On today's call we still have confusion about what will be done for the CR1 build of jbossas, including exporting of artifacts to maven repos for use by other projects. The main point of confusion is related to how ejb3 is going to be built. It needs jbossas artifacts in maven repo, jbossas needs the ejb3 artifacts for the assembly. The issues to resolve are: 1. What are the jbossas artifacts and how are they being uploaded to a maven repo as part of the build. One simple issue I already see is that the names of the artifacts are changed in the existing pom.xml files. For example in the system project, while the current build produces jboss-system-client.jar and jboss-system.jar artifacts, the system/pom.xml defines jboss-as-system.jar. We need to get to consistent artifact names in both builds as it affects classpaths and configuration files, docs. 2. Getting the jbossas build to use maven artifacts. Nothing currently validates the jbossas maven artifacts. The first step in doing this is to replace the legacy jbossbuild repo with the maven repo as the source for the thirdparty contents. How we do this using ivy, maven ant tasks, etc. needs to be defined and documented, and the existing build-thirdparty target replaced. The next step would be to replace the existing project dependencies (classpaths defined in tools/etc/buildmagic/modules.ent) with the same type of maven repo references as was done for thirdparty. At that point the build and testsuite would be based on the exportable artifacts. 3. How is ejb3/jbossas going to be built with ejb3 as a separate project, that depends on jbossas artifacts. Logically jbossas/ejb3 are a collection of dependent projects. How this translates into a build procedure from tagged codebases is what needs to be defined for CR1. We won't have jbossas completely mavenized by that point, so how a reproducible build results is the question. 4. Related to 3, do we need to restructure the jbossas project, including breaking it up into separate svn projects to support the creation of jbossas artifacts and the jbossas release assembly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127926#4127926 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127926

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: DS stats

by dimitris＠jboss.org

Ok, then I'll wait for the Beta4 tagging. The following goes to CR1? http://jira.jboss.com/jira/browse/JBAS-4396 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127912#4127912 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127912

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Avoiding creating AOPContainter for MC beans

by bstansberry＠jboss.com

I've got some -beans.xml files where I build up a pretty basic pojo configuration object and then inject it into another bean. I'm seeing that the injected object is an instance of AOPContainerProxy rather than the underlying pojo. Anyone know why an AOP proxy is being injected, and if there is a way to turn it off? JBC uses some internal reflection code to change fields on the injected object; this breaks when the object is a proxy. Here's an example from deploy/cluster/jbossweb-clusteredsso-beans.xml: | <bean name="ClusteredSSOCacheConfig" class="org.jboss.cache.config.Configuration"> | | .... set various properties, some with nested beans | | </bean> | |  | <bean name="ClusteredSSOCache" class="org.jboss.cache.jmx.CacheJmxWrapper"> | <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.cache:service=ClusteredSSOCache", exposedInterface=org.jboss.cache.pojo.jmx.PojoCacheJmxWrapperMBean.class, registerDirectly=true)</annotation> | | <property name="configuration"> | <inject bean="ClusteredSSOCacheConfig"/> | </property> | | </bean> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127908#4127908 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127908

18 years, 2 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 February 2008