Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster dev » [buckminster-dev] There must be 50 ways to build your project... or leave your lover (was Re: Moving
[buckminster-dev] There must be 50 ways to build your project... or leave your lover (was Re: Moving [message #378916] Wed, 29 July 2009 16:45 Go to next message
Nick Boldt is currently offline Nick Boldt
Messages: 480
Registered: July 2009
Senior Member
> Also, just to clarify, by moving to Athena/Hudson (and away from
> modeling builds I assume), what does this change? The way we kick off
> builds? Anything else?

Athena + Hudson gives you:

* build-to-build interaction (build B can start if it sees there's a new
build A available) so you can get build cascades (eg., perfect for the
projects that depend on GMF)

* EMMA, FindBugs and other source/performance analysis tools

* Simple interface for having builds respond to changes in CVS/SVN and
build automatically (continuous integration)

* better web UI than the custom stuff in build/index.php, which is
nightmarish to update every time someone needs a new requirement added

* XML and plain text APIs to track what's happening w/ builds, including
being able to watch build status on iPod (David Green's Hudson Helper)

* plots showing how your junits are increasing/decreasing over time

* plots showing how long your build takes over time

* the Continuous Integration Game, to encourage people to write more
tests, fix more warnings, NOT break the build, etc.

* ability to build against p2 repos, extracting specific feature.groups
needed for compilation

> Is the idea to move all the modeling builds to this new method? Or is
> there good reasons to keep people using the existing infrastructure?

The Modeling build is deprecated, just as the EMFT build was deprecated
before that. It's been in maintenance mode since I started Athena last
June. So, yes, if you want new bells/whistles in the system, it's Athena
or bust.

> Buckminster,

Workspace & target platform provisioning (?)

> bucky build,

Uses Buckminster to create an aggregate p2 repo (Galileo)

> gan-o-matic,

Last year's Ganymede builder, which was either ant or buckminster, or a
combination (not sure)

> PDE/Build,

The core underneath all of the above and below

> Athena,

A facade over PDE/Build to make it easier to set up and to provide lots
of OOTB features. Requires Ant-Contrib.

Athena project configuration is a couple of properties files (for build,
test, promote), a generic build.xml, map files, and optional extra ant
scripts if desired. Runs in Hudson, in Eclipse, via commandline.

> modeling build

The precursor to Athena, but closely tied to Modeling projects (and GEF
+ PDT). Athena is WAY more generic and doesn't make the same
assumptions, plus has WAY less code to copy and maintain.

Modeling is a TON of xml files, properties files, shell scripts, and
maps. Runs commandline on linux ONLY.

Infrastructure to run builds is painful to maintain, as there's
duplicated information in several places, and devs must edit .php,
..properties, .xml, etc. It's multidisciplinary and tons of overhead for
basically the same output as Athena+Hudson

> Hudson,

Web UI for controlling and running continuous builds. Does nothing by
itself - needs plugins and job instructions for what to run (ant, shell,
python, groovy). Hudson :: dashboard, Athena :: fuel injector, PDE/Build
:: engine. Hudson can be used to run pure ant builds, pure PDE builds,
Athena builds, Buckminster builds... you name it, it'll run it.

> Build-In-A-Box,

No idea, unless you mean my "buildserver in a box" idea from a couple
EclipseCons ago, now replaced by Athena.

> and now b3.

http://wiki.eclipse.org/PDE/Incubator/b3/Proposal

There's also luntbuild, ant4eclipse, pluginbuilder, maven / m2eclipse,
and many others.

> I'm just
> trying to wrap my head around the similarities / differences, between
> these technologies and understand what we "should" be using in an ideal
> world.

Well, we all define "ideal" differently. Some insist that if there's no
ecore under the covers, it's non-ideal. Others, that everything must be
EPL. Me, I prefer something that's server-centric first (property files,
runs in continuous headless mode), IDE second (UI clickity-click, builds
on demand), but Athena is moving closer to bridging that gap.

As in all things, YMMV. :)

--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling & Dash Athena
Re: [buckminster-dev] There must be 50 ways to build your project... or leave your lover (was Re: Mo [message #407576 is a reply to message #378916] Thu, 30 July 2009 02:57 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
Hi all,
Here are some clarifications on Buckminster related things.

Nick Boldt wrote:
> Athena + Hudson gives you:
>
> * build-to-build interaction (build B can start if it sees there's a new
> build A available) so you can get build cascades (eg., perfect for the
> projects that depend on GMF)
>
> * EMMA, FindBugs and other source/performance analysis tools
>
> * Simple interface for having builds respond to changes in CVS/SVN and
> build automatically (continuous integration)
>
> * better web UI than the custom stuff in build/index.php, which is
> nightmarish to update every time someone needs a new requirement added
>
> * XML and plain text APIs to track what's happening w/ builds, including
> being able to watch build status on iPod (David Green's Hudson Helper)
>
> * plots showing how your junits are increasing/decreasing over time
>
> * plots showing how long your build takes over time
>
> * the Continuous Integration Game, to encourage people to write more
> tests, fix more warnings, NOT break the build, etc.
>
> * ability to build against p2 repos, extracting specific feature.groups
> needed for compilation
>
>> Is the idea to move all the modeling builds to this new method? Or is
>> there good reasons to keep people using the existing infrastructure?
>
> The Modeling build is deprecated, just as the EMFT build was deprecated
> before that. It's been in maintenance mode since I started Athena last
> June. So, yes, if you want new bells/whistles in the system, it's Athena
> or bust.
>
>> Buckminster,
>
> Workspace & target platform provisioning (?)
>
Yes, and in addition to that, Buckminster brings you out-of-the-box commands to:

* Build and export bundles and features. Either from your IDE or from the command line. The build that executes will be
exactly the same in both cases

* Create a P2 site from any feature. This includes pack200 and signing. Can run on any server (or from your IDE)

* Hudson integration (sharing a lot of the advantages that Nick mentioned for Athena above)

* And lots more. Take a look at our documentation:
http://www.eclipse.org/downloads/download.php?file=/tools/bu ckminster/doc/BuckyBook.pdf

>> bucky build,
>
> Uses Buckminster to create an aggregate p2 repo (Galileo)
>
The Galileo Builder is described here:

http://wiki.eclipse.org/Buckminster_Galileo_Builder

And we're working on it's successor:

http://wiki.eclipse.org/Getting_Started_With_Aggregator_(Buckminster)


>> gan-o-matic,
>
> Last year's Ganymede builder, which was either ant or buckminster, or a
> combination (not sure)
>
It was a mix of Ant, Buckminster, and the old Update Manager. May it rest in peace :-)

Kind Regards,
Thomas Hallgren
Re: [buckminster-dev] There must be 50 ways to build your project... or leave your lover (was Re: Mo [message #408335 is a reply to message #378916] Thu, 30 July 2009 02:57 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
Hi all,
Here are some clarifications on Buckminster related things.

Nick Boldt wrote:
> Athena + Hudson gives you:
>
> * build-to-build interaction (build B can start if it sees there's a new
> build A available) so you can get build cascades (eg., perfect for the
> projects that depend on GMF)
>
> * EMMA, FindBugs and other source/performance analysis tools
>
> * Simple interface for having builds respond to changes in CVS/SVN and
> build automatically (continuous integration)
>
> * better web UI than the custom stuff in build/index.php, which is
> nightmarish to update every time someone needs a new requirement added
>
> * XML and plain text APIs to track what's happening w/ builds, including
> being able to watch build status on iPod (David Green's Hudson Helper)
>
> * plots showing how your junits are increasing/decreasing over time
>
> * plots showing how long your build takes over time
>
> * the Continuous Integration Game, to encourage people to write more
> tests, fix more warnings, NOT break the build, etc.
>
> * ability to build against p2 repos, extracting specific feature.groups
> needed for compilation
>
>> Is the idea to move all the modeling builds to this new method? Or is
>> there good reasons to keep people using the existing infrastructure?
>
> The Modeling build is deprecated, just as the EMFT build was deprecated
> before that. It's been in maintenance mode since I started Athena last
> June. So, yes, if you want new bells/whistles in the system, it's Athena
> or bust.
>
>> Buckminster,
>
> Workspace & target platform provisioning (?)
>
Yes, and in addition to that, Buckminster brings you out-of-the-box commands to:

* Build and export bundles and features. Either from your IDE or from the command line. The build that executes will be
exactly the same in both cases

* Create a P2 site from any feature. This includes pack200 and signing. Can run on any server (or from your IDE)

* Hudson integration (sharing a lot of the advantages that Nick mentioned for Athena above)

* And lots more. Take a look at our documentation:
http://www.eclipse.org/downloads/download.php?file=/tools/bu ckminster/doc/BuckyBook.pdf

>> bucky build,
>
> Uses Buckminster to create an aggregate p2 repo (Galileo)
>
The Galileo Builder is described here:

http://wiki.eclipse.org/Buckminster_Galileo_Builder

And we're working on it's successor:

http://wiki.eclipse.org/Getting_Started_With_Aggregator_(Buckminster)


>> gan-o-matic,
>
> Last year's Ganymede builder, which was either ant or buckminster, or a
> combination (not sure)
>
It was a mix of Ant, Buckminster, and the old Update Manager. May it rest in peace :-)

Kind Regards,
Thomas Hallgren
Re: [dash-dev] Re: [buckminster-dev] There must be 50 ways to build your project... or leave your lo [message #433749 is a reply to message #407576] Thu, 30 July 2009 14:43 Go to previous messageGo to next message
Nick Boldt is currently offline Nick Boldt
Messages: 480
Registered: July 2009
Senior Member
There's definitely overlap, and I'm amazed to see just *how much* is now
in Buckminster than there was the first time I looked at it a couple
years ago. A venn diagram would be awesome -- looks like there'll be new
Venn diagram chart type in BIRT in a couple weeks.

http://wiki.eclipse.org/Adding_new_advanced_chart_types_in_B IRT

Does Bucky handle javadoc generation or running of headless UI tests and
collecting JUnit results in XML/HTML? Can it run tests on different
platforms from the one on which the build's run? Those pieces work in
Athena (except build on platform X, test on Y), but they're still rough.
If it's in Bucky already, reuse would certainly be better than reinvention.

I've also been asked to look at a better approach to target provisioning
prior to building. Today, we unpack an Eclipse SDK zip + any referenced
SDK/runtime/update zips, p2.director install from referenced update
sites / zips any required features, then start fetching sources and
orbit bundles. But requiring an SDK when you're running in Eclipse is
not the best scenario for RCP and equinox people, so we've started
discussion here:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=285048

There's also this bug re: building multiplatform jars (eg., using
Xulrunner):

https://bugs.eclipse.org/bugs/show_bug.cgi?id=284539

+1 to wiki page(s), referenced by blogs/tweets.

Ian Bull wrote:
> Nick and Thomas,
>
> Thanks so much for the answers / clarifications. I originally wondered
> about these things on GEF mailing list when trying to understanding all
> the issues related to building GEF.
>
> I am going to start a wiki page, and then likely a blog post, to try and
> present all this information (unless it already exists). I'm sure I'm
> not the only one who is interested in Eclipse Build and wondered about
> all the different technologies.
>
> It would be good to create some sort of venn diagram (or compatibility
> matrix) that shows the overlap between technologies (which technologies
> provide alternatives to one another) and how the different technologies
> complement each other. In light of the b3 proposal, it seems like a
> good time to reflect on what we have.
>
> Thanks again,
> Ian
>
> On Wed, Jul 29, 2009 at 11:57 PM, Thomas Hallgren <thomas@tada.se
> <mailto:thomas@tada.se>> wrote:
>
> Hi all,
> Here are some clarifications on Buckminster related things.
>
>
> Nick Boldt wrote:
>
> Athena + Hudson gives you:
>
> * build-to-build interaction (build B can start if it sees
> there's a new build A available) so you can get build cascades
> (eg., perfect for the projects that depend on GMF)
>
> * EMMA, FindBugs and other source/performance analysis tools
>
> * Simple interface for having builds respond to changes in
> CVS/SVN and build automatically (continuous integration)
>
> * better web UI than the custom stuff in build/index.php, which
> is nightmarish to update every time someone needs a new
> requirement added
>
> * XML and plain text APIs to track what's happening w/ builds,
> including being able to watch build status on iPod (David
> Green's Hudson Helper)
>
> * plots showing how your junits are increasing/decreasing over time
>
> * plots showing how long your build takes over time
>
> * the Continuous Integration Game, to encourage people to write
> more tests, fix more warnings, NOT break the build, etc.
>
> * ability to build against p2 repos, extracting specific
> feature.groups needed for compilation
>
> Is the idea to move all the modeling builds to this new
> method? Or is there good reasons to keep people using the
> existing infrastructure?
>
>
> The Modeling build is deprecated, just as the EMFT build was
> deprecated before that. It's been in maintenance mode since I
> started Athena last June. So, yes, if you want new
> bells/whistles in the system, it's Athena or bust.
>
> Buckminster,
>
>
> Workspace & target platform provisioning (?)
>
> Yes, and in addition to that, Buckminster brings you out-of-the-box
> commands to:
>
> * Build and export bundles and features. Either from your IDE or
> from the command line. The build that executes will be exactly the
> same in both cases
>
> * Create a P2 site from any feature. This includes pack200 and
> signing. Can run on any server (or from your IDE)
>
> * Hudson integration (sharing a lot of the advantages that Nick
> mentioned for Athena above)
>
> * And lots more. Take a look at our documentation:
> http://www.eclipse.org/downloads/download.php?file=/tools/bu ckminster/doc/BuckyBook.pdf
>
>
> bucky build,
>
>
> Uses Buckminster to create an aggregate p2 repo (Galileo)
>
> The Galileo Builder is described here:
>
> http://wiki.eclipse.org/Buckminster_Galileo_Builder
>
> And we're working on it's successor:
>
> http://wiki.eclipse.org/Getting_Started_With_Aggregator_(Buckminster)
>
>
>
> gan-o-matic,
>
>
> Last year's Ganymede builder, which was either ant or
> buckminster, or a combination (not sure)
>
> It was a mix of Ant, Buckminster, and the old Update Manager. May it
> rest in peace :-)
>
> Kind Regards,
> Thomas Hallgren


--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling & Dash Athena
Re: [dash-dev] Re: [buckminster-dev] There must be 50 ways to build your project... or leave your lo [message #435273 is a reply to message #433749] Thu, 30 July 2009 16:28 Go to previous messageGo to next message
Achim Demelt is currently offline Achim Demelt
Messages: 160
Registered: July 2009
Senior Member
Nick,

Comments below.

> Does Bucky handle javadoc generation

There's no support for javadoc generation out-of-the-box, at least none that
I am aware of. That said, with a few lines of XML and Ant code, it is
possible to hook javadoc generation into the build process. We are doing
this in our company's product build and include the resulting javadoc in doc
bundles that provide it as Eclipse Help content.

As a side note, we also pull our product's user guide content from our in-
house Confluence wiki, transform it into HTML, produce a toc.xml, and add
this to the Eclipse Help, too. All orchestrated by Buckminster on our build
server.

> or running of headless UI tests and
> collecting JUnit results in XML/HTML?

That's work in progress. We (speaking as a Buckminster committer now) are
working with the JDT and PDE teams to clean up their JUnit launching code
(see [1] and [2]). We'll then be able to run JUnit tests in Buckminster
headless. By reusing the regular JDT/PDE JUnit launchers running in a
regular (headless) workspace, we can more or less guarantee that these tests
do the same things that they're doing in your IDE. Same classpath, same
target platform, same environment, same everything. We'll actually simply
run a saved *.launch config.

> Can it run tests on different
> platforms from the one on which the build's run?

I think that'll be hard to do.

> Those pieces work in
> Athena (except build on platform X, test on Y), but they're still rough.
> If it's in Bucky already, reuse would certainly be better than
> reinvention.
>

That's actually one of the ideas behind Buckminster: reuse existing
technologies. The platform with JDT, PDE et al. does a very nice job of
building your stuff in your IDE. We're "just" calling it in headless mode,
thus producing the same build results without any extra configuration.
Unfortunately, some of these parts were not meant to be reused in that way
(again, see [1] and [2]).

> I've also been asked to look at a better approach to target provisioning
> prior to building. Today, we unpack an Eclipse SDK zip + any referenced
> SDK/runtime/update zips, p2.director install from referenced update
> sites / zips any required features, then start fetching sources and
> orbit bundles. But requiring an SDK when you're running in Eclipse is
> not the best scenario for RCP and equinox people

I'd say that Buckminster has a very good story for providing the target
platform, both in your IDE and your automated build: Specify the bundles and
features you're building against---version ranges ensure you'll get those
your want to have---and Bucky uses p2 to fetch it from wherever you tell it
to.

Regards,
Achim

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=278844
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=278845
Re: [pde-dev] Re: [dash-dev] Re: [buckminster-dev] There must be 50 ways to build your project... o [message #436145 is a reply to message #407576] Thu, 30 July 2009 18:16 Go to previous messageGo to next message
Ian Bull is currently offline Ian Bull
Messages: 145
Registered: July 2009
Senior Member
--0015175d09f09449a5046ff3a9af
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

> I've also been asked to look at a better approach to target provisioning
> prior to building. Today, we unpack an Eclipse SDK zip + any referenced
> SDK/runtime/update zips, p2.director install from referenced update sites /
> zips any required features, then start fetching sources and orbit bundles.
> But requiring an SDK when you're running in Eclipse is not the best scenario
> for RCP and equinox people, so we've started discussion here:
>
>
> This is a good example of build overlap. There is also some discussion on
PDE/Build about using a target definition file to provision your target
before building:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=266311

I don't know if it makes sense for Athena to first provision your target
(and then use the results of this as a baseRepoLocation / pluginPath), or if
PDE/Build should support this internally.

The fact that this conversation is spanning 3 lists shows a great deal of
overlap between these technologies.

cheers,
ian

--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

--0015175d09f09449a5046ff3a9af
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"b=
order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddin=
g-left: 1ex;">
I&#39;ve also been asked to look at a better approach to target provisionin=
g prior to building. Today, we unpack an Eclipse SDK zip + any referenced S=
DK/runtime/update zips, p2.director install from referenced update sites / =
zips any required features, then start fetching sources and orbit bundles. =
But requiring an SDK when you&#39;re running in Eclipse is not the best sce=
nario for RCP and equinox people, so we&#39;ve started discussion here:<br>

<br><br></blockquote></div>This is a good example of build overlap.=A0 Ther=
e is also some discussion on PDE/Build about using a target definition file=
to provision your target before building:<br><br><a href=3D"https://bugs.e=
clipse.org/bugs/show_bug.cgi?id=3D266311">https://bugs.eclipse.org/bugs/sho=
w_bug.cgi?id=3D266311</a><br>
<br>I don&#39;t know if it makes sense for Athena to first provision your t=
arget (and then use the results of this as a baseRepoLocation / pluginPath)=
, or if PDE/Build should support this internally.=A0 <br><br>The fact that =
this conversation is spanning 3 lists shows a great deal of overlap between=
these technologies.<br>
<br>cheers,<br>ian<br clear=3D"all"><br>-- <br>R. Ian Bull | EclipseSource =
Victoria | +1 250 477 7484<br><a href=3D"http://eclipsesource.com">http://e=
clipsesource.com</a> | <a href=3D"http://twitter.com/eclipsesource">http://=
twitter.com/eclipsesource</a><br>


--0015175d09f09449a5046ff3a9af--
Re: [pde-dev] Re: [dash-dev] Re: [buckminster-dev] There must be 50 ways to build your project... or [message #440173 is a reply to message #436145] Fri, 31 July 2009 03:40 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
Ian Bull wrote:
> This is a good example of build overlap. There is also some discussion
> on PDE/Build about using a target definition file to provision your
> target before building:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=266311
>
Buckminster can manage target platform definitions from the command line. The only problem with such
a definition is that it is fairly static. The things in it cannot be determined based on a
resolution that is controlled from the top down. As a result, you often get a target platform that
contains far to much stuff and only a fragment of it will end up in your final product.

To remedy this, Buckminster is capable of populating a "Directory" location in a target platform
definition. The Buckminster resolver will determine what's needed (cannot use the planner since it
cannot manage multi platform configurations) and then we call on the P2 engine to populate the
target platform using it's collect phase.

> I don't know if it makes sense for Athena to first provision your target
> (and then use the results of this as a baseRepoLocation / pluginPath),
> or if PDE/Build should support this internally.
>
> The fact that this conversation is spanning 3 lists shows a great deal
> of overlap between these technologies.
>
Yes, b3 is badly needed. I suggest that we continue this discussion on the cross project list until
the b3 list has been set up.


Regards,
Thomas Hallgren
[buckminster-dev] jar signing book.pdf corrections [message #468370 is a reply to message #436145] Wed, 05 August 2009 05:57 Go to previous message
Eclipse User
Originally posted by: dieter.cailliau.barco.com

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA15B3.13D679E1
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I've created a keystore like in the pdf: the books says -genkeypair but =
that didn't work: i think it should be -genkey
The jar-signing then fails except if you add this property in the =
properties-file: local.keystore.passphrase <thesamepassword>




DISCLAIMER:
Unless indicated otherwise, the information contained in this message is =
privileged and confidential, and is intended only for the use of the =
addressee(s) named above and others who have been specifically =
authorized to receive it. If you are not the intended recipient, you are =
hereby notified that any dissemination, distribution or copying of this =
message and/or attachments is strictly prohibited. The company accepts =
no liability for any damage caused by any virus transmitted by this =
email. Furthermore, the company does not warrant a proper and complete =
transmission of this information, nor does it accept liability for any =
delays. If you have received this message in error, please contact the =
sender and delete the message. Thank you.

------_=_NextPart_001_01CA15B3.13D679E1
Content-Type: application/ms-tnef;
name="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IgIJAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcA GAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAIQAAAGphciBz aWduaW5nIGJvb2su
cGRmIGNvcnJlY3Rpb25zAEoMAQWAAwAOAAAA2QcIAAUACwA5AAAAAwA0AQEg gAMADgAAANkHCAAF
AAsAOQABAAMANQEBCYABACEAAAAxMjVGNkJDRDk2MjFDMDQxOTZCNjk4N0E4 MUQyMEYxMgAPBwED
kAYArAsAADoAAAADACYAAAAAAAMANgAAAAAAQAA5AOF51hOzFcoBHgA9AAEA AAABAAAAAAAAAAIB
RwABAAAAMwAAAGM9QkU7YT1SVFQ7cD1CQVJDTztsPUtORE1FWDAxLTA5MDgw NTA5NTcwMFotMTA0
NDc0AAAeAEkAAQAAAM8AAABSZTogW3BkZS1kZXZdIFJlOiBbZGFzaC1kZXZd IFJlOiBbYnVja21p
bnN0ZXItZGV2XSBUaGVyZSBtdXN0IGJlNTAgd2F5cyB0byBidWlsZCB5b3Vy IHByb2plY3QuLi4g
b3IgbGVhdmUgeW91ciBsb3ZlciAod2FzIFJlOiBNb3ZpbmdHRUZ0byBBdGhl bmEgKHdhcyBSZTog
W2dlZi1kZXZdIFJlOiBMYXN0IGJ1aWxkIG9uIGVtZnQuZWNsaXBzZS5vcmcg dG9kYXkpKQAAQABO
AICSDyGyEcoBHgBaAAEAAAAkAAAAYnVja21pbnN0ZXItZGV2LWJvdW5jZXNA ZWNsaXBzZS5vcmcA
AgFbAAEAAABlAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAYnVja21pbnN0 ZXItZGV2LWJvdW5j
ZXNAZWNsaXBzZS5vcmcAU01UUABidWNrbWluc3Rlci1kZXYtYm91bmNlc0Bl Y2xpcHNlLm9yZwAA
AAACAVwAAQAAACkAAABTTVRQOkJVQ0tNSU5TVEVSLURFVi1CT1VOQ0VTQEVD TElQU0UuT1JHAAAA
AB4AXQABAAAAEAAAAFRob21hcyBIYWxsZ3JlbgACAV4AAQAAADwAAAAAAAAA gSsfpL6jEBmdbgDd
AQ9UAgAAAABUaG9tYXMgSGFsbGdyZW4AU01UUAB0aG9tYXNAdGFkYS5zZQAC AV8AAQAAABQAAABT
TVRQOlRIT01BU0BUQURBLlNFAB4AZgABAAAABQAAAFNNVFAAAAAAHgBnAAEA AAAkAAAAYnVja21p
bnN0ZXItZGV2LWJvdW5jZXNAZWNsaXBzZS5vcmcAHgBoAAEAAAAFAAAAU01U UAAAAAAeAGkAAQAA
AA8AAAB0aG9tYXNAdGFkYS5zZQAAHgBwAAEAAAAhAAAAamFyIHNpZ25pbmcg Ym9vay5wZGYgY29y
cmVjdGlvbnMAAAAAAgFxAAEAAAAbAAAAAcoRsjPTM/1sAonmQT+yFsNAKuv4 yQD/MAHpAB4AcwAB
AAAAaAAAAENyb3NzIHByb2plY3QgaXNzdWVzOyBFY2xpcHNlIFBERSBnZW5l cmFsIGRldmVsb3Bl
cnMgbGlzdC47IERhdmlkIENhcnZlcjsgVG9vbHMgZm9yIENvbW1pdHRlciBD b21tdW5pdHkAHgB0
AAEAAAAiAAAAQnVja21pbnN0ZXIgZGV2ZWxvcGVyIGRpc2N1c3Npb25zAAAA HgAaDAEAAAARAAAA
Q2FpbGxpYXUsIERpZXRlcgAAAAAeAB0OAQAAACEAAABqYXIgc2lnbmluZyBi b29rLnBkZiBjb3Jy
ZWN0aW9ucwAAAAACAQkQAQAAAGwBAABoAQAADQIAAExaRnU8yyEfAwAKAHJj cGcxMjXiMgNDdGV4
BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQy BgAGwxEl9jMERhO3
MBIsETMI7wn3tjsYHw4wNREiDGBjAFAzCwkBZDM2FlALpiBJkCd2ZSAFAGVh DrAAZCBhIGtleXOm
dAWwHSBsaR3gIAuACCB0aB0gcGRmOpMe4wbgb2sEIHNhHgC4IC1nCfAd4Qqw aQXAHGJ1BUAe8B1w
IGRpqGRuJwVAdwWwax9gNmke4QuAax6wBUBzaPUIYGwdoGIdICB1CqIKgKpU HwFqCsAtAJBnAwCs
bmce4gOgZgtwbAQgmQ7AY2UFMQaQIHkIYF0dsGQdoCKxBCBwA2BwOQSQdHke tyfkCJBzLVpmAxBl
H2AXsGMHQC6NHeYuCrAEEHBocirgfR0gPB7xICAHgCrSIjFkFj4kVCyafS3A HgA1EAEAAAA+AAAA
PDAyOEFFOEE3QzA0RUUxNDg4OUJFOTlFNTQ1MEJFMzJEMDM2RUJBOTJAa25k bWV4MDEuYmFyY28u
Y29tPgAAAB4AORABAAAAPgIAADxPRjBFNzFDQkFDLjM2REMzRTIwLU9OODUy NTc1RkQuMDA0NEY5
RDItODUyNTc1RkQuMDA0NkY2RTdAY2EuaWJtLmNvbT4JPDJkNzM5MTMxMDkw NzI5MTAwNXU3OWY5
MThkazljNTg0NGQwYjY5ZWY5NTRAbWFpbC5nbWFpbC5jb20+CTw0QTcwODU3 NS45MDMwMzA0QGdt
YWlsLmNvbT4JPDJkNzM5MTMxMDkwNzI5MTA0Nm0xNmE2NmQ1N3FiOWEzMTVi NjY0YmY1MmMwQG1h
aWwuZ21haWwuY29tPgk8NEE3MDhDMTAuMTA5MDQwNEBnbWFpbC5jb20+CTwy ZDczOTEzMTA5MDcy
OTEyMTBrNDM5NDMwMzl4MTY4N2Y0ZGY1MmM0NTIwNEBtYWlsLmdtYWlsLmNv bT4JPG1haWxtYW4u
My4xMjQ4OTAwMzE4LjIzODYxOC5idWNrbWluc3Rlci1kZXZAZWNsaXBzZS5v cmc+CTw0QTcxNDQ1
Ny40MDMwOTAyQHRhZGEuc2U+CTwyZDczOTEzMTA5MDczMDA3NTFsNTQ3MjA2 N2JrYzg3MmNlNmU2
YWNjOTEyOUBtYWlsLmdtYWlsLmNvbT4JPDRBNzFFOUQzLjgwNjA1MDhAZ21h aWwuY29tPiA8bWFp
bG1hbi40LjEyNDg5OTIyMjUuOTU0MTIuYnVja21pbnN0ZXItZGV2QGVjbGlw c2Uub3JnPiA8NEE3
MjlGRDkuNzAzMDkwMkB0YWRhLnNlPgAAAB4ARxABAAAADwAAAG1lc3NhZ2Uv cmZjODIyAAALAPIQ
AQAAAB8A8xABAAAASgAAAGoAYQByACAAcwBpAGcAbgBpAG4AZwAgAGIAbwBv AGsALgBwAGQAZgAg
AGMAbwByAHIAZQBjAHQAaQBvAG4AcwAuAEUATQBMAAAAAAALAPYQAAAAAEAA BzAPa9nzrhXKAUAA
CDD7oN0TsxXKAQMA3j+vbwAAAwDxPwkEAAAeAPg/AQAAABEAAABDYWlsbGlh dSwgRGlldGVyAAAA
AAIB+T8BAAAARAAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1C QVJDTy9PVT1BRzAw
MS9DTj1SRUNJUElFTlRTL0NOPURJRUMAHgD6PwEAAAAVAAAAU3lzdGVtIEFk bWluaXN0cmF0b3IA
AAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4A AAADAP0/5AQAAAMA
GUAAAAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAAHgAwQAEAAAAFAAAARElF QwAAAAAeADFAAQAA
AAUAAABESUVDAAAAAB4AMkABAAAAJAAAAGJ1Y2ttaW5zdGVyLWRldi1ib3Vu Y2VzQGVjbGlwc2Uu
b3JnAB4AM0ABAAAADwAAAHRob21hc0B0YWRhLnNlAAAeADhAAQAAAAUAAABE SUVDAAAAAB4AOUAB
AAAAAgAAAC4AAAADAHZA/////wsAKQAAAAAACwAjAAAAAAADAAYQG2lycwMA BxDMAAAAAwAQEAAA
AAADABEQAQAAAB4ACBABAAAAZQAAAElWRUNSRUFURURBS0VZU1RPUkVMSUtF SU5USEVQREY6VEhF
Qk9PS1NTQVlTLUdFTktFWVBBSVJCVVRUSEFURElETlRXT1JLOklUSElOS0lU U0hPVUxEQkUtR0VO
S0VZVEhFSkEAAAAAAgF/AAEAAAA+AAAAPDAyOEFFOEE3QzA0RUUxNDg4OUJF OTlFNTQ1MEJFMzJE
MDM2RUJBOTJAa25kbWV4MDEuYmFyY28uY29tPgAAAFnz

------_=_NextPart_001_01CA15B3.13D679E1--
Previous Topic:[buckminster-dev] how to have junit available in headless buckminster
Next Topic:[buckminster-dev] create.eclipse.jnlp.product issues
Goto Forum:
  


Current Time: Fri Aug 29 01:42:15 EDT 2014

Powered by FUDForum. Page generated in 0.16349 seconds