Overlord build tool and structure tree.

[jeff.yuchang]

Hi All,

I am wondering which build tool will be used in building overlord project? Ant or Maven2?

currently, what we have on the svn tree are:

soag
|---------docs
|----------install
|----------samples

Next, I want to put my conversation based esb actions codes in to it, like

|----------jbossesb

After that, we might also have the gunvor codes as well, so what is the best practice for you to think on organizing the tree? Any thoughts on this?

Thanks
Jeff

[objectiser]

Under the jbossesb branch, we also need to split the tree into 'server' and 'tools' - as the conformance checking code will have some jbossesb specific code,

In terms of ant or Maven2 - DNA seems to be using Maven2, so if we are going to be working closely with this project, possibly best to use it? However I don't mind either approach.

[jeff.yuchang]

Ahh...right, thanks for Gary's reminder. ;-)

Personally, I'd like to use maven2. but I am ok with Ant too, as long as we have the "module" concept, say we can only build jbossesb-server module. jbossesb-tools module.

AFAIK, the gunvor also use the maven...

Well, "ANT vs Maven" is kind of debate, which will lead to people's philosophy... so we won't talk about their pro and cons on those two tools itself.. otherwise, it will be a long long discussion... ;-)

[jeff.yuchang]

Well, a question on maven build tool is that right now the jbossesb.jar is not be mavenized... so it would be a problem for our dependency, but we can add the jbossesb.jar as one big jar in the maven repository (I assume jboss have a maven repository) as a temporary solution?

[objectiser]

Yes, I think that would be fine as a solution.

[marklittle]

All of our projects are moving to Maven so it makes sense to do that here sooner rather than later.

[objectiser]

Haven't used Maven to build Eclipse plugins before, but just started reading this article http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html which seems to indicate there are some "tweaks" required - but I am sure we can deal with these as required.

One point they make is that they grouped their Eclipse plugins into one part of their source hierarchy. So possibly we should do the same, so rather than having a jbossesb root folder with runtime and tools components, possibly we should invert this and have 'runtime' (or 'server') and 'tools' top level folders, with the platform specific folders inside (i.e. just jbossesb initially).

[jeff.yuchang]

ok, sounds good to me...

[objectiser]

Looking at building the Eclipse plugin using Maven and ran into this problem:

Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0.0)
org.eclipse.equinox:app:jar:null

Its a known problem related to the latest Eclipse plugins on the central maven repository (http://repo1.maven.org/eclipse-staging).

The other issue with this repository is how often it is updated - latest version of the org.eclipse.core.resources plugin is 3.3.0 from June 2007.

Will need to consider the implications ......

The other approach would be to embed an ant task to build the plugins, but from what I have seen, the Eclipse pde export task can only be run within an Eclipse environment.

[objectiser]

Have created a structure to support Maven build of the Eclipse tools, that represents an update site. The reason being that when installed as a distribution, the user will then be able to install the plugins from the distribution. The same update site structure could also then be hosted - not sure if RedHat currently host an update site for any of their Eclipse plugins?

Outstanding issues:

1) Problem retrieving some Eclipse plugin dependencies, as indicated in the previous post. Had to manually install them in the local repository. This will make it difficult for users. Need to find a better solution.

Consequently I have not included the 'tools' module in the top level pom.xml yet, to avoid builds failing for the runtime.

2) Plugin builds - there are some Maven plugins that can be used to package an Eclipse plugin. However they overwrite the Manifest.mf with an autogenerated one - which overwrites some attributes that I need. Will need to investigate other options.

The only problem with the current approach is that the plugin version is not auto set from the pom.xml version - so at present this would need to be manually set. However we may also want the Eclipse plugin version to include a qualifier?

3) Distribution structure

a) Do we want the runtime and tools to be in the same distribution?

b) As the runtime and tools have platform specific targets, we will probably want the distributions to also be platform specific - i.e. not all platforms in one distribution. So possibly the governance aspects currently in the distribution would need to be jbossesb specific.

c) Should the distribution folder be checked in? Or should it be the target for the build of the other components? If so, then the current content of the distribution folder should be placed in (possibly) a top level 'governance' (or 'monitor') folder (along side runtime and tools), and then installed in to a transient distribution folder under jbossesb. May just want the content to be placed under the current runtime/jbossesb folder?

4) Other dependent plugins - until the conformance work is further advanced, it will not be possible to place these in a public maven repository, although we could sort out placing them in a temporary (or local) repository in the meantime - when it becomes appropriate.

[objectiser]

Before trying to resolve the problems with building Eclipse plugins using Maven (i.e. points 1 and 2 above), I just wanted to double check that we wanted to use Maven for this task.

I understand that projects, such as JBossESB, are being migrated to use Maven - however the JBoss tools project (which primarily has Eclipse plugins), does not seem to use Ant or Maven - so I assume they are just built directly with Eclipse - which is the way I have always built the pi4soa plugins for distribution (and the update site).

Therefore I would propose that we do not build the Eclipse plugins with Maven (atleast until this is a simple task to perform), and distribution of the plugins should be through a RedHat hosted update site rather than as part of a binary distribution.

Thoughts?

[jeff.yuchang]

"objectiser" wrote:


3) Distribution structure

a) Do we want the runtime and tools to be in the same distribution?

IMHO, I'd like to have these two separated, say one for runtime, the other for tools.

"objectiser" wrote:

b) As the runtime and tools have platform specific targets, we will probably want the distributions to also be platform specific - i.e. not all platforms in one distribution. So possibly the governance aspects currently in the distribution would need to be jbossesb specific.

+1, actually, I haven't thought deeply on the "distribution" folder, especially on the "governance.zip" which we have finished before.

"objectiser" wrote:

c) Should the distribution folder be checked in? Or should it be the target for the build of the other components? If so, then the current content of the distribution folder should be placed in (possibly) a top level 'governance' (or 'monitor') folder (along side runtime and tools), and then installed in to a transient distribution folder under jbossesb. May just want the content to be placed under the current runtime/jbossesb folder?

I'd like to have a distribution or "release" as an altertinative, contains some platform-specifc xml, such as assembly.xml which contains the Linux-OS, Windows-OS specific instructions. and we can even build a all-for-one artifact in the distribution/target folder.
That's what I am thinking on the distribution folder, again, I still haven't figured out where to put the "governance.zip", which is the trailblazer monitor artifact.

[jeff.yuchang]

"objectiser" wrote:


I understand that projects, such as JBossESB, are being migrated to use Maven - however the JBoss tools project (which primarily has Eclipse plugins), does not seem to use Ant or Maven - so I assume they are just built directly with Eclipse - which is the way I have always built the pi4soa plugins for distribution (and the update site).

Therefore I would propose that we do not build the Eclipse plugins with Maven (atleast until this is a simple task to perform), and distribution of the plugins should be through a RedHat hosted update site rather than as part of a binary distribution.

Thoughts?

I talked to the tools team, it seems that mostly they used the Eclipse one as you said, but they do have some ant scripts, which just some wrappers of the Eclipse one. well, they said current approach (ant wrapper) is not good, they are working on finding a better solution.

So, with this fact, I agree with you, if you want to mavenize it, we might have some other problems ahead, which requires many efforts we don't want to spend. Also since the runtime and tools might be two separate artifacts, I believe it is ok for them to use two different build tool.

BTW, Redhat do have a JBoss Tools plugin update site URL, http://download.jboss.org/jbosstools/updates/stable/. It is just for released stuff.