-
15. Re: JBossAS CR1 build plan
"scott.stark@jboss.org" wrote:
I don't follow why. Sure, both product releases would require separate runs of the top level aggregation entry point, but if both were mavenized, projects properly separated, running the top level jbossas release pom target should be able to build everything.
The jbossas aggregate doesn't know how to build ejb3 artifacts, only the ejb3 aggregate knows this. So if you run mvn release on jbossas it would complain about ejb3 snapshots. Likewise if you run mvn release on ejb3 it would complain about jbossas snapshots."scott.stark@jboss.org" wrote:
In practice I think we should separate the release project from the base artifacts and one would have to run the build in stages. Is that what you mean?
Yes, first you do a mvn release of the jbossas-base, then mvn release ejb3, then mvn release jbossas-product.
(In the same sense that we do a mvn release of jboss-metadata, jboss-container & others before we can do the above.) -
16. Re: JBossAS CR1 build plan
Sorry for this out-of-topic question but:
Why there is a plan to switch from ANT to MVN?
What are the pros/cons that drive this move?
Is there an analysis evaluating it?
I'm asking because AFAIK MVN based build will be slower,
more error prone and its auto-magic handling of dependencies
will cause us more problems than benefits it will bring us. -
17. Re: JBossAS CR1 build plan
"richard.opalka@jboss.com" wrote:
Sorry for this out-of-topic question but:
Why there is a plan to switch from ANT to MVN?
This forum as well as the as forums are full of these discussions. We don't have just an ant build. We have a customized ant build that tries to do some dependency management things mvn does. There was no good reason to try to fix this when other tools exist. -
18. Re: JBossAS CR1 build plan
So based on this morning's call there are two possible plans:
a. Paul works on reproducing the current local jbossas trunk thirdparty structure from maven artifacts. This requires that the existing jbossas project artifacts are the same as the current jbossbuild artifacts. The steps to build and test the server would be:
a1. Build the jbossas projects that ejb3 depends on using maven to make them available via the maven repo.
a2. Build ejb3 to make its artifacts available via the maven repo.
a3. Build the remaining jbossas projects using maven to make them available via the maven repo.
a4. Run an assembly step equivalent to the current build-thirdparty.xml to produce a local thirdparty repository from the maven repository rather than the jbossbuild repository. This allows the existing build/build-distr.xml, testsuite and eclipse project/classpath settings, config files, etc. to remain unchanged.
a5. Run the build/build-distr.xml to create the jboss-5.0.0.CR1 distribution structure.
a6. Run the testsuite as ususal to validate the artifacts. Note that this either requires that the target directory for the maven builds use the jbossbuild output/lib convention, or the testsuite module classpaths need to be updated to refer to the target/* locations of the maven build.
The B plan would be to simply:
b1. Build the jbossas projects that ejb3 depends on using maven to make them available via the maven repo.
b2. Build ejb3 to make its artifacts available via the maven repo.
b3. Upload the ejb3 artifacts to the jbossbuild repository
b4. Run the jbossbuild as ususual. -
19. Re: JBossAS CR1 build plan
I had an interesting discussion with Brian, after the call. He made the very simple observation that until all EJB3 dependencies are identified and externalized (by introducing proper SPIs) what we are having now is a fake independent ejb3 project that complicates thing and doesn't add any real value.
1) Break ejb3 into multiple modules inside the AS codebase (i.e. as per their new ejb3 subprojects). That is, let ejb3 refactor itself into components the way they want.
2) For every other AS module EJB3 depends on, break out the portion that is API/SPI into a separate project like I did with the cluster module. Once that's done, ejb3's dependency on that module is gone.
3) Once each module dependency is gone, *then* ejb3 is really independent; that's when you pull the ejb3 modules out of the AS source tree into their own independent project.
Or else, until the dependency graph for EJB3 is properly mavenized, the project should not move outside AS, causing all this trouble and jumping through hoops.
It really boils down to priorities here (AS5 CR1 vs EJB3 externalization) in which case that looks like a sensible plan C to me. -
20. Re: JBossAS CR1 build plan
Keeping ejb3 in the jbossas project really does not solve anything as far as I can see. Its using a different build system that has to be integrated through either maven repos, jbossbuild repos, or module classpaths. Having it out allows for the developers to do work without breaking the as build. Until they produce an artifact its not impacting jbossas.
The problem of as not having proper spis for the ejb3 dependencies needs to be solved regardless. ejb3 does have a proper dependency graph now. If what it depends on it does not have an spi, then that jbossas project needs to be broken up.
We already have an integration project. If we want to make it a requirement that all ejb3 dependencies are coming from there, fine. I'll post what the ejb3 project dependencies coming from the jbossas project are today. -
21. Re: JBossAS CR1 build plan
These are the jbossas related dependencies I see:
<version.org.jboss.jbossas_jboss-as-aspects>5.0.0.Beta4</version.org.jboss.jbossas_jboss-as-aspects>
<version.org.jboss.jbossas_jboss-as-connector>5.0.0.Beta4</version.org.jboss.jbossas_jboss-as-connector>
<version.org.jboss.jbossas_jboss-as-iiop>5.0.0.Beta4</version.org.jboss.jbossas_jboss-as-iiop>
<version.org.jboss.jbossas_jboss-as-naming>5.0.0.Beta4</version.org.jboss.jbossas_jboss-as-naming>
<version.org.jboss_jnpserver>5.0.0.Beta4</version.org.jboss_jnpserver>
The last two should essentially be the same thing, and even then I'm not sure why there is a dependency on the implementation vs the javax.naming apis. I'm going through the ejb3 dependencies to see what type of additions to the integration project are needed. -
22. Re: JBossAS CR1 build plan
You're forgetting jboss-as-server and the transitive dependencies.
Which means we pull in almost all the AS components.
I can send the dependency graph around again. :-)
Aspects should be a library component. It has nothing to do with AS. They should be pojo aspects for use in any container environment. Maybe an extension component for MC?
I'm not sure why we depend on the JCA implementation. We invoke the resource adapter through the MC. So the API should be enough (possibly some JCA API extentions).
Iiop is an extension and could be separated out. It still requires an AS lib component though.
Naming should be jnpserver (already fixed by Scott).
I think the deployers and client launcher depend on jboss-as-server. Both should be moved from ejb3 to AS. -
23. Re: JBossAS CR1 build plan
All the deployers have been moved out. I'll move the launcher out today.
Aspects can just be moved to its own project.