Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] Re: Command line builds

Valery,
 
At the last Face to Face in Provo, it was agreed that we needed a way to do the builds such that the classpath in the eclipse IDE is the same as the classpath in the command-line build file.  In addition to this, a second requirement was to make it so component owners don't have to hand-edit any build files when they do something like add a new dependency library.
 
The only way I could come up with to meet this requirement was to have eclipse export build.xml and have it auto-import buildaux.xml (by placing <?eclipse.ant.import?> at the top of buildaux.xml).
 
Right now, everytime a component owner changes their project properties, they re-export build.xml (Export, Ant Buildfile).  People don't' want to have to do anythign in addition to that, and yet they want the command-line build to work just like the IDE build.  This means we can't make any manual edits to build.xml.
 
If there's a way to do the things you want while still meeting these requirements, then that would be very welcome.
 
Jim

>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 3/12/07 4:08 PM >>>
Hi Jim,

I'm working on command line build scripts for our components. Most of
them depends on IdAS and I have some problems using IdAS build script
from my scripts.

It appears to me there are two problems with the current IdAS build
script:

1. It appears not possible to produce full-scale Eclipse plugin.
2. It appears not possible to use it with the different version of
Eclipse even to produce standalone jar.

First problem is related to the fact that simple using of Eclipse JDT
compiler to compile project's sources is not enough to produce Eclipse
plugin (actually, it is even not required). To produce full-scale
Eclipse plugin we need to do some extra work. In most cases it is
enough to put appropriate manifest into the resulting jar file but it
is not always true. The best way I know to produce plugin is to use
Eclipse runtime itself. Eclipse IDE uses PDE build scripts to produce
(export) plugins and my idea is to use these PDE build scripts in our
build scripts.

Second problem is related to the fact that
"Plug-in Dependencies.libraryclasspath" path element contains
version specific (Eclipse 3.2) pathelements and if I use Eclipse
3.1.2, for example, I need to change all that pathelements in order to
produce even standalone jar.

To solve above problems I'd propose to make following changes to IdAS
build script:

1. Not to use strong path references to Eclipse plugins. I meant use

<path>
   <fileset dir="${eclipse.home}/plugins">
      <include name="**/*.jar"/>
      <include name="**/*.jar/*.jar"/>
   </fileset>
</path>

instead of current implementation of
"Plug-in Dependencies.libraryclasspath".


2. If Eclipse runtime is not available exclude plugin's specific
classes from the build.

3. Create special target which will call special build script to
produce Eclipse plugin using PDE build scripts.

Also I'd prefer to rename property ECLIPSE_HOME to eclipse.home . The
reason for this is that Eclipse IDE itself uses eclipse.home property
when it runs ant build using the same JRE as the workspace and it runs
PDE build scripts internally. Thus, this will allow to avoid
property's conversions.

As an example you can take a look at I-Card Registry build scripts
documented at http://wiki.eclipse.org/index.php/I-Card_Registry_CVS

Do you mind if I make proposed changes?


--
Thanks,

Valery


Back to the top