automated build

[Michael Caron]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Alex (and team)

I thought of tackling the issue of automated builds. I'm looking into
the structure currently and figuring out a good route. I've used both
Ant and Maven in the past. I'd prefer to use Maven because it's pretty
easy to set up dependencies on things and just have them automatically
included. I've got to familiarize myself with building eclipse plugins
and how everything works together.

Some questions that came up for me:

1. Using google's hosting service, is there a build farm that would
run a build and serve nightly builds? If not, we could use one of our
machines to do a nightly build and upload the resulting build to the
code site wiki. Would be nice to have nightly builds going once build
automation is complete.

2. First thoughts are to create a project to wrap all the build logic
rather than put it in the root trunk folder. That particular project
then could reference the others. Thoughts?

Michael
- ------------------------------------------------
michael...@gmail.com
http://techrad.wordpress.com
http://mrcaron.wordpress.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFKZIPp5CEAr1NK/dQRAsD0AKCrN0KpxdbWYMJLwcL8OHbr2puW0wCfb/U4
usUY4LNLUBkt2ml7dgRcVjs=
=1VDW
-----END PGP SIGNATURE-----

[Alex Blewitt]

On 20 Jul 2009, at 15:49, Michael Caron wrote:

> I thought of tackling the issue of automated builds. I'm looking into
> the structure currently and figuring out a good route. I've used both
> Ant and Maven in the past. I'd prefer to use Maven because it's pretty
> easy to set up dependencies on things and just have them automatically
> included. I've got to familiarize myself with building eclipse plugins
> and how everything works together.

Building Eclipse is a challenge at the best of times :-) Actually,
there's some automated build support in Eclipse already (one can drive
the build from the feature, which is on the site) but it involves a
bit more setup than a corresponding Maven one would be. (The Eclipse
build is based on Ant builds, but knowing that doesn't actually help
much - there's a lot of cursing involved ...)

One downside of the Maven approach is that at runtime, the OSGi
bundles explicitly lock down visibility of packages. The JDT compiler
through the Eclipse build does error when you reach the wrong package,
so using a Maven build can result in a build that's successful and yet
not run at run-time.

I wrote a presentation for EclipseCon '06, which is probably a bit
dated by now, but it's available at

http://www.eclipsecon.org/2006/Sub.do?id=18

if you're interested ...

> Some questions that came up for me:
>
> 1. Using google's hosting service, is there a build farm that would
> run a build and serve nightly builds? If not, we could use one of our
> machines to do a nightly build and upload the resulting build to the
> code site wiki. Would be nice to have nightly builds going once build
> automation is complete.

There isn't any build farm machines, to the best of my knowledge. I've
been meaning to set up a virtual host on a Mac mini to do the work,
but I still haven't got around to that yet. But you're right, having a
nightly build and making the bits available is a good goal (provided
bandwith caps aren't a limitation).

> 2. First thoughts are to create a project to wrap all the build logic
> rather than put it in the root trunk folder. That particular project
> then could reference the others. Thoughts?

Could do. The Eclipse projects generally have a releng or build folder
which is used to drive the build. The example project above I ended up
hosting at SourceForge a long time ago (not done anything on it since
then, either) but used the feature to combine the releng feature in
one place.

http://rcpapps.cvs.sourceforge.net/viewvc/rcpapps/

For example, the 'base' feature involves checking out

http://rcpapps.cvs.sourceforge.net/viewvc/rcpapps/org.rcpapps.base.feature/releng/

and then running the build.xml there. However, you need to build with
an eclipse command (to host the ant runner in headless Eclipse, rather
than standalone ant).

There might be more up-to-date stuff than the instructions I wrote a
while ago - I've not set up any automated builds on 3.5 (or 3.4, for
that matter ...)

Alex

[Mike Caron]

Alex,

Can you explain the OSGi bit a little more thoroughly?

> One downside of the Maven approach is that at runtime, the OSGi  
> bundles explicitly lock down visibility of packages. The JDT compiler  
> through the Eclipse build does error when you reach the wrong package,  
> so using a Maven build can result in a build that's successful and yet  
> not run at run-time.

Are all Eclipse plugins compatible with OSGi? Being a n00b when it
comes to plugin development, I'm also new to OSGi. Are you suggesting
here that the Eclipse compiler is "OSGi-Safe" in that it protects you
from possible runtime failures, whereas the regular javac compiler
won't? I wonder if its possible to configure Maven to use the JDT
compier?

M

[Alex Blewitt]

On 21 Jul 2009, at 02:16, Mike Caron <michael...@gmail.com> wrote:

>
> Alex,
>
> Can you explain the OSGi bit a little more thoroughly?

I can probably direct you to some sites later ... This (virtual)
keyboard isn't made for long typing :-)

Basically, OSGi is a runtime technology that allows "bundles" to be
loaded. They're basically Jars with some more manifest info (see the
projects' manifest.mf for an example). It's quite like a web app
server (like Tomcat) that allows bundles to be stopped/started/updated.

One of the key elements in this puzzle is the ability to define, on a
per bundle basis, the packages you import/export. Only packages you
import can be used; similarly, clients can only use the packages you
export.

>
>> One downside of the Maven approach is that at runtime, the OSGi
>> bundles explicitly lock down visibility of packages. The JDT compiler
>> through the Eclipse build does error when you reach the wrong
>> package,
>> so using a Maven build can result in a build that's successful and
>> yet
>> not run at run-time.
>
> Are all Eclipse plugins compatible with OSGi?

In fact, Eclipse runs on an OSGi engine called Equinox. Every plugin
is a bundle (and has been since Eclipse 3.0 when the switch to OSGi
occurred). So not only are they compatible, every plugin must be a
valid bundle or else it will fail to work.

> Being a n00b when it
> comes to plugin development, I'm also new to OSGi. Are you suggesting
> here that the Eclipse compiler is "OSGi-Safe" in that it protects you
> from possible runtime failures, whereas the regular javac compiler
> won't? I wonder if its possible to configure Maven to use the JDT
> compier?

The javac (and build tools like Ant and Maven) just use a linear
classpath (I.e. you see everything on your dependencies). So it's
possible (accidentally) to depend on something in the build that you
can't see at runtime.

The plugin build process that Eclipse uses works with JDT and some
kind of compiler directive to make it clear which packages should be
visible, and to generate a compile error in the build if that is
violated.

Incidentally, there is a work-in-progress called "Tycho" which is
maven + osgi aware compiler, but I don't know what it's release status
is.

Either way, therefore, using the Eclipse build is likely to be less of
a headache to use, even if it takes a bit of getting up and running.

Alex

>
> M
> >

[Michael Caron]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the thoughts!

m

Michael
- ------------------------------------------------
michael...@gmail.com
http://techrad.wordpress.com
http://mrcaron.wordpress.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFKZZ9a5CEAr1NK/dQRAtE9AKCs/u2yW/hwetQNCbdZoJl+XOBbuACfdA96
9NQd0aY+KcoWs1ShjmpjZTQ=
=LbPY
-----END PGP SIGNATURE-----