Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [p2-dev] Custom Touchpoint Action Craziness

Sorry guys - this reads worse than I intended and frankly it is a little confusing to parse.  (Note to self: Don't send emails when frustrated and on the way out the door to make an appointment).  Anyway, I'll debug it tomorrow since I have a stack trace to work from.  I feel better now after a stiff drink and a few hours away from it. ;) 
 
I guess my main two points/qeustions are:
 
1) Shouldn't the export operation fail outright, rather than silently log an exception and generate default metadata?
2) Simon mentioned I am re-declaring all of my metadata (which is true) rather than using IUFragments in another email thread.  Is there something fundamental I am missing?  If there is a way to do this by somehow declaring small fragments of metadata rather than re-declaring everything, I'd love to hear about it.
 
Thanks again,
Mark.

________________________________

From: p2-dev-bounces@xxxxxxxxxxx on behalf of Mark Melvin
Sent: Tue 12/05/2009 5:56 PM
To: P2 developer discussions
Subject: [p2-dev] Custom Touchpoint Action Craziness



Hello Again,

I am trying to contribute a custom touchpoint action, and then require
and use it from a p2.inf file.  I can't seem to make the metadata
generator behave unless I declare things a certain way and it makes no
sense.  Perhaps answers to some fundamental questions will ease my
suffering...

First of all, when I declare a custom touchpoint action via an extension
point, what do I fill in for "touchpointType" and "touchpointVersion"?
It seems if I do not specify "org.eclipse.equinox.p2.native", I can't
really do much with it later (we'll get to that).  And why are these
fields optional?

Second, it has been brought up before, but it seems that if I want to
override the root files IU for a simple root files feature, I must
re-declare everything from scratch.  I also have found that if one tiny
thing is off, all of the metadata reverts back to the default values
making it next to impossible to figure out what the hell is going on.
For instance, let's say I have this:


properties.0.name=org.eclipse.equinox.p2.type.group
properties.0.value=false
requires.0.namespace=org.eclipse.equinox.p2.iu
requires.0.name=my.feature.name_root
requires.0.range=$version$
requires.0.greedy=true
requires.0.optional=false
requires.0.multiple=false
units.0.id=my.feature.name_root
units.0.version=$version$
units.0.singleton=true
units.0.provides.0.name=my.feature.name_root
units.0.provides.0.namespace=org.eclipse.equinox.p2.iu
units.0.provides.0.version=$version$
units.0.artifacts.0.classifier=binary
units.0.artifacts.0.id=my.feature.name_root
units.0.artifacts.0.version=$version$
units.0.touchpoint.id=org.eclipse.equinox.p2.native
units.0.touchpoint.version=1.0.0
units.0.instructions.install=helloworld();
units.0.instructions.uninstall=helloworld();

This particular construct allows me to simply override the default
install/uninstall action for my root files IU.  If I simply add one more
line to import my custom action and essentially hook it up like so:

units.0.instructions.configure.import=my.custom.feature.helloworld

Then I re-export, and my metadata looks entirely different.  It has
reverted back to being a group, the actions are defaulted back to
"unzip(source:@artifact, target:${installFolder});" and
"cleanupzip(source:@artifact, target:${installFolder});", and other
things are different as well.

Actually, further investigation shows that there is an error in my log
file indicating the following:

An error occured while parsing advice file:
basePath=C:/Temp/workspaces/test3.5sk/my.feature.name,
adviceFilePath=p2.inf.
java.lang.IllegalStateException: bad token:
units.0.instructions.configure.import
at
org.eclipse.equinox.p2.publisher.eclipse.AdviceFileParser.parseInstructi
ons(AdviceFileParser.java:240)
at
org.eclipse.equinox.p2.publisher.eclipse.AdviceFileParser.parseUnit(Advi
ceFileParser.java:353)
.
.


So I'm not sure what it is choking on, but shouldn't this cause the PDE
export operation to fail, instead of silently producing completely
different (default) metadata?  I've been fighting this for an hour and
still don't know what I am doing wrong.

Any hints on what the import statement is choking on?  I know I have
made this work before with Simon's metarequires sample and my .inf file
looks no different (apart from the names).

Thanks,
Mark.
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


<<winmail.dat>>


Back to the top