jboss-dev-forums

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<sco...@jb...>]

Ok, but I first want to see 4.0 building from a repository generated thirdparty structure which only entails getting the repository populated for 1).

For 2), the existing jboss-4.0/build/build-thirdparty.xml needs to be populated with the componentrefs for the thirdparty repository libraries needed to build the server.

3-5 are the same.

I'm thinking that it will take less to get this working for 4.0 than introducing component-info.xml for every module. If you don't think this is the case, fine, but this needs to be working for the 4.0.3 release.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882442#3882442

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882442

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rl...@jb...>]

I worked with this yesterday and created a build-thirdparty.xml based off of what was in the thirdparty directory in the 4.0 branch.   I found a couple of things that will need clarification.

1)  hibernate thirdparty vs. hibernate module

Currently when we try to pull down the thirdparty modules the build sees a directory "hibernate"  (our integration module).  Because this module exists it will not pull down the thirdparty component "hibernate".   How should we resolve this?   The way the build is currently structured a thirdparty component cannot have the same name as a source module.   Should the hibernate thirdparty be moved to jboss/hibernate?  

2)  what we use vs. what is there

If I go through every module under 4.0 (e.g. iiop, varia) looking at the build.xml file and look at what library classpaths are defined, and then creating a list of all library dependencies required, the list does not match the number of items in thirdparty.  I assume some items in thirdparty (the early version of tomcat for example) are no longer used.   Should I base the generated libraries.ent off of the cvs thirdparty dir as a whole, or just off of what is used.  

3)  naming conventions

Currently in the repository we have some dual directories, one called juddi, one called juddi-juddi.   Which should I base off of?

4)  new thirdparty items

In some cases, such as apache commons, the jars have been moved to their own repository locations.   Won't this necessitate a change to the build.xml files ?

Thanks!
Ruel Loehr

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882653#3882653

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882653

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rya...@jb...>]

1.  This is a by product of using the directory name as the component id.  We might be able to fix jbossbuild to have two components by the same name, one in thirdparty and one source component, but I'm afraid this leads to ambiguity.

We shouldn't rename the thirdparty hibernate.  If anything, the hibernate integration module needs to be renamed to hibernate-intg or something.

2. just what is being used.

3.  We aren't using the double named convention anymore, so just use juddi.  Make sure it has the correct version from the 4.0 versions.xml

4.  Yes it will, but let's commit what we have before making changes to build.xmls.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882654#3882654

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882654

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<sco...@jb...>]

1) This is because there is a notion of a component and it can be either a source or binary module? The hibernate integration module can be changed in the current jboss-4.0.x definition:


  | jboss-4.0.x        -d jboss-4.0 \
  |                         &_jboss_aop \
  | ...
  |                         -d har  hibernate \
  | ...
  | 

The build.xml modules reference to hibernate would have to be changed locally to do the build.

2) There certainly is tons of garbarge in there. The thirdparty build should be created by only referencing the direct dependencies of the toplevel components. Build the thirdparty strucuture and try the build and add thirdparty componentrefs as needed until it builds.

3) As Ryan said, drop the double name usage as its a cvs hack issue that we should not propagate.

4) The only place the new thirdparty lib names should be showing up at is in the libraries.ent definitions. Nearly all build files in the modules should simply be referencing the *.classpath from librariens.ent. The only problem will be that there will not be an aggregate classpath like apache.commons.classpath. You could deal with this by adding a notion of being able to merge multiple component paths to the libraries.ent generation:


  |   <path id="apache.commons.classpath">
  |     <componentref id="apache-lang" />
  |     <componentref id="apache-logging" />
  |     <componentref id="apache-modeler" />
  | ...
  |   </path>
  | 


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882690#3882690

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882690

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rl...@jb...>]

Excellent!    That leaves me with only two references from the collection of build.xml files that I am not sure how to handle.

1)  ant

The current libraries.ent has an entry for ant.

  <!-- Ant -->
  |   <property name="apache.ant.root" value="${project.tools}"/>
  |   <property name="apache.ant.lib" value="${apache.ant.root}/lib"/>
  |   <path id="apache.ant.classpath">
  |     <pathelement path="${apache.ant.lib}/ant.jar"/>
  |   </path>

