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 
Tycho requires an explicit list of projects to build. For example:

https://pi4soa.svn.sourceforge.net/svnroot/pi4soa/trunk/pom.xml
(flat)

or

http://anonsvn.jboss.org/repos/tdesigner/trunk/pom.xml
(nested)
But as I said before... if Buckminster is working for you, use that. Because it's built on top of PDE, it supports more of what PDE does. Tycho is attempting to bring p2 and osgi to the maven world, so a lot is being recreated. As such, it may not be as complete as Buckminster. (I'm not an expert - I just know what I've tried.) 

--
You can refer to ${WORKSPACE} (resolves to local path within a build job), or http:// paths to jobs' workspaces/archives.
Or, if you're only building on build.eclipse.org (Master), then you can use this path to get at other jobs: 

/opt/users/hudsonbuild/.hudson/jobs/<jobname>
Because build.eclipse.org knows that http://build.eclipse.org is local, it serves content from the local DNS and downloads are fast; as well, if your upstream stuff gets built on a slave instead of the master, you're not broken because the path or server changes. 

N

On 07/09/2010 07:03 PM, Miles Parker wrote:


On Jul 9, 2010, at 3:32 PM, Nick Boldt wrote:


"Handle" == can use p2 sites as dependencies?


Yeah, they need to update this: "We plan to support Maven repositories,
P2 repositories and update sites, although level of support will likely
vary."


Just like that old SNL sketch about a floor wax / dessert topping...
it's both!


I like the one where a plant manager leaves these two guys sitting in
the control room with the last word..

"remember: you can never put too much water in the cooling tank of a
nuclear reactor"

Sometimes I feel like that's what I'm reading going through build docs.

"remember: you can never provide version dependencies that are
underspecified"



What do you consider a complex layout? Pascal can (nearly?) build all
of equinox & p2 with Tycho. Is that complex enough?

I've used it for eclipse.org <http://eclipse.org> builds, jboss.org
<http://jboss.org> builds, and even a couple sf.net <http://sf.net>
builds. As long as the output desired is an update site/zip, then yes,
you're golden.


Actually, I need product builds which is why I went to buckminster from
the straight Athena solution. Athena was working just fine for me.



Personally, I prefer a nested layout w/ trunk/plugins/*,
trunk/features/*, trunk/tests/*, etc., but I just set up pi4soa to
build w/ Tycho using a flat layout of trunk/*. If you go nested, I
have an Ant script which can generate you pom.xml files from the tree
given you already have feature.xml and manifest.mf files.


That's cool. All of the info is there, so there isn't any reason that
you couldn't deduce it. If you look at the EMF project trees, like mine
they often look something like:

o.e.amp/o.e.amp/doc/o.e.doc
o.e.amp/o.e.amp.amf/plugins/o.e.amp.amf.core
..
o.e.amp/o.e.amp.amf/features/o.e.amp.amf

etc..

I actually just did regexp in rmap for that like:


<searchPath name=/"amp.plugins"/>
<provider componentTypes=/"osgi.bundle"/ readerType=/"cvs"/ source=/"true"/>
<uri
format=/":pserver:anonymous@xxxxxxxxxxxxxxx:/cvsroot/modeling,org.eclipse.amp/{0}/plugins/{1}"/>
<bc:replace>
<bc:propertyRef key=/"buckminster.component"/ />
<bc:match pattern=/"org\.eclipse\.amp\.agf.*"/
replacement=/"org.eclipse.amp.agf"/ />
<bc:match pattern=/"org\.eclipse\.amp\.axf.*"/
replacement=/"org.eclipse.amp.axf"/ />
<bc:match pattern=/"org\.eclipse\.amp\.amf.*"/
replacement=/"org.eclipse.amp.amf"/ />
<bc:match pattern=/"org\.eclipse\.amp\.escape.*"/
replacement=/"org.eclipse.amp.escape"/ />
<bc:match pattern=/"org\.eclipse\.amp.*"/ replacement=/"org.eclipse.amp"/ />
<bc:match pattern=/"org\.ascape.*"/ replacement=/"org.ascape"/ />
<bc:match pattern=/"org\.eclipse\.emf\.java"/
replacement=/"dependencies"/ />
</bc:replace>
<bc:propertyRef key=/"buckminster.component"/ />
</uri>
</provider>
</searchPath>

Of course I could have gotten rid of a lot of the lines with some more
matching but there are limits to this sort of thing!

Anyway, I've got so much in the way of sunk costs here and I've run way
over the time I had for this already so I've got to hope I can get this
working today or I'll just resort to doing my product

BTW, dumb question, but is there a variable for hudson root? I can't
find it and I don't want to use workspace relative roots to get to
artifacts from other projects. Maybe there is a better way to do that
anyway..

cheers.




Aside...

Using Tycho/Maven, you can also publish in maven2 repo format (if you
prefer to resolve deps from m2 repos using m2eclipse than with p2/PDE
from p2 sites when writing your code).

Meanwhile, on the buckminster side of the fence, I saw Kenn Hussey
demo generating a p2/m2 hybrid site with the b2 aggregator @ last
week's Eclipse Demo Camp Toronto. So, both technologies can handle
creation of p2 and m2 repos.

On 07/09/2010 04:11 PM, Miles Parker wrote:


Hmmm... I've been killing myself on Bucky for the last week. Does
Tycho handle P2 sites yet? Their webpage seems to indicate no, but
you seem to be saying yes. Can it deal with complex project layouts ok?

On Jul 9, 2010, at 12:21 PM, Nick Boldt wrote:


I am *not* *not* *not* going to get into Maven now, lol.


That was my attitude for a year as I fought w/ Athena+PDE. Having
drunk the Tycho kool-aid (it's come a long way since last year) I
can say I prefer it to Athena's approach to simplifying PDE. I'm
still not very well versed in Buckminster to really comment on it;
however, I did get annoyed recently by p2 issues using the B3
Aggregator (formerly the Buckminster Aggregator), and found that
Tycho can do with negligible code what Bucky/b3 requires a ton of
Ant script.

But with all things, YMMV, and what works for you is the best
solution, regardless of bandwagons, cheerleaders, or executive
decrees. At the end of the day, it's what gets the job done that
matters.


cheers,

Miles



Nick


On Jul 8, 2010, at 3:28 PM, Nick Boldt wrote:


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 <mailto:dash-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dash-dev


--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling& Dash Athena
_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dash-dev


_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dash-dev


--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling& Dash Athena
_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dash-dev


_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dash-dev


--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling& Dash Athena
_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dash-dev


_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dash-dev


--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling & Dash Athena
_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dash-dev




_______________________________________________
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

Back to the top