Project Structure

[ccrouch]

Here are some suggestions and queries about the project structure to be used for the Admin Console:

Suggested CVS module name in cvs.sourceforge.net: jboss-admin-console

CVS Branch: The first version of the Admin Console is intended to be deployed on JBoss AS v4.0.x, with the potential of it being backported to the 3.2.x series. Given this, what would be the best CVS branch on which to build?

Build system: buildmagic or the new build system?

Thanks

[dimitris]

I'd say Branch_4_0 and "traditional" buildmagic, if we are talking about the 3.x/4.x branches. The new build system is changed in HEAD, from what I understand.

Scott, should really confirm this.

[ccrouch]

So if we go with buildmagic one of things to manage will be the 3rd Party dependencies:

I've looked at \etc\buildmagic\libraries.ent in the tools module in CVS. I should be adding references to thirdparty .jars which the Admin Consoles needs in here right? And then add the jars themselves inside the thirdparty module folder?

1) What are the standards for the folder structure inside the thirdparty module? commons-logging (v1.0.1-dev) is in thirdparty/apache/struts/lib/ and also (v1.0.3) in thirdparty/apache/commons/lib/.

2) What are the naming conventions for archives in the thirdparty module? Some archives include a version as part of the name and others don't.

3) How should I go about resolving conflicts between versions of jars that the Admin Console needs and versions already existing in the thirdparty module?

Thanks very much.

[starksm64]

Since this should be a replacement for the web-console and this bundled with the app server why isn't this just going into the existing jboss-4.0/console module?

The thirdparty jars need to be canonicalized to ensure that the dependencies are understood. There should not be 10 commons-logging.jars in the thirdparty module. There is no naming convention for encoding the version in the jar name. The version info needs to be tracked along with the license and source of the thirdparty content in the thirdparty/licenses/thirdparty-licenses.xml file.

[ccrouch]

Since this should be a replacement for the web-console and this bundled with the app server why isn't this just going into the existing jboss-4.0/console module?

Currently I view the Admin Console as complementing rather than replacing the web-console. I could see a case in the future for migrating some of the reporting/alert information to the Admin Console, but for at least the first few release of the Console they will have very distinct capabilities. Given that existing web-console users will want to continue using it once the Admin Console is released, would we not be better off keeping the two separate and having a new module?

With respect to how the Admin Console is packaged I think that is still an open question. We will obviously want to bundle it with future releases of JBoss AS, but couldn't there be advantages from releasing it as a separate download as well, so that users can plugin the console to existing/compliant installations of JBoss AS?

The thirdparty jars need to be canonicalized to ensure that the dependencies are understood. There should not be 10 commons-logging.jars in the thirdparty module.

I will raise an issue in JIRA.

There is no naming convention for encoding the version in the jar name. The version info needs to be tracked along with the license and source of the thirdparty content in the thirdparty/licenses/thirdparty-licenses.xml file.

Not all jars in the thirdparty module are described in the thirdparty-licenses.xml, e.g. none of the jars in the ibm folder. Plus it needs a bit of tidy up to remove stuff like this:

<module name="odmg" licenseType="lgpl"
 version="3.8.1"
 projectHome="http://www.junit.org/index.htm"
 description="Java unit testing framework">
 <jar name="odmg-3.0.jar" />
</module>

I will mention this in the JIRA issue.

Thanks

[starksm64]

If this is going to be a new module then use the new build structure. There is no reason to keep propgating the buildmagic nonsense.

Ultimately I see no reason for there to be multiple consoles. The jmx-console, web-console and admin console should all be based on the same underlying architecture with different plugins and services comprising the functionality. The existing consoles should be left alone, and the admin console eventually subsumes their behavior. We have to have a single well documented console.

The thirdparty and licenses contents needs to be kept consistent and up to date. If this is not the case it needs to be fixed.

[ccrouch]

Ultimately I see no reason for there to be multiple consoles. The jmx-console, web-console and admin console should all be based on the same underlying architecture with different plugins and services comprising the functionality. The existing consoles should be left alone, and the admin console eventually subsumes their behavior. We have to have a single well documented console.

Agreed. I believe that the JSF/Portal based approach that the Admin Console will eventually move to is the best way of supporting a plugin based architecture.

The thirdparty and licenses contents needs to be kept consistent and up to date. If this is not the case it needs to be fixed.

http://jira.jboss.com/jira/browse/JBAS-1308

[ccrouch]

So just to summarize:

Module name at cvs.sourceforge.net: jboss-admin-console.

CVS Branch: Branch_4_0.

Build system: New build system.

Thanks

[ryan.campbell]

In order for jboss-admin-console to use the new build system, I'll need to merge it from head. I was hoping we could get things sorted out well in head before we had to start back-porting.

However, so long as jboss-admin-console has a shallow dependency tree, I don't think this would be that big of a deal. My understading from charles is that he needs jmx apis, so it would need to include j2ee(?). So it would include adding the following to jboss-4.0.

jboss-as/jbossbuild.xml
j2ee/jbossbuild.xml
common/jbossbuild.xml
tools/etc/jbossbuild/tasks.xml
tools/lib/jbossbuild.jar

Alternatively, Charles could use a simple non-integrated build (with local /lib?) and integrate with the new build system later.

[ccrouch]

FYI the structure we are going with is as follows:


Module name at cvs.sourceforge.net: jboss-admin-console

CVS Branch: HEAD

Build system: New build system

The jboss-admin-console module has been created in HEAD of sourceforge CVS. At the moment the module just contains a skeleton project structure. We are currently pulling third party dependencies (e.g. Struts) into CVS so that we can get building.

Thanks