The version of ant is found in the tools directory, not in the thirdparty. For the generated libraries.ent to have an entry for it, it would need to exist in the repository.    How should we handle this?

2)  EJB-Pesistence

The current libraries.ent handles ejb-persistence like this:

  <!-- hibernate3 -->
  |   <property name="hibernate.root" value="${project.thirdparty}/hibernate"/>
  |   <property name="hibernate.lib" value="${hibernate.root}/lib"/>
  |   <path id="hibernate3.classpath">
  |     <pathelement path="${hibernate.lib}/hibernate3.jar"/>
  |     <pathelement path="${hibernate.lib}/hibernate-annotations.jar"/>
  |     <pathelement path="${hibernate.lib}/asm.jar"/>
  |     <pathelement path="${hibernate.lib}/asm-attrs.jar"/>
  |     <pathelement path="${hibernate.lib}/antlr*.jar"/>
  |   </path>
  | 
  |   <!-- ejb3-persistence -->
  |   <path id="ejb3-persistence.classpath">
  |     <pathelement path="${hibernate.lib}/hibernate-annotations.jar"/>
  |     <pathelement path="${hibernate.lib}/hibernate-entitymanager.jar"/>
  |     <pathelement path="${hibernate.lib}/ejb3-persistence.jar"/>
  |   </path>


An ejb3-persistence classpath is defined, but it is part of hibernate (in the directory structure).   The same problem exists as with ant.  For an entry to be generated, it needs to have its own repository location, but does it make sense to break this out as a seperate entity?

Ruel Loehr
JBoss QA

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882735#3882735

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882735

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<sco...@jb...>]

1) Ant should be in the repository as well, but currently we do not include it into jboss. Tomcat used to until the switch to the jdt compiler. As of now there  should be no need for this in libraries.ent.

2) So really, hibernate, hibernate annotations, and hibernate entitymanager (which is what I assme has the ejb3-persistence.jar artifact, ask Bill or Emmanuel) should be seperate entries in the repository as they are three seperate releases currently:

http://www.hibernate.org/6.html



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882736#3882736

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882736

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rl...@jb...>]

I committed an initial pass at the thirdparty-build.xml file.  At this point it should be a very close representation of what is required to build the 4.0 branch.  

I am sure other adjustments will be required after generating the libraries.ent and attempting building (my next task) (e.g changing module names of hibernate & xdoclet).

user instructions:

mkdir test
cd test
cvs co -r Branch_4_0 jboss-4.0.x
cd jboss-4.0
cd build
ant -f build-thirdparty.xml
cd ../thirdparty
ls

Ruel Loehr
JBoss QA


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883410#3883410

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883410

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<sco...@jb...>]

It looks ok, but until the libraries.ent is generated and we can actually get the codebase to compile and tested I can't say for sure.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883688#3883688

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883688

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rl...@jb...>]

While working on building I ran across an inconsistency with the old system.   In the file modules.ent, from the buildmagic system, the following is defined:

  <!-- AOP -->
  |   <property name="jboss.aop.root" value="${project.root}/thirdparty/jboss-aop"/>
  |   <property name="jboss.aop.lib" value="${jboss.aop.root}/lib"/>
  |   <path id="jboss.aop.classpath">
  |     <pathelement path="${jboss.aop.lib}/jboss-aop.jar"/>
  |   </path>


This file defines only module properties except for the above.  I think this definition should be moved to the libraries.ent file for the following reasons:

1)  Consistency
2)  If the property exists in the libraries.ent file we can give it the proper value (with the version number in the path) when we generate a new one.  If it remains in the modules.ent the property is set and immutable.  The build.xml would have to be modified to reference the correct path.  (bad) 

Are there any reasons why we couldn't or shouldn't do this?

Ruel Loehr 
JBoss QA

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883748#3883748

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883748

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<sco...@jb...>]

No reason not to move it. The aop used to be a module in the jboss-4.0 but has now been moved to thirdparty and its classpath should be moved there as well.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883908#3883908

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883908

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[seetesh_h <nu...@jb...>]

Hello all,

Sorry to have intrued in this forum.

Does Jboss 4.0.x support Hibernate with Spring framework?

