What if the build machine had a location
where the 3rd party libraries were previously downloaded. A build
property (OS envirionment variable?) would be used to point to this
location. This would allow the build process to locally fetch the
libraries needed for the build
This approach would also work off-line as well as within
each developer's workstations.
Our linxu build machine has a user "releng".
Within the "home" for "releng" there is a folder
"download". The path to this location is
"/home/releng/download". An environment variable
CORONA_DOWNLOAD could be set to this location. This would allow the build
process to find all the 3rd party libraries that are not stored within Corona's CVS repository.
Other users on the linux build server could set
CORONA_DOWNLOAD to point to "/home/releng/download" or to their own
download location. This will allow them to customize what libraries they
use to build their own version of Corona.
What do you think of this approach?
I don’t think that
downloading some lib’s “Manually” is a good idea… we
can do it as it’s already done in a build process, that if something
(derby) is already downloaded that it won’t be downloaded second time.
Piotr
From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Kaczmarek, Pawel
Sent: Thursday, October 12, 2006
11:43 AM
To: Corona
development
Subject: RE: [corona-dev] Custom
Build Targets
Adding post-fetch behavior to
customTargets.xml seems the best solution. There are tree operations required:
1. get libraries
2. unzip
3. copy to plugin lib dir
I think that the first step should
be done "manually" as a part of preparing build infrastructure.
Otherwise we need to download 10MB Derby
libs each time a build is run.
Derby zip needs to be placed in build directory. We can get the
libraries using ftp or wget, but I think it is not necessary.
I'll add unzip and copy ant tasks
to post-fetch of customTargets.xml. Post-fetch is run after plugins are
downloaded but before any compilation.
Is Derby the only case now? Can you give me the
version required and plugin name?
Pawel
From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of O'Flynn, Dennis
Sent: Wednesday, October 11, 2006
6:31 PM
To: Corona
development
Subject: RE: [corona-dev] Custom
Build Targets
Pawel – can you please provide some
guidance on this?
This is the problem I would like
solved…
Corona provides a plugin that is dependent upon 3rd party
libraries. While waiting for IP approval of the libraries, the build
process should be able to proceed by fetching those libraries from a
non-Eclipse location. This will allow the plugin to be built, tested and
used while waiting for approval of the IP request
Specific
example: Plugin for Apache Derby
Corona will use Apache Derby as a repository used by its exemplary
implementation. Initial approval for Derby was given by the PMC and is pending by
the EMO.
I would like to commit the Corona Derby plugin to our CVS
repository, without the Derby
libraries. This will require the build process to fetch the appropriate
libraries and populate the plugin’s “lib” folder so that the
plugin can be built properly.
I have
briefly investigated both “customTargets.xml” and
“customBuildCallbacks.xml”. It appears that “customTargets.xml”
is probably what is needed.
From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of O'Flynn, Dennis
Sent: Tuesday, October 10, 2006
4:15 PM
To: Corona
development
Subject: [corona-dev] Custom Build
Targets
Pawel,
There are at least two ways to provide some custom build
steps: customerTargets.xml and customBuildCallbacks.xml. We may need to
use one (or both?) of these to build some plugins that require 3rd
party libraries that are pending IP approval.
Can you recommend how this should be handled to ensure
compatibility with Corona’s
build process.
Thanks,
-Dennis
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.