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.