[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[p2-dev] Re: [dash-dev] RE: Help with creating P2 update site

While not strictly relevant to the magic of running a build or creating an update site, let me quickly explain the difference between a .feature and a .feature.group.

foo.feature is the jar (or folder) that contains the feature; foo.feature.feature.group is that jar + all its children (namely, contained features, fragments and plugins).

The former is a single installable unit (IU); the latter is a collection of IUs that p2 will verify & install in one operation.

If you're using the p2.director application to install a feature and its children, you can pass in foo.feature.feature.group, or a list of IUs if you prefer to be entirely explicit.

See also:

http://wiki.eclipse.org/Equinox_p2_director_application#Scripted_Examples

I've also been playing lately with the Buckminster Aggregator as a way of excluding & mirroring pieces of update sites to new locations on disk. The use case I'm exploring is that of update.site.A.zip, update.site.B.zip and update.site.C.zip being merged into update.sites.A+B+C.zip with updated metadata, reorganized/merged categories, and verified packed jars.

My script is incomplete (doesn't do re-categorization yet) but if this is useful to you (or anyone listening) here's the work in progress. Requires Ant-Contrib and can be launched from within Eclipse:

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.dash/athena/org.eclipse.dash.commonbuilder/org.eclipse.dash.common.releng/tools/scripts/aggregateRepos.xml?root=Technology_Project&view=markup

Happy provisioning!

Nick

Kristina Taylor wrote:
I'm using MKS Toolkit, so I have the tools to make a linux-friendly build work on Windows, and I know Eclipse comes with a CVS client, I guess I just need to get everything hooked up right.  In the meantime...

Are you plugins set to be lazily-loaded (check MANIFEST.MF)? Installing software does not mean activating software; Eclipse will only instantiate classes as needed so that initial workbench startup time is calculated in minutes instead of in hours or days. :)

Yes, they are set to be lazy loaded, but switching that didn't change anything.

If you plugins contribute UI (eg., a tool bar button), they will only be activated if the UI is visible in the current perspective. If they contribute a view the plugins won't show in the registry until the view is opened.

I'm aware of this. The plugin contributes a top-level menu, several views, import wizards, synchronize wizards, team sharing wizards, preferences, etc. None of these items show up in any of the places they should. The plugin works just fine when installed via "Classic Updates", by adding an extension location, which is what leads me to believe it's a problem with the update site. We used to use the "links" method of installation, then when that stopped being supported in RAD 7 (IIRC), we switched to the extension location option. Now that it looks like that's being deprecated too, update site it is (if I can only get it working)!

Thanks for your help.  I'll work on getting the example going, and let you know if (when!) I have further questions.  I'm still perplexed by the id of "<feature id>.feature.group" in the installed software list.  Why's that being tacked on? The only other place I see it is in various places in the content.xml in the update site.  Lines like "<provided namespace="org.eclipse.equinox.p2.iu" name="<feature id>.feature.jar" version="4.10.1" />" where the actual name of the feature jar generated is "<feature id>_4.10.1.jar".

Kristina

-----Original Message-----
From: dash-dev-bounces@xxxxxxxxxxx [mailto:dash-dev-bounces@xxxxxxxxxxx] On Behalf Of Nick Boldt
Sent: October 22, 2009 6:29 PM
To: Tools for Committer Community
Subject: Re: [dash-dev] Re: [p2-dev] Help with creating P2 update site

Thank you for the reply. I'm finally getting back to this problem after getting sidetracked yet again. I'm not really getting anywhere, unfortunately. I'm by no means a build expert/release engineer of any sort, so please bear with me.
We don't use CVS at all, so for me, the gef example fails saying "[build] [eclipse.fetch] Could not retrieve feature.xml and/or build.properties: java.io.IOException:

The Eclipse SDK comes with a CVS client built-in; you can use that to fetch the GEF sources into your workspace, then build against the local sources (if you don't want the build to do the cvs fetch for you).

It's recommended that you start with a working build because then you have examples of well-crafted plugins and features, including correct syntax in MANIFEST.MF, feature.xml, build.properties, etc.

Cannot run program "cvs" (in directory "C:\tmp\build\N200910221443\eclipse\tempFeature"): CreateProcess error=2, The system cannot find the file specified.". I'm not sure installing and configuring CVS is a good use of my time, just to make an example work.

That translates to "you need to install Cygwin for a linux-friendly build to work on Windows; while installing Cygwin, be sure to include the cvs client so that the program 'cvs' can be found."

If you don't want to go down the CVS route, there are SVN-based builds too. See http://wiki.eclipse.org/MoDisco/Releng/How_to_Use#Building_on_Windows

But in either case, you can point Athena at your workspace and have it build all the plugins/features it finds there using the localSourceCheckoutDir=/path/to/workspace/or/some/cvs/tree/dump/folder
in your athena releng project's build.properties.

1. Created a feature that contains all of my plugins (3) and fragments (2), and includes my feature (which in turn also includes the 3 plugins). 2. Created an update site
2a. Added my master feature
2b. Built the site. It generated jars for the master feature, my feature, and for each of my 5 plugins/fragments, as well as the artifacts.jar and contents.jar.

Sounds good so far.

3. Start a clean debug instance of eclipse with none of my workspace plugins enabled.
	3a. Add the local update site
	3b. Install the "all in one" feature
	3c. Let Eclipse it restart itself.

Yep, that sounds good too.

My feature is listed as installed software (under Help -> About -> Installation Details), but none of my plugins are listed in the plugin registry, nor are the GUI elements being loaded. It's also not showing up under "Features" in the Installation Details box. I'm obviously missing something fundamental. If in step 2a, I also add my other (non-master) feature to the update site, then in step 3b try to install that one instead, I get the same result. What I find rather odd is that in the list of installed software, the ID is feature.a.feature.group. Where's this "feature.group" thing coming from? I don't get the error I was having previously any more (I think there may have been a spurious dependency on one of my plugins in my feature), but I'm not exactly getting any further, either.

Are you plugins set to be lazily-loaded (check MANIFEST.MF)? Installing software does not mean activating software; Eclipse will only instantiate classes as needed so that initial workbench startup time is calculated in minutes instead of in hours or days. :)

If you plugins contribute UI (eg., a tool bar button), they will only be activated if the UI is visible in the current perspective. If they contribute a view the plugins won't show in the registry until the view is opened.

For deeper assistance re: bundle activation and start levels... and all that fun stuff... try asking questions in #equinox-dev on freenode. See http://wiki.eclipse.org/IRC for other channels.


-- Nick Boldt :: http://nick.divbyzero.com Release Engineer :: Eclipse Modeling & Dash Athena _______________________________________________ dash-dev mailing list 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