Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re[2]: [higgins-dev] Build scripts for higgins components

Jim,

Thanks for your response and sorry for long delay.

I agree with you that it would be better to have global 'repository'
with the locations for both projects and remote libraries.

We'll try to implement such approach but I just wanted to be sure that
such approach may cover all needs of all higgins projects and it looks
like there are few problems. I hope nothing serious however.

One of the problem is that it looks like we need to be able to define (and
use) special case of remote library dependency where actual library jar is
located inside of archives (zip, tar, etc).

Another is that it looks like some projects may have more then one
locations where third party libraries must be located to allow build
the project.

I agree that it would be better either to auto-generate
dependencies.xml or use project's information directly.

Unfortunately, it appears impossible to use project's information
directly (from ant script especially) because dependency information
is separated among a lot of configuration files which may vary on type
of the project. I'm afraid that only Eclipse IDE may handle all of
them properly.

Fortunately, we could try to develop simple plugin for Eclipse IDE
(like eclipse2ant) which will be able to generate such dependency files
using information from IDE.


Valery

Thursday, July 19, 2007, 10:37:45 PM, you wrote:

>  
>  
> A suggestion:
>  
>  
>  
> Create a single 'global' file for dependency projects information,
> and another (or the same) for remote libs information such that a
> project's dependencies can refer to elements of the single 'global'
> file.  This way, each project's dependencies.xml file can be much
> smaller, have less duplication, and be less prone to maintenance
> if/when locations of things change.
>  
>  
>  
> I've attached examples.  The global_*.xml files could be located in
> some shared project (like org.eclipse.releng.auto).
>  
>  
>  
> If we do this, it may be easy to either auto-generate the
> dependencies.xml file, or just have the build tool use the project's
> .settings file (as the .settings file already has this
> information).  This way, the project maintainer doesn't have
> to update the project properties as well as another dependency file.
>  
>  
>  
> Jim 

>>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 7/19/07 8:41 AM >>>
> We're trying to change the process of automated builds for higgins
> components in order to simplify the process of adding new components
> to be build by the automated builds.

> We have almost completed build scripts designed for automated builds
> but we're trying to make them as smart as possible.

> Our new build scripts are requires a very small amount of
> information about the component to build but they also assumes that
> some addition information about the component is provided by the
> component itself.

> The information we need from the building component is its
> dependencies and where to get them. Current implementation reads a
> specific xml file from the component in order to find out project's
> dependencies (both projects and libs) and download them prior to run
> actual build.

> Attached is an example of such xml file with the project dependencies
> for *.cardspace.common project.

> Now we're trying to start running automated builds on build.eclipse.org
> using new approach for *.icard.* components but I believe that when we
> finish they should work for all other higgins components as well.

> When we finish I'm going to document on the higgins wiki how to add
> new component to the build process.

> Any questions and/or suggestions are welcome.




Back to the top