September 2007 - jboss-dev-forums

[Design of JBoss Build System] - Re: Getting the release process working with javaee

by scott.stark＠jboss.org

"pgier" wrote : For the release of javaee, should each of the sub-projects to use https://svn.jboss.org/repos/jbossas/projects/javaee/tags/ | as the base directory? | | So we end up with something like ? | tags/jboss-javaee-5.0.0.Beta | tags/jboss-servlet-api-2.5.Beta | tags/jboss-ejb-api-3.0.0.Beta | etc.. | I would just have the https://svn.jboss.org/repos/jbossas/projects/javaee/tags/5.0.0.Beta3/ tag contain the entire project structure that makes up the 5.0.0.Beta3 release, and this would include the various projects with their independent pom versions. It should just be a big bang release. It is likely that many subprojects are not going to change as we go from 5.0.0.Beta3 to 5.0.0.GA, but they should still be revd in terms of the qualifier as the aggregate release is revd. Maybe the aggregate qualifier (Beta3 in this case) should just be appended to all of the subprojects for simplicity. "pgier" wrote : | Another question is do we need to release them all at once? Could we just release the modules as needed, and release the combined jar using previously released versions of the modules? This is mostly an issue of ease of release management vs tracking compatibility. If the projects only change their version when there is a code change, its code should still be under the https://svn.jboss.org/repos/jbossas/projects/javaee/tags/x.y.z for the aggregate release. Maven should simply not re-release the same code. If a project depends on another whose version has changed, its dependency/compatiblity range should be updated and re-released. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082286#4082286 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082286

17 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: Getting the release process working with javaee

by pgier

For the release of javaee, should each of the sub-projects to use https://svn.jboss.org/repos/jbossas/projects/javaee/tags/ as the base directory? So we end up with something like ? tags/jboss-javaee-5.0.0.Beta tags/jboss-servlet-api-2.5.Beta tags/jboss-ejb-api-3.0.0.Beta etc.. Another question is do we need to release them all at once? Could we just release the modules as needed, and release the combined jar using previously released versions of the modules? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082279#4082279 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082279

17 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: Getting the release process working with javaee

by pgier

"scott.stark(a)jboss.org" wrote : | 1. Being able to to a mvn release:* to create the canonical maven2 artifacts as well as the jboss repo artifacts. A current issue is how the versioning is handled. You have to have x.y-SNAPSHOT releases of every project, and these are updated to x.(y+1)-SNAPSHOT in trunk (unless overriden). This does not match our versioning conventions of x.y.z.[Alpha|Beta|CR|GA] in that there can be several x.y.z releases with only the qualifier changing. Its a pain to have to override the release and next version for a large project like javaee, and worse for the mc. Can we customize this to better match our conventions? | We don't have many options for customizing the defaults for a release. For example, the release plugin doesn't have any way to know whether the next release after Beta1 should be Beta2 or CR1. For mc I don't think it's an issue because all the modules have the same version, so you just have to type it in once. With javaee since all the sub-projects are at different versions, there isn't any way I can think of to get around just entering the version for each one. "scott.stark(a)jboss.org" wrote : | 2. The eclipse project classpath settings need to be updated for the version updates as part of the release process. | Would it be better to not have the .project and .classpath in subversion? I normally use the IDE plugin (http://m2eclipse.codehaus.org/) and it generates the classpath for me from the pom. It's not perfect, but it's gradually getting better. Also, don't some people use IDEA? The .project and .classpath are useless for them anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082276#4082276 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082276

17 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: Getting the release process working with javaee

by pgier

It looks like a couple of the dependencies in javaee are now out of sync. For example, jboss-ejb-api has a dependency on jboss-transaction-api 1.0.2-SNAPSHOT, which doesn't really exist. I think they were updated by the release plugin, and then didn't get switched back. I will fix these as I find them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082272#4082272 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082272

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failure on XAResourceRecoveryTest

by clebert.suconic＠jboss.com

Another problem that I found was, when initializing TxControl, that is also initializing the StatusManager in a socket, and that caused the RecoverModule not being able to connect somehow. I'm still investigating. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082269#4082269 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082269

17 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deployer order solely based on inputs/outputs now?

by bill.burke＠jboss.com

For JNDI dependencies, I see no other way other than the javax.naming.event solution we talked about. As you said, there's no way to be notified when something is unbound from JNDI. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082250#4082250 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082250

17 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deployer order solely based on inputs/outputs now?

by bill.burke＠jboss.com

Having dependencies on the deployment instead of the actual EJB container makes no sense to me whatsoever, especially considering the lack of metadata needed to concretely resolve certain dependencies (@EJB). So maybe 4 deployers: 1. Parse and create metadata (PARSE) 2. Process anonotations (POST_CLASSLOADER) 3. Instantiate EJB containers and register them. (POST_CLASSLOADER stage, ordered after annotation processor). 4. Real deployer, process references, create dependency items, install EJB containers with these dependency items. If an EJB container has an @EJB/@PC dependency, it wouldn't be affected by an arbitrary stop/redeploy because it would already know the concrete kernel names it depended on. Unless of course the user changed the referenced EJB or PC's name, but we don't have to handle that situation. For the piecemeal scenario (at least my definitino of piecemeal), we *cannot* support the scenario of somebody deploying something first, then deploying something that it depends on 1 hour later and expecting the dependency to be resolved unless the user has defined adequate metadata to resolve the dependency (i.e. @EJB with only interface as identifying metadata will not work). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082249#4082249 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082249

17 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Getting the release process working with javaee

by scott.stark＠jboss.org

So one thing we need to do is flesh out the release process for multi-project releases like the mc and javaee. Javaee is the simpler, and needs to have the canonical projects re-released as .Beta1s, so lets start with that. What we need working is: 1. Being able to to a mvn release:* to create the canonical maven2 artifacts as well as the jboss repo artifacts. A current issue is how the versioning is handled. You have to have x.y-SNAPSHOT releases of every project, and these are updated to x.(y+1)-SNAPSHOT in trunk (unless overriden). This does not match our versioning conventions of x.y.z.[Alpha|Beta|CR|GA] in that there can be several x.y.z releases with only the qualifier changing. Its a pain to have to override the release and next version for a large project like javaee, and worse for the mc. Can we customize this to better match our conventions? 2. The contents uploaded to the legacy jboss repo are some aggregate view of the canonical projects. This generally is not the same as the aggregate contents one wants for a release upload to jboss.org. We need integration between the maven-jboss-deploy-plugin and an aggregrator description to define how to create the jbossrepor/{component-info.xml,resources,bin,lib} contents. 3. We need a consistent set of steps one can follow in http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenReleaseProcess for any maven based project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082247#4082247 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082247

17 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deployer order solely based on inputs/outputs now?

by bill.burke＠jboss.com

You're talking about DeploymentUnit dependencies, not components, right? So, if I create dependencies on the EJB container itself, rather than the deployment I'll be ok. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082243#4082243 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082243

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: More build problems.

by scott.stark＠jboss.org

The 2_0 branch and Beta4 eclipse projects are working for me so that should be what is needed for trunk. We need to get the maven release process to update the project classpaths. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082240#4082240 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082240

17 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2007