Home » Archived » Buckminster » materialize projects-platform.cquery in eclipse
|
| Re: materialize projects-platform.cquery in eclipse [message #892842 is a reply to message #892809] |
Sat, 30 June 2012 09:56   |
|
On 06/29/2012 09:19 PM, Lorenzo Bettini wrote:
> Hi
>
> I have another doubt (related to the buckminster functionalities created by the xtext wizard): if I materialize the
> projects-platform.cquery in eclipse I then get the .buckminster project with the tp. (I'm doing this to try to simulate
> in local the situation of the Jenkins headless build).
>
> However, the generated target platform contains some additional plugins but still rely on my eclipse installation, thus
> I don't have a real target platform separated from my eclipse installation, and I can't test locally the same situation
> of an headless build...
>
> is this the intended behavior?
>
Yes, this is expected. The default target platform is a copy of the default one (which has the runtime as the one and
only container). Buckminster adds a directory container to the copy and then uses that for additional stuff.
> is there something I could do to have the same situation of the headless build with a target platform in the workspace
> which does not rely on my eclipse local installation?
>
Yes. You can for instance do:
addtargetplatform -A -N tp <directory>
This will add a target platform by the name of 'tp' that appoints <directory> and set it to the currently active one.
Use an empty directory and do this before the import to get everything materialized into the directory.
HTH,
- thomas
|
|
|
| Re: materialize projects-platform.cquery in eclipse [message #892849 is a reply to message #892842] |
Sat, 30 June 2012 12:42 |
|
On 06/30/2012 11:56 AM, Thomas Hallgren wrote:
> On 06/29/2012 09:19 PM, Lorenzo Bettini wrote:
>> Hi
>>
>> I have another doubt (related to the buckminster functionalities
>> created by the xtext wizard): if I materialize the
>> projects-platform.cquery in eclipse I then get the .buckminster
>> project with the tp. (I'm doing this to try to simulate
>> in local the situation of the Jenkins headless build).
>>
>> However, the generated target platform contains some additional
>> plugins but still rely on my eclipse installation, thus
>> I don't have a real target platform separated from my eclipse
>> installation, and I can't test locally the same situation
>> of an headless build...
>>
>> is this the intended behavior?
>>
> Yes, this is expected. The default target platform is a copy of the
> default one (which has the runtime as the one and only container).
> Buckminster adds a directory container to the copy and then uses that
> for additional stuff.
>
>> is there something I could do to have the same situation of the
>> headless build with a target platform in the workspace
>> which does not rely on my eclipse local installation?
>>
> Yes. You can for instance do:
>
> addtargetplatform -A -N tp <directory>
>
> This will add a target platform by the name of 'tp' that appoints
> <directory> and set it to the currently active one. Use an empty
> directory and do this before the import to get everything materialized
> into the directory.
Hi Thomas
I'm not sure I understand where I should run that command... from within
eclipse or from the command line (sorry for the probably newbie question :)
in the meantime by adding an advisor node like
<cq:advisorNode namePattern=".*" useTargetPlatform="false"/>
I manage to have in the materialized target platform all the features
and plugins specified in the .cquery... still the target platform (as
shown from the eclipse preferences dialog) still contains the current
eclipse installation... I can manually remove the eclipse installation
from the eclipse dialog to have the complete yet (hopefully) minimal
target platform...
thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: materialize projects-platform.cquery in eclipse [message #892851 is a reply to message #892849] |
Sat, 30 June 2012 13:24 |
|
On 06/30/2012 02:42 PM, Lorenzo Bettini wrote:
> On 06/30/2012 11:56 AM, Thomas Hallgren wrote:
>> On 06/29/2012 09:19 PM, Lorenzo Bettini wrote:
>>> Hi
>>>
>>> I have another doubt (related to the buckminster functionalities
>>> created by the xtext wizard): if I materialize the
>>> projects-platform.cquery in eclipse I then get the .buckminster
>>> project with the tp. (I'm doing this to try to simulate
>>> in local the situation of the Jenkins headless build).
>>>
>>> However, the generated target platform contains some additional
>>> plugins but still rely on my eclipse installation, thus
>>> I don't have a real target platform separated from my eclipse
>>> installation, and I can't test locally the same situation
>>> of an headless build...
>>>
>>> is this the intended behavior?
>>>
>> Yes, this is expected. The default target platform is a copy of the
>> default one (which has the runtime as the one and only container).
>> Buckminster adds a directory container to the copy and then uses that
>> for additional stuff.
>>
>>> is there something I could do to have the same situation of the
>>> headless build with a target platform in the workspace
>>> which does not rely on my eclipse local installation?
>>>
>> Yes. You can for instance do:
>>
>> addtargetplatform -A -N tp <directory>
>>
>> This will add a target platform by the name of 'tp' that appoints
>> <directory> and set it to the currently active one. Use an empty
>> directory and do this before the import to get everything materialized
>> into the directory.
>
> Hi Thomas
>
> I'm not sure I understand where I should run that command... from within eclipse or from the command line (sorry for the
> probably newbie question :)
From the command line. To do the same thin in the Eclipse IDE you will need to use the "Preferences" -> "Plug-in
Development" -> "Target Platform" preference page to set up a new target platform.
>
> in the meantime by adding an advisor node like
>
> <cq:advisorNode namePattern=".*" useTargetPlatform="false"/>
>
This doesn't look right.
- thomas
|
|
|
| Re: materialize projects-platform.cquery in eclipse [message #892853 is a reply to message #892851] |
Sat, 30 June 2012 14:14 |
|
On 06/30/2012 03:24 PM, Thomas Hallgren wrote:
> On 06/30/2012 02:42 PM, Lorenzo Bettini wrote:
>> On 06/30/2012 11:56 AM, Thomas Hallgren wrote:
>>> On 06/29/2012 09:19 PM, Lorenzo Bettini wrote:
>>>> Hi
>>>>
>>>> I have another doubt (related to the buckminster functionalities
>>>> created by the xtext wizard): if I materialize the
>>>> projects-platform.cquery in eclipse I then get the .buckminster
>>>> project with the tp. (I'm doing this to try to simulate
>>>> in local the situation of the Jenkins headless build).
>>>>
>>>> However, the generated target platform contains some additional
>>>> plugins but still rely on my eclipse installation, thus
>>>> I don't have a real target platform separated from my eclipse
>>>> installation, and I can't test locally the same situation
>>>> of an headless build...
>>>>
>>>> is this the intended behavior?
>>>>
>>> Yes, this is expected. The default target platform is a copy of the
>>> default one (which has the runtime as the one and only container).
>>> Buckminster adds a directory container to the copy and then uses that
>>> for additional stuff.
>>>
>>>> is there something I could do to have the same situation of the
>>>> headless build with a target platform in the workspace
>>>> which does not rely on my eclipse local installation?
>>>>
>>> Yes. You can for instance do:
>>>
>>> addtargetplatform -A -N tp <directory>
>>>
>>> This will add a target platform by the name of 'tp' that appoints
>>> <directory> and set it to the currently active one. Use an empty
>>> directory and do this before the import to get everything materialized
>>> into the directory.
>>
>> Hi Thomas
>>
>> I'm not sure I understand where I should run that command... from
>> within eclipse or from the command line (sorry for the
>> probably newbie question :)
>
> From the command line. To do the same thin in the Eclipse IDE you will
> need to use the "Preferences" -> "Plug-in Development" -> "Target
> Platform" preference page to set up a new target platform.
OK, I see! Now in the empty directory I get all the plugins for the
target platform (though I don't get the features... but the projects
compile fine).
>
>>
>> in the meantime by adding an advisor node like
>>
>> <cq:advisorNode namePattern=".*" useTargetPlatform="false"/>
>>
> This doesn't look right.
why is this wrong?
thanks
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: materialize projects-platform.cquery in eclipse [message #892856 is a reply to message #892853] |
Sat, 30 June 2012 15:29 |
|
On 06/30/2012 04:14 PM, Lorenzo Bettini wrote:
>>>
>>> in the meantime by adding an advisor node like
>>>
>>> <cq:advisorNode namePattern=".*" useTargetPlatform="false"/>
>>>
>> This doesn't look right.
>
> why is this wrong?
>
The useTargetPlatform attribute prevents the resolver from using the target platform as source during resolve. I.e. it
will not try and find the needed components there. This is sometimes useful when you want to force Bucky to resolve from
an external source (to find updates) rather than be happy with what it finds in the TP. The TP will still receive binary
components during materialization.
- thomas
|
|
| |
| Re: materialize projects-platform.cquery in eclipse [message #893016 is a reply to message #893013] |
Mon, 02 July 2012 10:03 |
|
On 07/02/2012 11:43 AM, Lorenzo Bettini wrote:
> On 06/30/2012 05:29 PM, Thomas Hallgren wrote:
>> On 06/30/2012 04:14 PM, Lorenzo Bettini wrote:
>>
>>>>>
>>>>> in the meantime by adding an advisor node like
>>>>>
>>>>> <cq:advisorNode namePattern=".*" useTargetPlatform="false"/>
>>>>>
>>>> This doesn't look right.
>>>
>>> why is this wrong?
>>>
>> The useTargetPlatform attribute prevents the resolver from using the
>> target platform as source during resolve. I.e. it will not try and find
>> the needed components there. This is sometimes useful when you want to
>> force Bucky to resolve from an external source (to find updates) rather
>> than be happy with what it finds in the TP. The TP will still receive
>> binary components during materialization.
>
> Hi Thomas
>
> from the book I understood:
>
> useTargetPlatform
> "Target Platform
> Should components found in the target
> platform be used."
>
> if false then it won't use the current target platform to find components, but once the tp is materialized it won't
> search for updates in the subsequent materializations
>
That's correct.
> useMaterialization
> "Materialization
> Should Buckminster materializations
> be used (i.e. things previously downloaded)."
>
> skip earlier materializations in preference of contacting repositories again, "to find updates"
>
That applies to materialization that do not end up in your target platform or as projects in your workspace. I.e.
materializations that are not plug-ins but other types of artifacts that you might be using (maven jars for instance).
> while you say that also using useTargetPlatform="false" it will always search for updates?
>
I say that useTargetPlatform="false" means don't scan target platform during resolve. When useTargetPlatform="true"
(which is the default) then the resolver will consider a match found there as the one to use. I.e. Once a match is found
in the TP, it will not continue the search using locations found in the rmap so even if more recent plug-ins has been
published they will not be found as long as the target platform contains an older version that fulfills the
requirements. Setting it to false forces the rmap locations to be searched.
- thomas
|
|
|
| Re: materialize projects-platform.cquery in eclipse [message #893022 is a reply to message #893016] |
Mon, 02 July 2012 10:37 |
|
On 07/02/2012 12:03 PM, Thomas Hallgren wrote:
> On 07/02/2012 11:43 AM, Lorenzo Bettini wrote:
>> On 06/30/2012 05:29 PM, Thomas Hallgren wrote:
>>> On 06/30/2012 04:14 PM, Lorenzo Bettini wrote:
>>>
>>>>>>
>>>>>> in the meantime by adding an advisor node like
>>>>>>
>>>>>> <cq:advisorNode namePattern=".*" useTargetPlatform="false"/>
>>>>>>
>>>>> This doesn't look right.
>>>>
>>>> why is this wrong?
>>>>
>>> The useTargetPlatform attribute prevents the resolver from using the
>>> target platform as source during resolve. I.e. it will not try and find
>>> the needed components there. This is sometimes useful when you want to
>>> force Bucky to resolve from an external source (to find updates) rather
>>> than be happy with what it finds in the TP. The TP will still receive
>>> binary components during materialization.
>>
>> Hi Thomas
>>
>> from the book I understood:
>>
>> useTargetPlatform
>> "Target Platform
>> Should components found in the target
>> platform be used."
>>
>> if false then it won't use the current target platform to find
>> components, but once the tp is materialized it won't
>> search for updates in the subsequent materializations
>>
> That's correct.
>
>> useMaterialization
>> "Materialization
>> Should Buckminster materializations
>> be used (i.e. things previously downloaded)."
>>
>> skip earlier materializations in preference of contacting repositories
>> again, "to find updates"
>>
> That applies to materialization that do not end up in your target
> platform or as projects in your workspace. I.e. materializations that
> are not plug-ins but other types of artifacts that you might be using
> (maven jars for instance).
>
>> while you say that also using useTargetPlatform="false" it will always
>> search for updates?
>>
> I say that useTargetPlatform="false" means don't scan target platform
> during resolve. When useTargetPlatform="true" (which is the default)
> then the resolver will consider a match found there as the one to use.
> I.e. Once a match is found in the TP, it will not continue the search
> using locations found in the rmap so even if more recent plug-ins has
> been published they will not be found as long as the target platform
> contains an older version that fulfills the requirements. Setting it to
> false forces the rmap locations to be searched.
and wouldn't that be good? Or by "This doesn't look right" you meant
that useTargetPlatform="false" did not get me what I needed?
thanks in advance
cheers
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: materialize projects-platform.cquery in eclipse [message #893029 is a reply to message #893022] |
Mon, 02 July 2012 11:12 |
|
On 07/02/2012 12:37 PM, Lorenzo Bettini wrote:
> On 07/02/2012 12:03 PM, Thomas Hallgren wrote:
>
> and wouldn't that be good? Or by "This doesn't look right" you meant that useTargetPlatform="false" did not get me what
> I needed?
>
Yes. Your problem was that you wanted to control over the TP and separate it from your runtime. This option doesn't help
you do that.
- thomas
|
|
| |
| Re: materialize projects-platform.cquery in eclipse [message #977905 is a reply to message #977848] |
Fri, 09 November 2012 17:25 |
|
sorry for the question, but did you also add an empty directory to the
new empty target platform?
see http://wiki.eclipse.org/Extending_or_Contributing_to_Buckminster
and also the screenshots here
http://www.lorenzobettini.it/2012/11/materializing-and-provisioning-your-target-platform-as-local-p2-site-with-buckminster/
hope this helps
Lorenzo
On 11/09/2012 05:26 PM, William Saar wrote:
> Hi! I have tried specifying an empty target platform called "tp" in the
> Eclipse GUI and setting it as active before running a materialization,
> but Buckminster still creates a new target platform that includes my
> local Eclipse installation and does not download the Eclipse target
> installation that I have specified in the rmap.
> It seems to work from the command line or if I use an mspec, but is that
> really necessary to make Buckminster ignore my local Eclipse installation?
>
> Thomas Hallgren wrote on Sat, 30 June 2012 09:24
>> From the command line. To do the same thin in the Eclipse IDE you will
>> need to use the "Preferences" -> "Plug-in Development" -> "Target
>> Platform" preference page to set up a new target platform.
>
>
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| |
Goto Forum:
Current Time: Thu Dec 26 10:11:30 GMT 2024
Powered by FUDForum. Page generated in 0.04484 seconds |
] 
Search
Help
Register
Login
Home
