[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dash-dev] Local source
|
Without symlinks I can't see how that structure would work for a local
build from Athena. Athena expects to find something like:
rootdir\
plugins\
features\
tests\
So you'll either need to dump the two trunk folders to disk and symlink
the bejibblies out of it, or carefully checkout into the above
structure. Either way, it's ugly.
I think it also works w/ a workspace-style folder, where everything is
in a single root folder - this simply mirrors your own Eclipse workspace
structure and is therefore dead simple to set up (if you've already
checked everything out or have a .psf or .map file):
workspace\
org.foo.plugin
org.foo.core
org.foo.ui
org.foo.whatever.feature
org.foo.tests
In that case you MUST ensure that the folder name == the artifact name;
you cannot have org.foo.whatever be the ID of a feature in a dir called
org.foo.whatever.feature. Path on disk MUST be the same as the metadata
in the manifest.mf or feature.xml.
---
Alternatively...
You would probably benefit from Tycho here. Same great PDE/osgi taste,
but wrapped up in a crunchy candy pom.xml shell.
Added bonus to Tycho over Athena is that you aren't stuck building from
a SINGLE ALL-IN-ONE FEATURE. In fact, you can omit features entirely if
you have a pom.xml that lists all the plugins you want to build. Dir
structure is irrelevant provided that the pom.xml can reference its
children via relative path on disk.
Here's a standalone example of how to build Xulrunner 1.9.2 using Tycho.
http://anonsvn.jboss.org/repos/jbosstools/trunk/xulrunner/
Here's the parent-pom.xml that defines how to run tests and what p2
repos to source for dependencies:
http://anonsvn.jboss.org/repos/jbosstools/trunk/parent-pom.xml
And here's the target platform we use for building all of JBoss Tools
(including this component):
http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/e36-wtp32.target
You don't need to define a target platform for your build; you can
instead just provide update sites in the parent-pom.xml and let Tycho
figure out what you need from that. The target platform is a way of
overriding that discovery mechanism to tell the build EXACTLY what you
want as input.
In the above example you'll also see how to generate an update site from
nothing more than a pom.xml and site.xml. Very simple. (If you want a
more complex example involving the aggregation of multiple update sites
and the addition of associate sites, I have that here:
http://anonsvn.jboss.org/repos/jbosstools/trunk/build/aggregate/
On 07/20/2010 11:54 AM, Trip Gilman wrote:
I’m trying to use the local source feature to reduce the time it takes
to build the VTP but I’m having problems. The VTP repository structure
is a strange one:
Repository root
Component 1
trunk
features
plugins
branches
branch 1
features
plugins
Component 2
trunk
features
plugins
branches
...
Right now I’m interested in building a specific branch that is in each
component group. How should I set up the checkout portion of the job
configuration and what should I use for the local source directory?
Also, if you use the local source option, it appears that the features
and plugins are gathered from what was checked out instead of the map
files provided? I’m not sure I understand how each of these items
interact with each other.
Trip
_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dash-dev
--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling & Dash Athena
