"Handle" == can use p2 sites as dependencies?
"Handle" == can create p2 sites?
Just like that old SNL sketch about a floor wax / dessert topping...
it's both!
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 builds, jboss.org builds, and even a couple
sf.net builds. As long as the output desired is an update site/zip, then
yes, you're golden.
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.
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@eclipse.org
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@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
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@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
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@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
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@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
