[Design of JBoss Build System] - Re: JBossAS CR1 build plan
by dimitris＠jboss.org
"scott.stark(a)jboss.org" wrote : The problem is I don't know that we can wait for mavenization of jbossas for CR1. We can't have an unusable trunk for any amount of time (other than next week) as there is too much work to do. We also can't have the tck runs impacted. So what I'm suggesting is that start using the maven repo with the current ant build to validate artifacts, classpaths, eclipse project files, etc. Once that is working, how everything is mavenized can be decided.
|
Just to stress out how important this is:
There are *only* 6 development weeks, after JBW for CR1, which means we have only the luxury of the "dead" JBW week to come up with a viable (even interim) solution.
Anything beyond has great chances of jeopartizing the whole plan.
So let's keep the forum discussion going, and if necessary get everyone on a confcall the comming Tuesday.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128007#4128007
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128007
18 years, 2 months
[Design of JBoss Build System] - Re: JBossAS CR1 build plan
by wolfc
"scott.stark(a)jboss.org" wrote : But the problem is that there is a chicken & egg problem. jbossas-5.0.0.GA needs ejb3 2.1.x, which needs jbossas-5.0.0.GA SPI jars. If both were mavenized, the dependencies would handle this by having access to all projects during the build. Since jbossas is not mavenized, we have to build the spi artifacts, uploaded to a maven repo, build the ejb3 artifacts, upload to a maven repo, build the ejb3 dependent artifacts of jbossas, build the jbossas assembly product. Its getting this procedure defined/automated that I'm wanting to get defined for jbossas-5.0.0.CR1.
|
Even if both were mavenized it still wouldn't work, because jbossas and ejb3 run with different aggregators. It needs to become and will from point on always be a multi-stage rocket.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128006#4128006
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128006
18 years, 2 months
[Design of JBoss Build System] - Re: JBossAS CR1 build plan
by wolfc
"pgier" wrote : "scott.stark(a)jboss.org" wrote :
| | 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.
| |
|
| Once ejb3 is mavenized it can still be deployed to the legacy repository using the jboss-deploy plugin or manually. Then the existing build can use the artifacts.
This is not the problem, the problem is the circular dependency.
"pgier" wrote : Maybe Andrew can provide some input on this since he is working on the EJB3 mavenization now.
Alternative strategy: let's demote jbossas/trunk to being a component. We remove jbossas/trunk/ejb3 and build & tag it as CR1. Now the repository contains all jboss-as-components at CR1. EJB 3 builds & tags as CR1, repository has jboss-ejb3-components. Then we take a new project with whatever name we come up with. Which is an assembly of jboss-as-components, jboss-ejb3-plugin, jboss-ws-plugin etc with a complete integration test suite. That new project will be the JBoss AS community edition. (Then EAP is either another project like this or another version of the same project. SOA-P will be another one (either sucking in EAP or AS-Community).)
I think we tackle 3 & 4 with 1 stone then (shouldn't there be a bird in there somewhere).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128004#4128004
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128004
18 years, 2 months
[Design of JBoss Build System] - Re: JBossAS CR1 build plan
by scott.stark＠jboss.org
"pgier" wrote :
| 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.
|
The problem is I don't know that we can wait for mavenization of jbossas for CR1. We can't have an unusable trunk for any amount of time (other than next week) as there is too much work to do. We also can't have the tck runs impacted. So what I'm suggesting is that start using the maven repo with the current ant build to validate artifacts, classpaths, eclipse project files, etc. Once that is working, how everything is mavenized can be decided.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128003#4128003
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128003
18 years, 2 months
[Design of JBoss Build System] - Re: JBossAS CR1 build plan
by scott.stark＠jboss.org
"pgier" wrote :
| Once ejb3 is mavenized it can still be deployed to the legacy repository using the jboss-deploy plugin or manually. Then the existing build can use the artifacts.
|
| Maybe Andrew can provide some input on this since he is working on the EJB3 mavenization now.
|
But the problem is that there is a chicken & egg problem. jbossas-5.0.0.GA needs ejb3 2.1.x, which needs jbossas-5.0.0.GA SPI jars. If both were mavenized, the dependencies would handle this by having access to all projects during the build. Since jbossas is not mavenized, we have to build the spi artifacts, uploaded to a maven repo, build the ejb3 artifacts, upload to a maven repo, build the ejb3 dependent artifacts of jbossas, build the jbossas assembly product. Its getting this procedure defined/automated that I'm wanting to get defined for jbossas-5.0.0.CR1.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128001#4128001
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128001
18 years, 2 months
[Design of JBoss Build System] - Re: JBossAS CR1 build plan
by wolfc
"pgier" wrote : 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?
That's fine for the repo, but in the release there should be no version in the jar name. jbossall-client.jar will contain a Class-Path (soon) which has all jar names in it. I don't want to re-jar because we do a component update. (That's the thing we want to get rid of.)
"pgier" wrote : 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.
|
Personally I don't care if it's called jboss-as-system or jboss-system. We need to redo the class path entries into our build anyway.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127996#4127996
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127996
18 years, 2 months
[Design of JBoss Build System] - Re: JBossAS CR1 build plan
by pgier
"scott.stark(a)jboss.org" wrote :
| 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.
|
Once ejb3 is mavenized it can still be deployed to the legacy repository using the jboss-deploy plugin or manually. Then the existing build can use the artifacts.
Maybe Andrew can provide some input on this since he is working on the EJB3 mavenization now.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127989#4127989
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127989
18 years, 2 months