[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [p2-dev] Custom Touchpoint Action Craziness
|
Simon,
Thank you for your response. Things are starting to
make more sense now!
b) Re: the parse error. I never noticed
that the configure.import=foo.action was
always accompanied by a configure=action();
directive. I see the light now! I (stupidly) thought imports
done at configure time were available to the other phases, but of course this
makes no sense. I now see that you attach the import to the phase you are
interested in.
c) Your example is very useful! OK, I see what
you are doing - you are declaring a new IU that depends on the root files
IU. I have two more questions about this approach:
1) You mentioned that "with using an IUFragment we will always unzip the artifact
associated with the root IU so potentially tweak the "root" declaration in your
feature's build.properties to unzip in a more appropriate folder".
OK - I think I see what you mean by this. You mean that a default root
files IU will *always* contain the following lines:
<touchpoint
id='org.eclipse.equinox.p2.native'
version='1.0.0'/>
<touchpointData
size='1'>
<instructions
size='2'>
<instruction
key='install'>
unzip(source:@artifact,
target:${installFolder});
</instruction>
<instruction
key='uninstall'>
cleanupzip(source:@artifact,
target:${installFolder});
</instruction>
</instructions>
</touchpointData>
This is a pain for me because it means I will always
end up with files being inflated into the the "eclipse" folder, right? And
from what I understand of your comment, I should customize this behavior by,
say, putting my root files into a subfolder when I declare them in
build.properties, like so:
root=some/path/to/myfiles
I assume I can then write a custom handler (in my
IUFragment) that takes the files from the location ${installFolder}/some/path/to/myfiles and sticks them
where they should be. I guess this works, but wouldn't it make a ton more
sense to allow me to simply override the root file IU in the first place?
That is essentially what I was accomplishing by re-declaring it from
scratch. I no longer have the two-operation install (unzip them to a
folder, then move them somewhere), and I can write a proper cleanup operation
(the cleanupzip operation leaves empty folders
lying around).
I guess ultimately I could have my "copy to the
real location" step also remove the temporary location, but that just seems like
redundant work.
My second question with this approach is - do I need to
declare a touchpointId on my IUFragment? If I don't I get this in my
metadata:
<touchpoint id='null'
version='0.0.0'/>
<touchpointData
size='1'>
...
</touchpointData>
Is a touchpoint id of null
valid, or should I be declaring something?
Once again, thanks for your help and your patience. I
am getting very close to "great success". ;)
Mark.
The example I'm working on is a bit more comprehensive and also uses custom
actions but ere's a quick and dirty example using an IUFragment to alter the
root_files IU.
(See attached file:
example.p2inf.rootfiles.zip)
Simon
Kaegi---05/12/2009 11:37:14 PM---Mark,
From: |
Simon
Kaegi/Ottawa/IBM@IBMCA |
To: |
P2 developer discussions
<p2-dev@xxxxxxxxxxx> |
Date: |
05/12/2009 11:37 PM |
Subject: |
RE: [p2-dev] Custom Touchpoint Action
Craziness |
Mark,
I suspect the parse error is occurring
because we're finding the "import" without any actions declared. The parse
error is maybe over zealous however we are expecting to see action
declarations to go along with the import so I think if you declare some
actions you should be alright.
re (1) - log a bug. I think we want some
feedback here
re (2) - I'm working on an example right now and will post
something tomorrow.
In a nutshell we recognize a "unit" as an
IUFragment if it has a hostRequirement, so the approach I'm suggesting is
to:
1) create an IU with a hostRequirement on the {featureName}_root
IU.
2) add the requirement for this IUFragment to the main
p2.inf
One thing to keep in mind with using an IUFragment we will
always unzip the artifact associated with the root IU so potentially tweak the
"root" declaration in your feature's build.properties to unzip in a more
appropriate folder.
-Simon
"Mark
Melvin" ---05/12/2009 10:14:57 PM---Sorry guys - this reads worse than I
intended and frankly it is a little confusing to parse. (Note to self: Don't
send emails
From: |
"Mark Melvin" <Mark.Melvin@xxxxxxxxxx> |
To: |
"P2 developer discussions" <p2-dev@xxxxxxxxxxx> |
Date: |
05/12/2009 10:14 PM |
Subject: |
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
[attachment "winmail.dat" deleted by Simon
Kaegi/Ottawa/IBM] _______________________________________________
p2-dev
mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev
mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
