Re: [orbit-dev] customCallbacks: A small twist on including pre-built bu

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

This is an interesting approach.  It
would be good to see (as you mention) how the body of the that task can
be updated to download the latest copy of the required bundles etc.  Not
to push a particular technology but what I have been arguing for is something
repo independent like OBR.  Here the OBR client could be used to pull
content from update sites, download servers, Maven repos, ...  Keep
in mind also that some sources might contain packed bundles that you would
want ot use instead...

BTW, I think custom callbacks came after
the book was done but my sense of time sucks...

Jeff


David Williams wrote on 01/05/2007 02:27:05 AM:

> 
> Jeff has recently mentioned on this list the technique of having your
own "
> getBaseComponents" target to pull in pre-built components, but
> lucky or not lucky, right before he posted his note, I had just 
> spent three days discovering another way, that I think I might like
> better. Maybe it's just semantics, 
> but there is a way to add "custom call backs" to your feature/bundle
> builds, so, I used that mechanism, at the feature 
> level, to get and copy the pre-built bundles. To make it concrete
--
> merely to aide discussion, not meant to be "how to" -- 
> here's the rough steps I went through to get closer to what I 
> believe is the Orbit model we're headed. 
> This example is from WTP, using our  xml_core feature and it's
need 
> for xerces from Apache. 
> 
> In our previous release, in our xml_core feature, we "required"
the 
> xerces.feature, whose only included plugin was the xerces bundle.
> So, I removed all that, and added "include" xerces directly
to our 
> xml_core feature. 
> 
> Then, in xml_core feature's build.properties I added the line 
>     customBuildCallbacks=addPreBuiltComponents.xml 
> 
> Next I created the addPreBuiltComponents.xml file, starting with a
> template from the customCallbacks.xml content, found in 
> org.eclipse.pde.build_<version>\templates\features 
> 
> Then I added my custom "get and copy" script  ... 
>         <target name="pre.gather.bin.parts">
>             <!-- copy our known,
pre-built, usually third party pre-
> reqs into this feature --> 
>         <copy 
>             todir="${destination.temp.folder}"
>             overwrite="true">
>             <fileset dir="${env.BUILD_HOME}/prebuilt/eclipse/plugins/"
> includes="org.apache.xerces*/**" /> 
>         </copy> 
>         </target> 
> 
> And, so far seems to be working well (doesn't seem like that should
> have taken 3 days, does it? :) 
> 
> I like this approach since you can code all the "knowledge"
of the 
> 3rd party requirement right there in the feature project, and 
> because you can name the file something meaningful for this case.
> (that's the semantics part). 
> 
> So, obviously, my "get and copy" is only copying from our
build 
> machine, so far, and the "copy" relies on some silly ant
attribute, 
> (to avoid hard coding the exact version numbers) but I could see 
> those few lines being easily improved to be more robust. 
> 
> So, on the one hand, we could all do what ever we wanted or needed
> to do, right there in those few lines of script code ... 
> get from a maven repository? ... download and unzip an archive file?
> ... or whatever. 
> 
> I think (part of) Eugene's (and Jeff's) recent comments is that it'd
> be great to have a more general "get and copy task", such
as 
> get-the-bundle-versioned-2.8.0-but-with-the-most-recent-(highest)-
> qualifier-from-repository-xyz-using-protocol-abc. 
> (right?)  If so, seems we could make incremental progress on
that, 
> if anyone happens to develop more robust ant tasks. 
> 
> So ... I post this just for comment ... if anyone has any 
> comments/improvements/warnings on this approach .... let me know.
> After all, I could not find customCallbacks mentioned anywhere in
> the Eclipse RCP book, so maybe it's completely invalid :) 
> 
> And ... soon, we'll get back to talking about  how to produce
Orbit,
> instead of how we expect to use Orbit :) 
> _______________________________________________
> orbit-dev mailing list
> orbit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orbit-dev