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 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.
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:anonym...@dev.eclipse.org:/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@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
_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
