Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dash-dev] SCM and Buckminster on Hudson

Hi all,

I also cannot get svn to work ("Could not retrieve feature.xml or
build.properties"). The org.eclipse.team.svn.pde.build feature is
installed correctly and I've already tried every thinkable combination
for the map entries but no luck...
localSourceCheckoutDir would be a very convenient workaround, but for
some reason when I point it to the hudson workspace, it only considers
the contained releng dir ({$WORKSPACE}/org.eclipse.jwt/releng/*) but not
the other directories containing the plugins ({$WORKSPACE}/*/*) although
https://bugs.eclipse.org/bugs/show_bug.cgi?id=252774 seems to indicate
that this should work.

Regards,
Chris


Am 09.07.2010 00:28, schrieb Nick Boldt:
That's pretty much how PDE works...

1. Hudson checks out your code into its job workspace.
2. When changes occur, it kicks a build for you.
3. Then the PDE build fetches sources from map file and you end up with
double the source on disk. Hella inefficient.

Alternative approach is to have the PDE build use local sources already
on disk as fetched by Hudson, rather than having the build provision the
sources for you. Athena does this using the localSourceCheckoutDir
variable; Bucky prolly has an analoguous approach.

There's also the non-PDE approach using Tycho+Maven, which simply builds
from the already-available sources in Hudson's workspace. Doesn't
support fetching from map file, only from a branch/tag (that is, it'll
build whatever Hudson's already fetched). Ideal for CVS, SVN, or Git
sources.

Nick

On 07/08/2010 02:38 PM, Miles Parker wrote:
Hi all,

I'm wondering how people are setting up SCM WRT Buckminster.

1. As I understand things it seems like best practices with
Buckminster would involve pulling everything from Version Control
through Buckminster?
2. Except that the releng site, i.e. rmap, cspec etc.. obviously need
to be there so they need to be bootstrapped into the Hudson workspace,
presumably through Hudson SCM.
3. And, you want any changes in covered code to trigger an SCM which
(I think?) means bringing all of that stuff over from SCM first.

2 and 3 sort of seem to conspire against 1, or am I missing something
here.

Also, I think this might have been asked before, but is there any way
to view the configurations of other projects to see how they've got
things setup?

cheers,

Miles_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dash-dev



Back to the top