Home » Eclipse Projects » Oomph » Origin of a variable
| Origin of a variable [message #1403293] |
Tue, 22 July 2014 13:13  |
|
Hi,
Today, when I hit the "Perform Setup Tasks..." button, I was prompted
for a variable value that I had never previously been asked to supply.
I don't think it's coming from my Papyrus setup because that hasn't
changed since I last ran the setup.
Is there some way to reveal in the set-up wizard the origin of a
variable that I'm being prompted to supply? That is to say, which
project/product definition in which setup model needs this variable?
The wizard only shows the variable name "Target Platform" with choices
like "Eclipse Mars", "Eclipse Luna", etc., and "None". I don't know
what it is for (I have a fully functional and complete targlet set up)
so I'm worried about what will happen if I proceed to run this set-up.
Thanks,
Christian
|
|
|
| Re: Origin of a variable [message #1403294 is a reply to message #1403293] |
Tue, 22 July 2014 14:24  |
|
Hi Christian,
I know that Ed was working on the consolidation (and easier composition) of Targlet tasks and I know that he introduced
this variable plus a skeleton Targlet task into the Eclipse.org project catalog. I thought that his intention was that
these two pieces are "invisible" to those who don't use them. I'm sure that he can provide more detail when he's back ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 22.07.2014 15:13, schrieb Christian W. Damus:
> Hi,
>
> Today, when I hit the "Perform Setup Tasks..." button, I was prompted for a variable value that I had never previously
> been asked to supply. I don't think it's coming from my Papyrus setup because that hasn't changed since I last ran
> the setup.
>
> Is there some way to reveal in the set-up wizard the origin of a variable that I'm being prompted to supply? That is
> to say, which project/product definition in which setup model needs this variable? The wizard only shows the variable
> name "Target Platform" with choices like "Eclipse Mars", "Eclipse Luna", etc., and "None". I don't know what it is
> for (I have a fully functional and complete targlet set up) so I'm worried about what will happen if I proceed to run
> this set-up.
>
> Thanks,
>
> Christian
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Origin of a variable [message #1403435 is a reply to message #1403294] |
Wed, 23 July 2014 16:10 |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Christian,
Sorry I'm falling behind keeping up with Gerrit. I want to revisit the
Papyrus setup with an eye to using a targlet design like the one I've
put into Xtext. The basic idea is that you define named repo lists
exactly like what you see in the project catalog. In each grouping
you'd put the additional repos your projects need for each of those
Eclipse versions. Then you don't need to specify the platform's p2
update site, because you inherit it from the base targlet, but only the
ones needed to resolve things for your project. Also, with the recent
changes to the targlet resolution mechanism, it's a good practice to
include your own project's p2 update site because the targlet, when it
resolves, will include a binary version of the corresponding imported
project. I'll try to find time to look at Papyrus' setup to suggest
ways to improve it...
On 22/07/2014 4:24 PM, Eike Stepper wrote:
> Hi Christian,
>
> I know that Ed was working on the consolidation (and easier
> composition) of Targlet tasks and I know that he introduced this
> variable plus a skeleton Targlet task into the Eclipse.org project
> catalog. I thought that his intention was that these two pieces are
> "invisible" to those who don't use them. I'm sure that he can provide
> more detail when he's back ;-)
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Am 22.07.2014 15:13, schrieb Christian W. Damus:
>> Hi,
>>
>> Today, when I hit the "Perform Setup Tasks..." button, I was prompted
>> for a variable value that I had never previously been asked to
>> supply. I don't think it's coming from my Papyrus setup because that
>> hasn't changed since I last ran the setup.
>>
>> Is there some way to reveal in the set-up wizard the origin of a
>> variable that I'm being prompted to supply? That is to say, which
>> project/product definition in which setup model needs this variable?
>> The wizard only shows the variable name "Target Platform" with
>> choices like "Eclipse Mars", "Eclipse Luna", etc., and "None". I
>> don't know what it is for (I have a fully functional and complete
>> targlet set up) so I'm worried about what will happen if I proceed to
>> run this set-up.
>>
>> Thanks,
>>
>> Christian
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Origin of a variable [message #1403587 is a reply to message #1403435] |
Thu, 24 July 2014 14:00 |
|
Hi, Ed,
I certainly welcome anything that will simplify the Papyrus setup
model. At the moment, it has a lot of duplication of variable in the
streams of all the sub-projects, and there will be that much more when
Papyrus branches off the Luna maintenance stream in the fall. At first
glance, I don't understand how this new variable is supposed to work,
but I'll probably figure it out when I have time to look through some
of your models again.
One idea that I had to streamline the stream situation (pun intended),
to eliminate most of the variable duplication, would be a concept of
abstract container projects. Currently, the "Papyrus" project (and
sub-projects like "Main" and "Extras") are abstract in the sense that
they cannot be imported, on account of not defining any Streams. But,
what if I could explicitly mark my top-level "Papyrus" project as
abstract and give it streams that declare my variables? Then, all of
the sub-projects could inherit the streams from this top project, with
some merging rules:
* sub-projects that define no streams of their own but are not marked
abstract will inherit
streams from their container project chain
* sub-projects that define streams inherit definitions from the
streams (matched by name)
in their container project chain, with variables, targlets, P2
directors, etc. merged as
currently done by projects (without the stream factor)
With that, I could pretty much eliminate all of my variable replication.
What do you think of this?
cW
On 2014-07-23 16:10:05 +0000, Ed Merks said:
> Christian,
>
> Sorry I'm falling behind keeping up with Gerrit. I want to revisit the
> Papyrus setup with an eye to using a targlet design like the one I've
> put into Xtext. The basic idea is that you define named repo lists
> exactly like what you see in the project catalog. In each grouping
> you'd put the additional repos your projects need for each of those
> Eclipse versions. Then you don't need to specify the platform's p2
> update site, because you inherit it from the base targlet, but only the
> ones needed to resolve things for your project. Also, with the recent
> changes to the targlet resolution mechanism, it's a good practice to
> include your own project's p2 update site because the targlet, when it
> resolves, will include a binary version of the corresponding imported
> project. I'll try to find time to look at Papyrus' setup to suggest
> ways to improve it...
>
> On 22/07/2014 4:24 PM, Eike Stepper wrote:
>> Hi Christian,
>>
>> I know that Ed was working on the consolidation (and easier
>> composition) of Targlet tasks and I know that he introduced this
>> variable plus a skeleton Targlet task into the Eclipse.org project
>> catalog. I thought that his intention was that these two pieces are
>> "invisible" to those who don't use them. I'm sure that he can provide
>> more detail when he's back ;-)
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Am 22.07.2014 15:13, schrieb Christian W. Damus:
>>> Hi,
>>>
>>> Today, when I hit the "Perform Setup Tasks..." button, I was prompted
>>> for a variable value that I had never previously been asked to supply.
>>> I don't think it's coming from my Papyrus setup because that hasn't
>>> changed since I last ran the setup.
>>>
>>> Is there some way to reveal in the set-up wizard the origin of a
>>> variable that I'm being prompted to supply? That is to say, which
>>> project/product definition in which setup model needs this variable?
>>> The wizard only shows the variable name "Target Platform" with choices
>>> like "Eclipse Mars", "Eclipse Luna", etc., and "None". I don't know
>>> what it is for (I have a fully functional and complete targlet set up)
>>> so I'm worried about what will happen if I proceed to run this set-up.
>>>
>>> Thanks,
>>>
>>> Christian
|
|
|
| Re: Origin of a variable [message #1403795 is a reply to message #1403587] |
Sun, 27 July 2014 16:05 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Christian,
Comments below.
On 24/07/2014 4:00 PM, Christian W. Damus wrote:
> Hi, Ed,
>
> I certainly welcome anything that will simplify the Papyrus setup
> model. At the moment, it has a lot of duplication of variable in the
> streams of all the sub-projects, and there will be that much more when
> Papyrus branches off the Luna maintenance stream in the fall. At
> first glance, I don't understand how this new variable is supposed to
> work, but I'll probably figure it out when I have time to look through
> some of your models again.
It's just used as a selector to activate a particular list of repos in
the targlet task, so if you have one list per release train, it's easy
to activate that one, and if everyone does that in their setups, its
easy to make a single consistent choice across projects...
>
> One idea that I had to streamline the stream situation (pun intended),
> to eliminate most of the variable duplication, would be a concept of
> abstract container projects. Currently, the "Papyrus" project (and
> sub-projects like "Main" and "Extras") are abstract in the sense that
> they cannot be imported, on account of not defining any Streams. But,
> what if I could explicitly mark my top-level "Papyrus" project as
> abstract and give it streams that declare my variables? Then, all of
> the sub-projects could inherit the streams from this top project, with
> some merging rules:
I see.
>
> * sub-projects that define no streams of their own but are not marked
> abstract will inherit
> streams from their container project chain
Based on stream name...
> * sub-projects that define streams inherit definitions from the
> streams (matched by name)
> in their container project chain, with variables, targlets, P2
> directors, etc. merged as
> currently done by projects (without the stream factor)
Make it behave as if the tasks are are copied to the "concrete" stream
(which we can do during the current copying process)...
>
> With that, I could pretty much eliminate all of my variable replication.
>
> What do you think of this?
That's an interesting idea; I'll definitely explore it further...
>
> cW
>
>
> On 2014-07-23 16:10:05 +0000, Ed Merks said:
>
>> Christian,
>>
>> Sorry I'm falling behind keeping up with Gerrit. I want to revisit
>> the Papyrus setup with an eye to using a targlet design like the one
>> I've put into Xtext. The basic idea is that you define named repo
>> lists exactly like what you see in the project catalog. In each
>> grouping you'd put the additional repos your projects need for each
>> of those Eclipse versions. Then you don't need to specify the
>> platform's p2 update site, because you inherit it from the base
>> targlet, but only the ones needed to resolve things for your
>> project. Also, with the recent changes to the targlet resolution
>> mechanism, it's a good practice to include your own project's p2
>> update site because the targlet, when it resolves, will include a
>> binary version of the corresponding imported project. I'll try to
>> find time to look at Papyrus' setup to suggest ways to improve it...
>>
>> On 22/07/2014 4:24 PM, Eike Stepper wrote:
>>> Hi Christian,
>>>
>>> I know that Ed was working on the consolidation (and easier
>>> composition) of Targlet tasks and I know that he introduced this
>>> variable plus a skeleton Targlet task into the Eclipse.org project
>>> catalog. I thought that his intention was that these two pieces are
>>> "invisible" to those who don't use them. I'm sure that he can
>>> provide more detail when he's back ;-)
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>
>>> Am 22.07.2014 15:13, schrieb Christian W. Damus:
>>>> Hi,
>>>>
>>>> Today, when I hit the "Perform Setup Tasks..." button, I was
>>>> prompted for a variable value that I had never previously been
>>>> asked to supply. I don't think it's coming from my Papyrus setup
>>>> because that hasn't changed since I last ran the setup.
>>>>
>>>> Is there some way to reveal in the set-up wizard the origin of a
>>>> variable that I'm being prompted to supply? That is to say, which
>>>> project/product definition in which setup model needs this
>>>> variable? The wizard only shows the variable name "Target
>>>> Platform" with choices like "Eclipse Mars", "Eclipse Luna", etc.,
>>>> and "None". I don't know what it is for (I have a fully functional
>>>> and complete targlet set up) so I'm worried about what will happen
>>>> if I proceed to run this set-up.
>>>>
>>>> Thanks,
>>>>
>>>> Christian
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Origin of a variable [message #1403800 is a reply to message #1403795] |
Sun, 27 July 2014 18:38 |
|
Thanks, Ed.
I have am now using the eclipse.target.platform variable and it has
eliminated the replication of loads of variables in every one of the
many sub-projects in the Papyrus setup model. Thanks for that!
Now, the only variable remaining that is repeated in every stream is
the value of the bugzilla version field for my Mylyn queries. If this
could be eliminated, then all (or the vast majority) of my streams
would be empty! I suppose the idea of stream inheritance could still
address this, although I must say that my earlier proposal of nested
variable expansion would also work. :-)
One more thing: is there anything else I need to do to satisfy the
requirements for publishing the Papyrus setup model in the official
Oomph catalogue? I'm waiting for a response to my provisioning request
[1].
Thanks again!
Christian
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=439487
On 2014-07-27 16:05:42 +0000, Ed Merks said:
> Christian,
>
> Comments below.
>
> On 24/07/2014 4:00 PM, Christian W. Damus wrote:
>> Hi, Ed,
>>
>> I certainly welcome anything that will simplify the Papyrus setup
>> model. At the moment, it has a lot of duplication of variable in the
>> streams of all the sub-projects, and there will be that much more when
>> Papyrus branches off the Luna maintenance stream in the fall. At first
>> glance, I don't understand how this new variable is supposed to work,
>> but I'll probably figure it out when I have time to look through some
>> of your models again.
> It's just used as a selector to activate a particular list of repos in
> the targlet task, so if you have one list per release train, it's easy
> to activate that one, and if everyone does that in their setups, its
> easy to make a single consistent choice across projects...
>>
>> One idea that I had to streamline the stream situation (pun intended),
>> to eliminate most of the variable duplication, would be a concept of
>> abstract container projects. Currently, the "Papyrus" project (and
>> sub-projects like "Main" and "Extras") are abstract in the sense that
>> they cannot be imported, on account of not defining any Streams. But,
>> what if I could explicitly mark my top-level "Papyrus" project as
>> abstract and give it streams that declare my variables? Then, all of
>> the sub-projects could inherit the streams from this top project, with
>> some merging rules:
> I see.
>>
>> * sub-projects that define no streams of their own but are not marked
>> abstract will inherit
>> streams from their container project chain
> Based on stream name...
>> * sub-projects that define streams inherit definitions from the streams
>> (matched by name)
>> in their container project chain, with variables, targlets, P2
>> directors, etc. merged as
>> currently done by projects (without the stream factor)
> Make it behave as if the tasks are are copied to the "concrete" stream
> (which we can do during the current copying process)...
>>
>> With that, I could pretty much eliminate all of my variable replication.
>>
>> What do you think of this?
> That's an interesting idea; I'll definitely explore it further...
>>
>> cW
>>
>>
>> On 2014-07-23 16:10:05 +0000, Ed Merks said:
>>
>>> Christian,
>>>
>>> Sorry I'm falling behind keeping up with Gerrit. I want to revisit the
>>> Papyrus setup with an eye to using a targlet design like the one I've
>>> put into Xtext. The basic idea is that you define named repo lists
>>> exactly like what you see in the project catalog. In each grouping
>>> you'd put the additional repos your projects need for each of those
>>> Eclipse versions. Then you don't need to specify the platform's p2
>>> update site, because you inherit it from the base targlet, but only the
>>> ones needed to resolve things for your project. Also, with the recent
>>> changes to the targlet resolution mechanism, it's a good practice to
>>> include your own project's p2 update site because the targlet, when it
>>> resolves, will include a binary version of the corresponding imported
>>> project. I'll try to find time to look at Papyrus' setup to suggest
>>> ways to improve it...
>>>
>>> On 22/07/2014 4:24 PM, Eike Stepper wrote:
>>>> Hi Christian,
>>>>
>>>> I know that Ed was working on the consolidation (and easier
>>>> composition) of Targlet tasks and I know that he introduced this
>>>> variable plus a skeleton Targlet task into the Eclipse.org project
>>>> catalog. I thought that his intention was that these two pieces are
>>>> "invisible" to those who don't use them. I'm sure that he can provide
>>>> more detail when he's back ;-)
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://www.esc-net.de
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>
>>>> Am 22.07.2014 15:13, schrieb Christian W. Damus:
>>>>> Hi,
>>>>>
>>>>> Today, when I hit the "Perform Setup Tasks..." button, I was prompted
>>>>> for a variable value that I had never previously been asked to supply.
>>>>> I don't think it's coming from my Papyrus setup because that hasn't
>>>>> changed since I last ran the setup.
>>>>>
>>>>> Is there some way to reveal in the set-up wizard the origin of a
>>>>> variable that I'm being prompted to supply? That is to say, which
>>>>> project/product definition in which setup model needs this variable?
>>>>> The wizard only shows the variable name "Target Platform" with choices
>>>>> like "Eclipse Mars", "Eclipse Luna", etc., and "None". I don't know
>>>>> what it is for (I have a fully functional and complete targlet set up)
>>>>> so I'm worried about what will happen if I proceed to run this set-up.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Christian
|
|
|
| Re: Origin of a variable [message #1403816 is a reply to message #1403800] |
Mon, 28 July 2014 05:56 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Christian,
Last week I was focused on improved drag and drop as well as cut, copy,
paste support, which took way longer than expected (but turned out super
cool). This week I'll catch up on the outstanding bugs and Gerrit reviews.
The problem with nested variable expansion is that we could no longer
build up a map of variable names to variable values, using the
references in the values to the keys in the map as a way to order
evaluation. The overall set of variable keys would itself become
variable...
On 27/07/2014 8:38 PM, Christian W. Damus wrote:
> Thanks, Ed.
>
> I have am now using the eclipse.target.platform variable and it has
> eliminated the replication of loads of variables in every one of the
> many sub-projects in the Papyrus setup model. Thanks for that!
>
> Now, the only variable remaining that is repeated in every stream is
> the value of the bugzilla version field for my Mylyn queries. If this
> could be eliminated, then all (or the vast majority) of my streams
> would be empty! I suppose the idea of stream inheritance could still
> address this, although I must say that my earlier proposal of nested
> variable expansion would also work. :-)
>
> One more thing: is there anything else I need to do to satisfy the
> requirements for publishing the Papyrus setup model in the official
> Oomph catalogue? I'm waiting for a response to my provisioning
> request [1].
>
> Thanks again!
>
> Christian
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=439487
>
>
> On 2014-07-27 16:05:42 +0000, Ed Merks said:
>
>> Christian,
>>
>> Comments below.
>>
>> On 24/07/2014 4:00 PM, Christian W. Damus wrote:
>>> Hi, Ed,
>>>
>>> I certainly welcome anything that will simplify the Papyrus setup
>>> model. At the moment, it has a lot of duplication of variable in
>>> the streams of all the sub-projects, and there will be that much
>>> more when Papyrus branches off the Luna maintenance stream in the
>>> fall. At first glance, I don't understand how this new variable is
>>> supposed to work, but I'll probably figure it out when I have time
>>> to look through some of your models again.
>> It's just used as a selector to activate a particular list of repos
>> in the targlet task, so if you have one list per release train, it's
>> easy to activate that one, and if everyone does that in their setups,
>> its easy to make a single consistent choice across projects...
>>>
>>> One idea that I had to streamline the stream situation (pun
>>> intended), to eliminate most of the variable duplication, would be a
>>> concept of abstract container projects. Currently, the "Papyrus"
>>> project (and sub-projects like "Main" and "Extras") are abstract in
>>> the sense that they cannot be imported, on account of not defining
>>> any Streams. But, what if I could explicitly mark my top-level
>>> "Papyrus" project as abstract and give it streams that declare my
>>> variables? Then, all of the sub-projects could inherit the streams
>>> from this top project, with some merging rules:
>> I see.
>>>
>>> * sub-projects that define no streams of their own but are not
>>> marked abstract will inherit
>>> streams from their container project chain
>> Based on stream name...
>>> * sub-projects that define streams inherit definitions from the
>>> streams (matched by name)
>>> in their container project chain, with variables, targlets, P2
>>> directors, etc. merged as
>>> currently done by projects (without the stream factor)
>> Make it behave as if the tasks are are copied to the "concrete"
>> stream (which we can do during the current copying process)...
>>>
>>> With that, I could pretty much eliminate all of my variable
>>> replication.
>>>
>>> What do you think of this?
>> That's an interesting idea; I'll definitely explore it further...
>>>
>>> cW
>>>
>>>
>>> On 2014-07-23 16:10:05 +0000, Ed Merks said:
>>>
>>>> Christian,
>>>>
>>>> Sorry I'm falling behind keeping up with Gerrit. I want to revisit
>>>> the Papyrus setup with an eye to using a targlet design like the
>>>> one I've put into Xtext. The basic idea is that you define named
>>>> repo lists exactly like what you see in the project catalog. In
>>>> each grouping you'd put the additional repos your projects need for
>>>> each of those Eclipse versions. Then you don't need to specify
>>>> the platform's p2 update site, because you inherit it from the base
>>>> targlet, but only the ones needed to resolve things for your
>>>> project. Also, with the recent changes to the targlet resolution
>>>> mechanism, it's a good practice to include your own project's p2
>>>> update site because the targlet, when it resolves, will include a
>>>> binary version of the corresponding imported project. I'll try to
>>>> find time to look at Papyrus' setup to suggest ways to improve it...
>>>>
>>>> On 22/07/2014 4:24 PM, Eike Stepper wrote:
>>>>> Hi Christian,
>>>>>
>>>>> I know that Ed was working on the consolidation (and easier
>>>>> composition) of Targlet tasks and I know that he introduced this
>>>>> variable plus a skeleton Targlet task into the Eclipse.org project
>>>>> catalog. I thought that his intention was that these two pieces
>>>>> are "invisible" to those who don't use them. I'm sure that he can
>>>>> provide more detail when he's back ;-)
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> ----
>>>>> http://www.esc-net.de
>>>>> http://thegordian.blogspot.com
>>>>> http://twitter.com/eikestepper
>>>>>
>>>>>
>>>>>
>>>>> Am 22.07.2014 15:13, schrieb Christian W. Damus:
>>>>>> Hi,
>>>>>>
>>>>>> Today, when I hit the "Perform Setup Tasks..." button, I was
>>>>>> prompted for a variable value that I had never previously been
>>>>>> asked to supply. I don't think it's coming from my Papyrus setup
>>>>>> because that hasn't changed since I last ran the setup.
>>>>>>
>>>>>> Is there some way to reveal in the set-up wizard the origin of a
>>>>>> variable that I'm being prompted to supply? That is to say, which
>>>>>> project/product definition in which setup model needs this
>>>>>> variable? The wizard only shows the variable name "Target
>>>>>> Platform" with choices like "Eclipse Mars", "Eclipse Luna", etc.,
>>>>>> and "None". I don't know what it is for (I have a fully
>>>>>> functional and complete targlet set up) so I'm worried about what
>>>>>> will happen if I proceed to run this set-up.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Christian
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 08:48:54 GMT 2024
Powered by FUDForum. Page generated in 0.02593 seconds |
] 
Search
Help
Register
Login
Home
