Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 311615

Summary:	Athena needs to be Hudson Slave friendly
Product:	z_Archived	Reporter:	David Carver <d_a_carver>
Component:	Dash Athena	Assignee:	Project Inbox <athena.build-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	nboldt
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description David Carver

2010-05-04 15:45:45 EDT

Currently the way Athena is designed it makes it difficult to setup an run on a slave machine.   Here are some problems.

The master build machine is running 64bit PPC, the slave is 64bit x86.  This means you need two different target platforms depending on the machine your are building on.

The JDKs that are needed are different.  Athena loads the build.properties file again, and typically this has coded into it the JAVA_HOME, JAVA50_HOME, etc.   Some of these issues may be base builder issues that we need to address.   base builder needs to be able to determine which JVM to use to build based off the JRE restrictions.   If running on master it'll be the PPC jvms, if it is running on the slaves, it'll be the appropriate jvms for the slave machines.

Testing is going to run into similar issues, as the appropriate target platform will need to be constructed.

I've got wst.xsl partially working on the slave, but running into issues with p2.dir and installing some features.

Comment 1 Nick Boldt

2010-05-05 09:59:29 EDT

How about ensuring that the slaves all have the same symlinks in place for latest JDK 1.4 & 1.5 & 1.6, Maven 2 & 3, and Ant 1.7.1 & 1.8?

Then everyone will call java, maven, or ant the same way, regardless of *real* location on disk.

Comment 2 Nick Boldt

2010-05-05 10:35:11 EDT

Also, instead of using the older build.xml or run.sh scripts to start a job, I'd suggest starting your Athena build like this:

http://wiki.eclipse.org/Common_Build_Infrastructure/Getting_Started/Bootstrapping

Comment 3 David Carver

2010-05-05 10:45:50 EDT

(In reply to comment #2)
> Also, instead of using the older build.xml or run.sh scripts to start a job,
> I'd suggest starting your Athena build like this:
> 
> http://wiki.eclipse.org/Common_Build_Infrastructure/Getting_Started/Bootstrapping

If I get a chance later today I'll try the boostrapping method to work with the VEX build.

Comment 4 Nick Boldt

2010-05-24 11:53:37 EDT

(In reply to comment #3)
> (In reply to comment #2)
> > Also, instead of using the older build.xml or run.sh scripts to start a job,
> > I'd suggest starting your Athena build like this:
> > 
> > http://wiki.eclipse.org/Common_Build_Infrastructure/Getting_Started/Bootstrapping
> 
> If I get a chance later today I'll try the boostrapping method to work with the
> VEX build.

Did the bootstrapping method work for you?

Comment 5 David Carver

2010-05-24 13:07:28 EDT

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Also, instead of using the older build.xml or run.sh scripts to start a job,
> > > I'd suggest starting your Athena build like this:
> > > 
> > > http://wiki.eclipse.org/Common_Build_Infrastructure/Getting_Started/Bootstrapping
> > 
> > If I get a chance later today I'll try the boostrapping method to work with the
> > VEX build.
> 
> Did the bootstrapping method work for you?

Yes, the bootstrapping seems to work fine.  In addition users of Athena should use the provisioning of the appropriate target platform through the use of the P2 Product ZIP files.   I didn't get very good results from just pointing at the Helios repository.    Doesn't appear that the platform has a P2 Zip of the product SDK available.  I ended up using the one you created for 3.6M5, but that is not the most current, but it works for my purposes.

My findings are documented here:

http://wiki.eclipse.org/Common_Build_Infrastructure/Getting_Started/Build_In_Hudson/Ant_Job_Distributed