Rgds,

Seet

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884202#3884202

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884202

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rl...@jb...>]

Using the thirdparty-build.xml definitions file, a generated libraries.ent file, and a generated thirdparty folder, I have succesfully completed builds using both the 1.4 and 1.5 compiler.   The following instructions will execute this functionality.


mkdir test
  | cd test
  | cvs co -r Branch_4_0 jboss-4.0.x
  | cd jboss-4.0
  | cd build
  | ant -f build-thirdparty.xml generate-lib-file 
  | ./build.sh
  | cd output
  | cd jboss-4.0.3RC1
  | cd bin
  | ./run.sh
  | 

The dependencies are downloaded and then the target "generate-lib-file" creates a libraries.ent file which has the correct path information.  

I will continue work on validating the build and running the testsuite.


Ruel Loehr
JBoss QA

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884242#3884242

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884242

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rya...@jb...>]

We should run the testsuite, but the easiest way to verify that the distros are exactly the same is just to compare the output of one with the other:

diff -br jboss-4.0/build/output/ jboss-4.0.x/build/output



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884412#3884412

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884412

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rl...@jb...>]

The diff yielded excellent results.   The structures are the same except for jar files which were constructed by the build, and these differ by only a few bytes (due to time stamps, or version numbers in the manifest files and such).

I do have one task left which needs to be resolved.   The testsuite build.xml file uses /tools/etc/libraries.xml for its properties definitions while the rest of the modules use libraries.ent.    Upon examination the files look to be relatively the same (libraries.xml is slightly out of date).   Could we modify the libraries.xml to include the libraries.ent rather than redefining it?   This way we would only have to worry about the maintenance of one file.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884439#3884439

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884439

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<ad...@jb...>]

Yes please. We should remove libraries.xml and replace it uses with libraries.ent 

And do the same with modules.xml -> modules.ent
if you have the time while you are there.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884440#3884440

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884440

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rl...@jb...>]

As the build based upon the repository is now complete my next thoughts are on how is the best way to deploy this.   

A couple of points to consider are :
1) Maintaining backwards compatability
2) How maintenance will occur when changing the version of a dependency

At one point it was discussed that a thirdparty folder that has been generated from the repository would be checked into cvs.  This folder would then be aliased into the 4.0.x module.   Does this still hold true?

Whenever the build-thirdparty.xml file is modified a few events will need to transpire:

1)  Regenerate the thirdparty directory
2)  Check-in changes
3)  Generate a new libraries.ent file
4)  Check-in changes

(provided that these items are being stored in cvs).

Previously we had discussed storing the libraries.ent file as an artifact somewhere in the thirdparty directory.  At some point (preferably build time) we must choose which version of the libraries.ent file to use; the one which contains the repository path structure, or the existing libraries.ent.  This could be determined via a property passed in to the script.

Thoughts?

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884555#3884555

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884555

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<sco...@jb...>]

I'm inclined to not checkin the thirdparty contents into cvs and to simply change the directions for building 4.0.3+ to include using the jboss-4.0.x cvs alias. The first dependency of the jboss-4.0/build/build.xml should be to build the thirdparty contents based on the build-thirdparty.xml.

The libraries.ent file should be an artifact generated in the thirdparty directory and the scripts should be updated to use this version.

The source release associated with a dist would continue to include the thirdparty contents so that its a self contained bundle.

The biggest compatibility issue are the eclipse classpath entries. Someone can write another visitor that generates the project eclipse classpath when thirdparty is build instead of relying on cvs versions.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884578#3884578

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884578

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<ad...@jb...>]

"sco...@jb..." wrote : 
  | The biggest compatibility issue are the eclipse classpath entries. Someone can write another visitor that generates the project eclipse classpath when thirdparty is build instead of relying on cvs versions.
  | 

This already exists as part of the "synchronize" in the new build, but it has been
broken by all the refactoring.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884579#3884579

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884579

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rl...@jb...>]

Two issues have come up today which I would like to get confirmation on.

1) libraries.ent generation location

If we generate a libraries.ent and store it in the thirdparty folder this will require a change to the build.xml files.  The buildfiles currently reference it in this manner:

