Re: [equinox-dev] Equinox Aspects: Reworked website, quick-start guide and Hello world! demo
Sounds good. Of course by update site I meant to say p2 repository :-) Jeff Martin Lippert wrote: Hi Jeff, This sounds like a good plan. Thanks for being proactive on this. It will be interesting to see what happens with the *new* lower version. For exapmle, if the update sites that people use have both the new and old with the new version being lower then users likely will not be able to get the right thing. Would you see removing the older versions? I think we should create a new update site for this. As for the graduation review, do you have a set of code that you would like to release now? If that is true then you might just graduate with a higher version number and remove the old versions. I think that either option would be fine. Thanks again. Our current idea is to start with the lower version number, then build a number of milestone builds over the next months and graduate after this period (maybe by the end of this or beginning of next year). Does this sound reasonable? -Martin Jeff Martin Lippert wrote: Hi Jeff, we discussed this briefly and the result is: we would like to do ALL this stuff... ;-) Our idea would be: 1. lower the version numbers to make the incubator status clear. This includes communication with the community to avoid confusion and to make clear that this does not include lowering the quality of the code produced so far... ;-) 2. produce some more milestone builds instead of what we called releases in the past. We will write up a project plan as a wiki page that includes open bugs and our goals for upcoming milestone builds. 3. start the graduation process for a future first release of equinox aspects including reviews, a release review and whatever is necessary to graduate... :-) What do you think? -Martin Jeff McAffer wrote: Possible solutions: - graduate - lower the version numbers In either case there will need to be a review if there is going to be a release. You could avoid a review if the version number is lowered AND the event is rephrased as a milestone. As for dealing with the past, well, dropping the version numbers would certainly cause some confusion. Graduation would retain the version number sequence but we'd have to have a discussion in the wider community to see if graduation is warranted (I have no evidence either way at this point). I'm certainly open to alternatives. Jeff Martin Lippert wrote: Thanks Bjorn and Jeff for the clarification! Now the question arises how we should deal with upcoming releases of equinox aspects while being in incubation... ;-) Since we published releases with versions 1.x I am not sure what the best way is to move on. We mentioned the incubation within the bundle names and download zips (according to the guidelines I hope). Should we go back to versions 0.x with the next releases (with some explanations to avoid confusion)? -Martin Bjorn Freeman-Benson wrote: The policy that we've been following/enforcing is that a project in incubation must have releases 1.0 and that projects out of incubation have releases = 1.0. I apologize that this is not clearly written. Jeff McAffer wrote: In any event, Bjorn (cc'd) would certainly know if there is an actual policy on this. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] P2 touchpoint instructions doc
Yet another question about touchpoint data.
Does it matter if an IU is authored so that there is only one
instruction per TouchpointData? This would make it easier in the user
interface. The user would then only see two levels - the instruction
(install, uninstall, etc.), and the actions for the instruction. The
grouping of several instructions seems to have no semantic meaning
(but is useful at runtime).
Thus, the user can add install, uninstall, etc. instructions, and add
actions to them but do not have to be concerned with grouping at all.
Do you think this approach is ok?
Regards
Henrik Lindberg
[EMAIL PROTECTED]
On 23 jun 2008, at 21.40, Simon Kaegi wrote:
Hm, I think may able to answer this myself. The format is actually
documented :)
The touchpoint data has a map, the keys in this map are the phases
like install, and the value is the format described on the wiki
page - i.e. a string that needs to be parsed
to understand the actions and parameters i.e action1
(paramname1:value, paramname2:value,
paramname3:value);action2(...); ...
Can someone confirm - or have I got it wrong yet one more time :) ?
Yep. That's it. You've got it.
Henrik Lindberg
[EMAIL PROTECTED]
On 23 jun 2008, at 17.25, Henrik Lindberg wrote:
Thanks Simon,
Hm, seems that my understanding of this is still unclear. I
understand touchpoint type - one IU can affect one touchpoint only,
but I have trouble with Touchpoint Data.
The IU has a list of Touchpoint Data. What exactly is one such
Touchpoint Data instance describing? I thought it was one
instruction like chmod, but now I am uncertain. From your response
it seems like one Touchpoint Data instance describes a set of
instructions for a phase like install - or is it even capable of
describing multiple sets of instructions for different phases?
Is the following correct touchpoint data?
touchpoint data = a Map {
{ key = install, value= a Map {
{key=setXXX, value= aMap { {key=param1, value= } {key=param2,
value=}},
{key=chmod, value= aMap { {key=param1, value= } {key=param2,
value=}} }
{ key = uninstall, value= a Map {
// instructions for uninstall...
} }
}
If that is true, then I will update the wiki page to make it clear -
an instruction is the top level thing (i.e. install,
uninstall), and in such an instruction it is possible to specify
actions (but only one action instance per type of action).
Henrik Lindberg
[EMAIL PROTECTED]
On 23 jun 2008, at 16.27, Simon Kaegi wrote:
A couple of notes and questions:
- With the current encoding (a map of instructions), it is not
possible to use the same instruction type more than once. Is this
intentional? What if the author needs to create two directories
etc?
(I am asking because if this will be changed in the future I
want to
allow the user to add more than one of the same instruction type).
At runtime the intent is to allow a resolved IU to provide
multiple instructions with the same key. e.g. multiple install
instructions is fair game.
I use runtime and resolved because one of the important uses of
multiple instructions is to allow IUFragments to provide additional
instructions with the same key.
e.g. an IU when resolved with IUFragments might provide multiple
install instructions.
At dev time I would suggest only using one instruction for each key
although I don't believe there is a formal restriction here.
I think I may have understood the format wrong. Does an instance
of
TouchpointData describe one instruction?
Multiple instructions are fine... e.g. an IU's touchpoint data
section can provide an install, uninstall, configure, etc. set
of instructions.
- Why the special use of @artifact instead of an injected
parameter like artifactDir that can be included with $
{artifactDir} ? (I am asking because I am thinking about what kind
of editing support to offer - perhaps browse/select from available
parameters, and the @artifact is different than the other
parameters).
Yes this is something we can cleanup. Originally we didn't have a
place to initialize parameters that would get set by an action from
an earlier phase.
There are a few other changes that need to be done here also to
allow referencing more than just the first artifact of an IU. As a
result I was reluctant to do a change here late in the cycle.
- How are actions executed during the phases? (I have not studied
the code), but it seems logical that what is specified in the IU's
touchpoint data gets executed during install and uninstall - and
that the install phase executes the Action's execute the
uninstall executes the Action's undo - is this correct?
Undo is used only when rolling back a failed set of operations.
e.g. during the uninstall phase we use explicit uninstallbundle
actions.
The reason this is the case is that an action/undo pair is not
always perfectly symmetric e.g. an action can be destructive (for
example
RE: [equinox-dev] P2 touchpoint instructions doc
Agrred. I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=238240 to track this. [EMAIL PROTECTED] wrote on 06/24/2008 03:50:15 AM: [image removed] RE: [equinox-dev] P2 touchpoint instructions doc Haigermoser, Helmut to: Equinox development mailing list 06/24/2008 03:50 AM Sent by: [EMAIL PROTECTED] Please respond to Equinox development mailing list Ciao @ll :) I've already had trouble with this limitation, my Desktop Shortcut action tried to create a shortcut Eclipse, 3.4 messing up the parameter parsing completely. Ended up substituting , with %comma%, this solved my issues but such substitution should be generalized into p2 code if we need to keep the limitation... HTH, Ciao, hh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henrik Lindberg Sent: 24 June 2008 00:59 To: Equinox development mailing list Subject: Re: [equinox-dev] P2 touchpoint instructions doc :) That means that it is not possible to have a parameter value that includes a comma ',' - the parser will then think it delimits the value. Which is fine for now for paths, filenames, artifact keys and such, but perhaps not for some future touchpoints and actions. Is there some particular reason for using the current format and not have actions as classes read/written to XML? Henrik Lindberg [EMAIL PROTECTED] On 23 jun 2008, at 21.40, Simon Kaegi wrote: Hm, I think may able to answer this myself. The format is actually documented :) The touchpoint data has a map, the keys in this map are the phases like install, and the value is the format described on the wiki page - i.e. a string that needs to be parsed to understand the actions and parameters i.e action1 (paramname1:value, paramname2:value, paramname3:value);action2(...); ... Can someone confirm - or have I got it wrong yet one more time :) ? Yep. That's it. You've got it. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] P2 touchpoint instructions doc
Does it matter if an IU is authored so that there is only one
instruction per TouchpointData? This would make it easier in the
user interface. The user would then only see two levels - the
instruction (install, uninstall, etc.), and the actions for the
instruction. The grouping of several instructions seems to have no
semantic meaning (but is useful at runtime).
Thus, the user can add install, uninstall, etc. instructions, and
add actions to them but do not have to be concerned with grouping at all.
Do you think this approach is ok?
The implementation would support this however I personally find it a bit
fine grained.
I tend to group contributions around installing/configuring/uninstalling
etc. a particular artifact.
In other words the semantics I apply are along the lines of...
...these are the instructions for this chunk of touchpoint data (e.g.
artifact).
With that said, I'm not too fussed about it.
-Simon
Regards
Henrik Lindberg
[EMAIL PROTECTED]
On 23 jun 2008, at 21.40, Simon Kaegi wrote:
Hm, I think may able to answer this myself. The format is actually
documented :)
The touchpoint data has a map, the keys in this map are the phases
like install, and the value is the format described on the wiki
page - i.e. a string that needs to be parsed
to understand the actions and parameters i.e action1
(paramname1:value, paramname2:value, paramname3:value);action2(...);
...
Can someone confirm - or have I got it wrong yet one more time :) ?
Yep. That's it. You've got it.
Henrik Lindberg
[EMAIL PROTECTED]
On 23 jun 2008, at 17.25, Henrik Lindberg wrote:
Thanks Simon,
Hm, seems that my understanding of this is still unclear. I
understand touchpoint type - one IU can affect one touchpoint only,
but I have trouble with Touchpoint Data.
The IU has a list of Touchpoint Data. What exactly is one such
Touchpoint Data instance describing? I thought it was one
instruction like chmod, but now I am uncertain. From your response
it seems like one Touchpoint Data instance describes a set of
instructions for a phase like install - or is it even capable of
describing multiple sets of instructions for different phases?
Is the following correct touchpoint data?
touchpoint data = a Map {
{ key = install, value= a Map {
{key=setXXX, value= aMap { {key=param1, value= } {key=param2,
value=}},
{key=chmod, value= aMap { {key=param1, value= } {key=param2,
value=}} }
{ key = uninstall, value= a Map {
// instructions for uninstall...
} }
}
If that is true, then I will update the wiki page to make it clear -
an instruction is the top level thing (i.e. install,
uninstall), and in such an instruction it is possible to specify
actions (but only one action instance per type of action).
Henrik Lindberg
[EMAIL PROTECTED]
On 23 jun 2008, at 16.27, Simon Kaegi wrote:
A couple of notes and questions:
- With the current encoding (a map of instructions), it is not
possible to use the same instruction type more than once. Is this
intentional? What if the author needs to create two directories etc?
(I am asking because if this will be changed in the future I want to
allow the user to add more than one of the same instruction type).
At runtime the intent is to allow a resolved IU to provide
multiple instructions with the same key. e.g. multiple install
instructions is fair game.
I use runtime and resolved because one of the important uses of
multiple instructions is to allow IUFragments to provide additional
instructions with the same key.
e.g. an IU when resolved with IUFragments might provide multiple
install instructions.
At dev time I would suggest only using one instruction for each key
although I don't believe there is a formal restriction here.
I think I may have understood the format wrong. Does an instance of
TouchpointData describe one instruction?
Multiple instructions are fine... e.g. an IU's touchpoint data
section can provide an install, uninstall, configure, etc. set
of instructions.
- Why the special use of @artifact instead of an injected
parameter like artifactDir that can be included with $
{artifactDir} ? (I am asking because I am thinking about what kind
of editing support to offer - perhaps browse/select from available
parameters, and the @artifact is different than the other
parameters).
Yes this is something we can cleanup. Originally we didn't have a
place to initialize parameters that would get set by an action from
an earlier phase.
There are a few other changes that need to be done here also to
allow referencing more than just the first artifact of an IU. As a
result I was reluctant to do a change here late in the cycle.
- How are actions executed during the phases? (I have not studied
the code), but it seems logical that what is specified in the IU's
touchpoint data gets executed during install and
Re: [equinox-dev] P2 touchpoint instructions doc
Well, I can do it that way too - I will then show a tree of
instruction blocks where each block as the nodes install/uninstall/
configure... already in place, but empty if there are no
instructions. Then the user can either add a new instruction block
or add/edit actions in the nodes. Empty nodes will not be written to
XML.
It would be good if it was possible to give the TouchpointData a name/
label - this if an IU has several and user wants to name them to be
able to find the wanted block without browsing through instructions.
Meanwhile I will just label them instruction block n or something
like that.
Is that better?
Henrik Lindberg
[EMAIL PROTECTED]
On 24 jun 2008, at 16.13, Simon Kaegi wrote:
Does it matter if an IU is authored so that there is only one
instruction per TouchpointData? This would make it easier in the
user interface. The user would then only see two levels - the
instruction (install, uninstall, etc.), and the actions for the
instruction. The grouping of several instructions seems to have no
semantic meaning (but is useful at runtime).
Thus, the user can add install, uninstall, etc. instructions, and
add actions to them but do not have to be concerned with grouping
at all.
Do you think this approach is ok?
The implementation would support this however I personally find it a
bit fine grained.
I tend to group contributions around installing/configuring/
uninstalling etc. a particular artifact.
In other words the semantics I apply are along the lines of...
...these are the instructions for this chunk of touchpoint data
(e.g. artifact).
With that said, I'm not too fussed about it.
-Simon
Regards
Henrik Lindberg
[EMAIL PROTECTED]
On 23 jun 2008, at 21.40, Simon Kaegi wrote:
Hm, I think may able to answer this myself. The format is actually
documented :)
The touchpoint data has a map, the keys in this map are the phases
like install, and the value is the format described on the wiki
page - i.e. a string that needs to be parsed
to understand the actions and parameters i.e action1
(paramname1:value, paramname2:value,
paramname3:value);action2(...); ...
Can someone confirm - or have I got it wrong yet one more
time :) ?
Yep. That's it. You've got it.
Henrik Lindberg
[EMAIL PROTECTED]
On 23 jun 2008, at 17.25, Henrik Lindberg wrote:
Thanks Simon,
Hm, seems that my understanding of this is still unclear. I
understand touchpoint type - one IU can affect one touchpoint
only,
but I have trouble with Touchpoint Data.
The IU has a list of Touchpoint Data. What exactly is one such
Touchpoint Data instance describing? I thought it was one
instruction like chmod, but now I am uncertain. From your
response
it seems like one Touchpoint Data instance describes a set of
instructions for a phase like install - or is it even capable of
describing multiple sets of instructions for different phases?
Is the following correct touchpoint data?
touchpoint data = a Map {
{ key = install, value= a Map {
{key=setXXX, value= aMap { {key=param1, value= } {key=param2,
value=}},
{key=chmod, value= aMap { {key=param1, value= } {key=param2,
value=}} }
{ key = uninstall, value= a Map {
// instructions for uninstall...
} }
}
If that is true, then I will update the wiki page to make it
clear -
an instruction is the top level thing (i.e. install,
uninstall), and in such an instruction it is possible to specify
actions (but only one action instance per type of action).
Henrik Lindberg
[EMAIL PROTECTED]
On 23 jun 2008, at 16.27, Simon Kaegi wrote:
A couple of notes and questions:
- With the current encoding (a map of instructions), it is not
possible to use the same instruction type more than once. Is
this
intentional? What if the author needs to create two
directories etc?
(I am asking because if this will be changed in the future I
want to
allow the user to add more than one of the same instruction
type).
At runtime the intent is to allow a resolved IU to provide
multiple instructions with the same key. e.g. multiple install
instructions is fair game.
I use runtime and resolved because one of the important uses
of
multiple instructions is to allow IUFragments to provide
additional
instructions with the same key.
e.g. an IU when resolved with IUFragments might provide multiple
install instructions.
At dev time I would suggest only using one instruction for each
key
although I don't believe there is a formal restriction here.
I think I may have understood the format wrong. Does an
instance of
TouchpointData describe one instruction?
Multiple instructions are fine... e.g. an IU's touchpoint data
section can provide an install, uninstall, configure, etc.
set
of instructions.
- Why the special use of @artifact instead of an injected
parameter like artifactDir that can be
[equinox-dev] [prov] Next week meeting cancelled
Because of July 1st here in Canada, next week p2 meeting will be cancelled. PaScaL___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Possible to obtain org.eclipse.osgi.jar without OSGi framework classes?
Hello, I'm currently embedding equinox into a JEE app server and would like to make the OSGi API visible to the enclosing application. Therefore, I need an org.eclipse.osgi distribution that does not include the org.osgi.framework classes. Does it exist? Cheers, Olaf ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
