Repository Workspace loading
Im just wondering if there is a way to hook in to the "load" process of a repository workspace.
We use binary artefacts (jars, wars) from our buildsystem when creating a workspace because of performance problems when loading a workspace with hundreds of projects.
the question is really about an extension point for loading a repository workspace into our local workspace.
regards,
Hampus
We use binary artefacts (jars, wars) from our buildsystem when creating a workspace because of performance problems when loading a workspace with hundreds of projects.
the question is really about an extension point for loading a repository workspace into our local workspace.
regards,
Hampus
5 answers
Hi Hampus,
On the Jazz project we handle this by using the Eclipse build hooks. We have a stream containing our binary prerequisites (in the form of large zip files). Each project in that stream has a builder that extracts the contents appropriately. After the project is loaded, and autobuild kicks in, we get the properly extracted content.
hth
e
On the Jazz project we handle this by using the Eclipse build hooks. We have a stream containing our binary prerequisites (in the form of large zip files). Each project in that stream has a builder that extracts the contents appropriately. After the project is loaded, and autobuild kicks in, we get the properly extracted content.
hth
e
Ok, we use a homegrown "SCM" system consisting of CVS and a bunch of XML files stored in CVS.
The XML files represent "configurations" and contains any number of artefacts which the user can fetch either as binaries or as Eclipse projects through a plugin weve developed internally.
Our buildsystem uses the same XML files to build configurations and results in a bunch of jars, wars and one ear which then are published to our HTTP content repository (we use Apache Ivy for this).
The Eclipse user can then fetch the main bulk of a configuration from the content repository as binaries instead of Eclipse projects (one configuration typically contain 400+ jars or wars) to build a workspace. He/she normally need 5-6 artefacts as Eclipse projects.
The plugin weve developed helps the Eclipse user to do this so there is no need to manually download all these binaries from the content repository.
I suppose what Im asking for is a way of listing the components that will be fetched by the "Load Repository Workspace" action and then let the user adjust properties (or somekind of metadata) on those components which then can be read by an extension which intercepts the loading of these components based on some metadata criteria.
Am I making any sense at all? :shock:
regards
Hampus
The XML files represent "configurations" and contains any number of artefacts which the user can fetch either as binaries or as Eclipse projects through a plugin weve developed internally.
Our buildsystem uses the same XML files to build configurations and results in a bunch of jars, wars and one ear which then are published to our HTTP content repository (we use Apache Ivy for this).
The Eclipse user can then fetch the main bulk of a configuration from the content repository as binaries instead of Eclipse projects (one configuration typically contain 400+ jars or wars) to build a workspace. He/she normally need 5-6 artefacts as Eclipse projects.
The plugin weve developed helps the Eclipse user to do this so there is no need to manually download all these binaries from the content repository.
I suppose what Im asking for is a way of listing the components that will be fetched by the "Load Repository Workspace" action and then let the user adjust properties (or somekind of metadata) on those components which then can be read by an extension which intercepts the loading of these components based on some metadata criteria.
Am I making any sense at all? :shock:
regards
Hampus
> Am I making any sense at all? :shock:
In fact, most larger projects using CVS/SVN have their own homegrown way of defining configurations and input to their builds. In Eclipse we have map files which contain lists of plug-ins and features with tag names and directory in the repo where to find them. Then we have homegrown tools to update and read the files.
In Jazz SCM, we use components to split up the source files into logical units that are developed together. A developer or team will typically configure their stream with the components they depend on or actively develop. So we've made the move from map files to a combination of components and baselines. What we haven't done as much is to consider loading binaries and setting-up the target platform automatically. We don't need map files anymore.
There are two parts to your tooling, the first is the developer IDE setup and the second the build setup. For the IDE setup you could use components to split the source, then create component(s) with the jars/wars. Teams add the components they need to develop into their team streams and on load, you can either script that during build the jars get published or set as the target platform or you can listen to the load events sent by the SCM component. Ok, so I've never tried this myself, but in theory it sounds doable.
In the builds, it may be easier. After things are fetched from the repository, you can run a script to expand/install the jars/war before compiling and running tests.
It doesn't sound all that crazy, and very doable.
Jean-Michel Lemieux
Jazz Source Control Team
In fact, most larger projects using CVS/SVN have their own homegrown way of defining configurations and input to their builds. In Eclipse we have map files which contain lists of plug-ins and features with tag names and directory in the repo where to find them. Then we have homegrown tools to update and read the files.
In Jazz SCM, we use components to split up the source files into logical units that are developed together. A developer or team will typically configure their stream with the components they depend on or actively develop. So we've made the move from map files to a combination of components and baselines. What we haven't done as much is to consider loading binaries and setting-up the target platform automatically. We don't need map files anymore.
There are two parts to your tooling, the first is the developer IDE setup and the second the build setup. For the IDE setup you could use components to split the source, then create component(s) with the jars/wars. Teams add the components they need to develop into their team streams and on load, you can either script that during build the jars get published or set as the target platform or you can listen to the load events sent by the SCM component. Ok, so I've never tried this myself, but in theory it sounds doable.
In the builds, it may be easier. After things are fetched from the repository, you can run a script to expand/install the jars/war before compiling and running tests.
It doesn't sound all that crazy, and very doable.
Jean-Michel Lemieux
Jazz Source Control Team