ENTITY libraries SYSTEM "../tools/buildmagic/etc/libraries.ent"  which we change to look like this:

ENTITY libraries SYSTEM "../thirdparty/libraries.ent"

If this were to be modified to point to the thirdparty location we will have a problem when the thirdparty folder is not yet present.  For example, if we were to perform a clean checkout of JBoss-4.0.x (which does not pull down the thirdparty folder) and then try to build we will immediately get an exception stating that the the libraries.ent file is not found.  This is valid as we have not generated it yet.

A simple solution would be to place the generated file in the same location as the pre-existing file.  If a user ever wished to revert back he would simply pull down the old version from cvs.   

Next:

Adrian raised a valid issue regarding making the thirdparty downloading the first target of the build.

anonymous wrote : You cannot do that, unless there is mechanism to disable it (e.g. an unless="property").
  | What happens if somebody is working offline?

The way that I have set this up is that there is indeed an unless property.  If the build-thirdparty.xml file is newer than the libraries.ent file then the downloads from the repository will take place.  Otherwise the build will transpire as usual.    If you do not have the thirdparty components on your machine and you do not have a net connection you will not be able to build.



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884790#3884790

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884790

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<sco...@jb...>]

The libraries are only used by the main build when creating the dist. They have no purpose for building thirdparty or compiling the modules. Couldn't we simply break out the install target into a seperate build-dist.xml file that contains the install and related targets?

Unless you do this, the initial build will be using the obsolete ../tools/buildmagic/etc/libraries.ent version and would fail anyway when the incorrect libraries were used.

There should be a way to disable initiating the thirdparty build as suggested.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884793#3884793

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884793

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rl...@jb...>]

As suggested, I was able to move the installation targets from the main build.xml file and into a build-distr.xml file (work done locally).

At this point I am ready to commit and perform integration testing on the thirdparty build system.  In order to not disturb development during this period we will create a branch to do this.

Ruel Loehr
JBoss QA

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885102#3885102

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885102

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rya...@jb...>]

I have created Repo_Branch_4_0 for this.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885299#3885299

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885299

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rl...@jb...>]

I have fully integrated all changes for the jboss thirdparty build on the branch Repo_Branch_4_0.  The output directories match up and testsuite results are consistent with a regular 4.0 build both with 1.4 and 1.5 compilers.

You can test this in the following fashion:

mkdir test
cd test
cvs co -r Repo_Branch_4_0 jboss-4.0.x
cd jboss-4.0
cd build
./build.sh

The first time build.sh is executed the dependencies will be downloaded from the repository.   Later attempts at building will not download the thirdparty dependencies unless the build-thirdparty.xml file has been updated.

In anticipation of migration to the thirdparty build I have set up a JBossBuild wiki page:  
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossBuild

The final step for deployment will be to merge this branch into the Branch_4_0.   

What is the best process for doing this (e.g. notifying people, lead time, day to do it...)?



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886122#3886122

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886122

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<sco...@jb...>]

I have gone through the build and it looks good so far. I'm still running the unit tests.

The wiki page needs to be more strict about how the thirdparty contents are maintained. Generally, one should never update existing binaries. The only time this should be done is for snapshots on pre-release binaries.

The respository is also independent of any existing build, so the discussion about looking to the build/build-thirdparty.xml for the correct version is off target. Someone has version x.y.z of a binary and they simply need to know how to add this to the repository.

Its a independent choice to update the jboss-x.y/build/build-thirdparty.xml version to refer to the newer version. It may very well never happen, and there needs to be a jira issue that documents every change in thirdparty dependencies.

As for merging this, announce it on the dev list and give it 24 hours to sink in. If I find a major problem in running the testsuite I'll followup to the dev list announcement.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886171#3886171

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886171

[Jboss-dev-forums] [Design of JBoss Build System] - Re: JBoss Third Party Build

[<rl...@jb...>]

I have released the 4.0 thirdparty build.   

It can be checked out and build in the following fashion.


cvs co -r Branch_4_0 jboss-4.0.x    
cd JBoss-4.0/build
./build.sh


I have updated and will continue updating the wiki as quesitons arise.   http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossBuild .

The cruisecontrol scipt is also in the process of being update to reflect these changes.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886639#3886639

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886639