Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster dev » [buckminster-dev] Different builds using Buckminster
[buckminster-dev] Different builds using Buckminster [message #17040] Thu, 22 May 2008 15:46 Go to next message
Mikhail Kadan is currently offline Mikhail KadanFriend
Messages: 61
Registered: July 2009
Member
------=_Part_5704_28051158.1211471168801
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi.

Let's assume such situation: I have some Eclipse plugins in SVN in source
form. I need to gather them together to compose a working project.

I can easily get them all in my workspace using simple CQUERY. It will be
perfect for our developers team, as they need to see all the sources and
need to modify them often.

But we also have customization team, which don't need all of the source
projects in the workspace - it would be preferable for them to pack each
project into jar, include sources in it (for debugging purposes, but not for
modification) and put all this jars somewhere together, so the project will
be composed properly, but there will be minimal set of subprojects in the
workspace.

Is it possible to complete with Buckminster? I've read Buckminster
documentation, but only way to partially complete this seems to add action
to each Eclipse plugin (using CSPEX), which will create .jar from plugin
(and include sources in it). I have two questions then:
1) How can I call this action automatically? I think maybe "pre-bind" action
will work there?
1) How can I gather this jars together or make Eclipse understand where to
look for them? Is there any standart implementation for this?

Thanks.

------=_Part_5704_28051158.1211471168801
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi.<br><br>Let&#39;s assume such situation: I have some Eclipse plugins in SVN in source form. I need to gather them together to compose a working project.<br><br>I can easily get them all in my workspace using simple CQUERY. It will be perfect for our developers team, as they need to see all the sources and need to modify them often. <br>
<br>But we also have customization team, which don&#39;t need all of the source projects in the workspace - it would be preferable for them to pack each project into jar, include sources in it (for debugging purposes, but not for modification) and put all this jars somewhere together, so the project will be composed properly, but there will be minimal set of subprojects in the workspace.<br>
<br>Is it possible to complete with Buckminster? I&#39;ve read Buckminster documentation, but only way to partially complete this seems to add action to each Eclipse plugin (using CSPEX), which will create .jar from plugin (and include sources in it). I have two questions then:<br>
1) How&nbsp;can I call this action automatically? I think maybe &quot;pre-bind&quot; action will work there? <br>1) How can I gather this jars together or make Eclipse understand where to look for them? Is there any standart implementation for this? <br>
<br>Thanks.<br>

------=_Part_5704_28051158.1211471168801--
Re: [buckminster-dev] Different builds using Buckminster [message #17099 is a reply to message #17040] Thu, 22 May 2008 18:14 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Mikhail,
One way of accomplishing what you talk about here is to maintain an
update site where you publish some stable collection of the plug-ins
that you develop. You can then use an RMAP that appoints this update
site using a reader of type "eclipse.import". What it does is
essentially importing the binary plug-ins into your workspace.

Another way to resolve this is to define a target platform that is
pre-configured with the binaries and have the customization team use
that target platform as the base for their builds.

The sources is a different matter. Buckminster doesn't provide any
special support for creating jars with sources in them. I would
recommend that you do this the same way it's done by the Eclipse
platform. They create specific source bundles that use an extension
point to automatically connect the respective sources to their
corresponding binary.

Regards,
Thomas Hallgren


Mikhail Kadan wrote:
> Hi.
>
> Let's assume such situation: I have some Eclipse plugins in SVN in
> source form. I need to gather them together to compose a working project.
>
> I can easily get them all in my workspace using simple CQUERY. It will
> be perfect for our developers team, as they need to see all the sources
> and need to modify them often.
>
> But we also have customization team, which don't need all of the source
> projects in the workspace - it would be preferable for them to pack each
> project into jar, include sources in it (for debugging purposes, but not
> for modification) and put all this jars somewhere together, so the
> project will be composed properly, but there will be minimal set of
> subprojects in the workspace.
>
> Is it possible to complete with Buckminster? I've read Buckminster
> documentation, but only way to partially complete this seems to add
> action to each Eclipse plugin (using CSPEX), which will create .jar from
> plugin (and include sources in it). I have two questions then:
> 1) How can I call this action automatically? I think maybe "pre-bind"
> action will work there?
> 1) How can I gather this jars together or make Eclipse understand where
> to look for them? Is there any standart implementation for this?
>
> Thanks.
Re: [buckminster-dev] Different builds using Buckminster [message #17242 is a reply to message #17040] Fri, 23 May 2008 09:03 Go to previous messageGo to next message
Mikhail Kadan is currently offline Mikhail KadanFriend
Messages: 61
Registered: July 2009
Member
------=_Part_7820_690577.1211533405599
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi.

I understood your approaches, but both of them are similar in one way - I
have to manually package my sources into jars, and then feed them to
Updater/target platform, to be sure they have actual code.Of course this can
be performed automatically for example on night build.

But I wanted to know, is there a possibility to implement such a behaviour
using Buckminster:
1) take all sources from SVN (so the most actual sources are taken)
2) put some of them to local workspace (which sources to put must be marked
somehow)
3) package the rest to jars
4) put this jars to target platform or somewhere else (it doesn't matter) -
the reason of this step is to make them somehow VISIBLE to Ecipse

Thanks.

2008/5/22, Thomas Hallgren <thomas@tada.se>:
>
> Hi Mikhail,
> One way of accomplishing what you talk about here is to maintain an update
> site where you publish some stable collection of the plug-ins that you
> develop. You can then use an RMAP that appoints this update site using a
> reader of type "eclipse.import". What it does is essentially importing the
> binary plug-ins into your workspace.
>
> Another way to resolve this is to define a target platform that is
> pre-configured with the binaries and have the customization team use that
> target platform as the base for their builds.
>
> The sources is a different matter. Buckminster doesn't provide any special
> support for creating jars with sources in them. I would recommend that you
> do this the same way it's done by the Eclipse platform. They create specific
> source bundles that use an extension point to automatically connect the
> respective sources to their corresponding binary.
>
> Regards,
> Thomas Hallgren
>
>
> Mikhail Kadan wrote:
>
>> Hi.
>>
>> Let's assume such situation: I have some Eclipse plugins in SVN in source
>> form. I need to gather them together to compose a working project.
>>
>> I can easily get them all in my workspace using simple CQUERY. It will be
>> perfect for our developers team, as they need to see all the sources and
>> need to modify them often.
>>
>> But we also have customization team, which don't need all of the source
>> projects in the workspace - it would be preferable for them to pack each
>> project into jar, include sources in it (for debugging purposes, but not for
>> modification) and put all this jars somewhere together, so the project will
>> be composed properly, but there will be minimal set of subprojects in the
>> workspace.
>>
>> Is it possible to complete with Buckminster? I've read Buckminster
>> documentation, but only way to partially complete this seems to add action
>> to each Eclipse plugin (using CSPEX), which will create .jar from plugin
>> (and include sources in it). I have two questions then:
>> 1) How can I call this action automatically? I think maybe "pre-bind"
>> action will work there?
>> 1) How can I gather this jars together or make Eclipse understand where to
>> look for them? Is there any standart implementation for this?
>>
>> Thanks.
>>
>
> _______________________________________________
> buckminster-dev mailing list
> buckminster-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
>

------=_Part_7820_690577.1211533405599
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi.<br><br>I understood your approaches, but both of them are similar in one way - I have to manually package my sources into jars, and then feed them to Updater/target platform, to be sure they have actual code.Of course this&nbsp;can be performed automatically for example on night&nbsp;build.<br>
<br>But I wanted to know, is there a possibility to implement such a behaviour using Buckminster: <br>1) take all sources from SVN (so the most actual sources are taken)<br>2) put some of them to local workspace (which sources to put must be marked somehow) <br>
3) package the rest to jars<br>4) put this jars to target platform or somewhere else (it doesn&#39;t matter) - the reason of this step is to make them somehow VISIBLE to Ecipse<br><br>Thanks.<br><br><div><span class="gmail_quote">2008/5/22, Thomas Hallgren &lt;<a href="mailto:thomas@tada.se" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">thomas@tada.se</a>&gt;:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Hi Mikhail,<br> One way of accomplishing what you talk about here is to maintain an update site where you publish some stable collection of the plug-ins that you develop. You can then use an RMAP that appoints this update site using a reader of type &quot;eclipse.import&quot;. What it does is essentially importing the binary plug-ins into your workspace.<br>
<br> Another way to resolve this is to define a target platform that is pre-configured with the binaries and have the customization team use that target platform as the base for their builds.<br><br> The sources is a different matter. Buckminster doesn&#39;t provide any special support for creating jars with sources in them. I would recommend that you do this the same way it&#39;s done by the Eclipse platform. They create specific source bundles that use an extension point to automatically connect the respective sources to their corresponding binary.<br>
<br> Regards,<br> Thomas Hallgren<div><span><br><br><br> Mikhail Kadan wrote:<br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Hi.<br><br> Let&#39;s assume such situation: I have some Eclipse plugins in SVN in source form. I need to gather them together to compose a working project.<br><br> I can easily get them all in my workspace using simple CQUERY. It will be perfect for our developers team, as they need to see all the sources and need to modify them often.<br>
<br> But we also have customization team, which don&#39;t need all of the source projects in the workspace - it would be preferable for them to pack each project into jar, include sources in it (for debugging purposes, but not for modification) and put all this jars somewhere together, so the project will be composed properly, but there will be minimal set of subprojects in the workspace.<br>
<br> Is it possible to complete with Buckminster? I&#39;ve read Buckminster documentation, but only way to partially complete this seems to add action to each Eclipse plugin (using CSPEX), which will create .jar from plugin (and include sources in it). I have two questions then:<br>
1) How can I call this action automatically? I think maybe &quot;pre-bind&quot; action will work there?<br> 1) How can I gather this jars together or make Eclipse understand where to look for them? Is there any standart implementation for this?<br>
<br> Thanks.<br></blockquote><br></span></div> _______________________________________________<br> buckminster-dev mailing list<br><a href="mailto:buckminster-dev@eclipse.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">buckminster-dev@eclipse.org</a><br>
<a href="https://dev.eclipse.org/mailman/listinfo/buckminster-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://dev.eclipse.org/mailman/listinfo/buckminster-dev</a><br></blockquote></div>
<br>

------=_Part_7820_690577.1211533405599--
Re: [buckminster-dev] Different builds using Buckminster [message #17322 is a reply to message #17242] Fri, 23 May 2008 10:53 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Mikhail Kadan wrote:
> Hi.
>
> I understood your approaches, but both of them are similar in one way -
> I have to manually package my sources into jars, and then feed them to
> Updater/target platform, to be sure they have actual code.Of course
> this can be performed automatically for example on night build.
>
> But I wanted to know, is there a possibility to implement such a
> behaviour using Buckminster:
> 1) take all sources from SVN (so the most actual sources are taken)
> 2) put some of them to local workspace (which sources to put must be
> marked somehow)
> 3) package the rest to jars
> 4) put this jars to target platform or somewhere else (it doesn't
> matter) - the reason of this step is to make them somehow VISIBLE to Ecipse
>
I would suggest that you create a top-level component that contains a
buckminster.cspec and an ant build script.

You let the buckminster.cspec list dependencies to all the bundles that
you want to include and you then create an action that collects their
sources into a jar. The prerequisites to this action must list the
'eclipse.build.source' of each bundle that you want to include.

The action could look something like this:

<cs:public name="gather.source" actor="ant">
<cs:actorProperties>
<cs:property key="buildFileId" value="buckminster.pdetasks"/>
<cs:property key="targets" value="create.zip"/>
</cs:actorProperties>
<cs:prerequisites alias="action.requirements">
<cs:attribute name="eclipse.build.source" component="x.y.1"/>
<cs:attribute name="eclipse.build.source" component="x.y.2"/>
<cs:attribute name="eclipse.build.source" component="x.y.3"/>
</cs:prerequisites>
<cs:products alias="action.output" base="generated/">
<cs:path path="source.zip"/>
</cs:products>
</cs:public>


This approach requires the absolute latest version of Buckminster found
at http://download.eclipse.org/tools/buckminster/updates-3.4. In
previous versions, the 'eclipse.build.source' attribute was private.

Regards,
Thomas Hallgren



> Thanks.
>
> 2008/5/22, Thomas Hallgren <thomas@tada.se <mailto:thomas@tada.se>>:
>
> Hi Mikhail,
> One way of accomplishing what you talk about here is to maintain an
> update site where you publish some stable collection of the plug-ins
> that you develop. You can then use an RMAP that appoints this update
> site using a reader of type "eclipse.import". What it does is
> essentially importing the binary plug-ins into your workspace.
>
> Another way to resolve this is to define a target platform that is
> pre-configured with the binaries and have the customization team use
> that target platform as the base for their builds.
>
> The sources is a different matter. Buckminster doesn't provide any
> special support for creating jars with sources in them. I would
> recommend that you do this the same way it's done by the Eclipse
> platform. They create specific source bundles that use an extension
> point to automatically connect the respective sources to their
> corresponding binary.
>
> Regards,
> Thomas Hallgren
>
>
>
> Mikhail Kadan wrote:
>
> Hi.
>
> Let's assume such situation: I have some Eclipse plugins in SVN
> in source form. I need to gather them together to compose a
> working project.
>
> I can easily get them all in my workspace using simple CQUERY.
> It will be perfect for our developers team, as they need to see
> all the sources and need to modify them often.
>
> But we also have customization team, which don't need all of the
> source projects in the workspace - it would be preferable for
> them to pack each project into jar, include sources in it (for
> debugging purposes, but not for modification) and put all this
> jars somewhere together, so the project will be composed
> properly, but there will be minimal set of subprojects in the
> workspace.
>
> Is it possible to complete with Buckminster? I've read
> Buckminster documentation, but only way to partially complete
> this seems to add action to each Eclipse plugin (using CSPEX),
> which will create .jar from plugin (and include sources in it).
> I have two questions then:
> 1) How can I call this action automatically? I think maybe
> "pre-bind" action will work there?
> 1) How can I gather this jars together or make Eclipse
> understand where to look for them? Is there any standart
> implementation for this?
>
> Thanks.
>
>
> _______________________________________________
> buckminster-dev mailing list
> buckminster-dev@eclipse.org <mailto:buckminster-dev@eclipse.org>
> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
>
>
Re: [buckminster-dev] Different builds using Buckminster [message #19234 is a reply to message #17242] Wed, 04 June 2008 15:23 Go to previous messageGo to next message
Mikhail Kadan is currently offline Mikhail KadanFriend
Messages: 61
Registered: July 2009
Member
------=_Part_6753_26436958.1212593024970
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi.

I've thought a bit on what I really want and how can I implement it using
Buckminster.

So, let's look into such a situation:
1) I have three plug-ins: "plA", "plB" and "plC", located in SVN.
2) "plA" depends on "plB" and "plC".
3) I've created CQUERY to provide me with "plA" plugin (and all of its
dependencies - that means "plB" and "plC").
4) I resolve this query and get "plA", "plB" and "plC" in my workspace.

Everything is perfect.


Now imagine a situation, where I need ONLY "plA" in my workspace, but the
whole project has to be in working state. That means I have to put "plB" and
"plC" in target platform somehow. To generalize it, I can create such
requirement:

"I have a number of plug-ins in SVN repository. I have a CQUERY, which
provides me with a top-level plug-in and all of its dependencies. In this
CUQERY I have to specify, which plug-ins have to be materialized into my
workspace, and which have to be built and put to target platform".


I've thought how can I implement such a requirement and looked at standard
component action "buckminster.prebind". The idea was that on the phase of
binding plug-in into workspace I can run Ant script (located in
"buckminster.prebind" action of each plug-in), that will determine, whether
this plug-in has to be put into workspace as Eclipse project, or if it has
to be built and put to target platform. My CQUERY, which I use to get
top-level plug-in, can have a number of properties, named for example like
"buckminster.cquery.source.plN", which, if it is present, indicates, that I
have to put "plN" into a workspace.

To implement this behavior I have to know a little more about Buckminster
integration with PDE:
1) How can I export Eclipse plug-in using ant script called in Buckminster
action? I need this to export unnecessary (in my workspace, not in the whole
project) plug-ins to target platform as jars. Is there a standard ant task
for this?
2) How can I tell Buckminster not to import plug-in to workspace using ant
script? I need this to stop Buckminster from importing plug-in, when it
determines that this plug-in has to be exported to target platform, and so
has not to be present in workspace.

Thanks.

------=_Part_6753_26436958.1212593024970
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi.<br><br>I&#39;ve thought a bit on what I really want and how can I implement it using Buckminster.<br><br>So, let&#39;s look into such a situation: <br> 1) I have three plug-ins: &quot;plA&quot;, &quot;plB&quot; and &quot;plC&quot;, located in SVN.<br>
2) &quot;plA&quot; depends on &quot;plB&quot; and &quot;plC&quot;.<br>3) I&#39;ve created CQUERY to provide me with &quot;plA&quot; plugin (and all of its dependencies - that means &quot;plB&quot; and &quot;plC&quot;). <br>
4) I resolve this query and get &quot;plA&quot;, &quot;plB&quot; and &quot;plC&quot; in my workspace.<br><br>Everything is perfect.<br><br><br>Now imagine a situation, where I need ONLY &quot;plA&quot; in my workspace, but the whole project has to be in working state. That means I have to put &quot;plB&quot; and &quot;plC&quot; in target platform somehow. To generalize it, I can create such requirement: <br>
<br>&quot;I have a number of plug-ins in SVN repository. I have a CQUERY, which provides me with a top-level plug-in and all of its dependencies. In this CUQERY I have to specify, which plug-ins have to be materialized into my workspace, and which have to be built and put to target platform&quot;. <br>
<br><br>I&#39;ve thought how can I implement such a requirement and looked at standard component action &quot;buckminster.prebind&quot;. The idea was that on the phase of binding plug-in into workspace I can run Ant script (located in &quot;buckminster.prebind&quot; action of each plug-in), that will determine, whether this plug-in has to be put into workspace as Eclipse project, or if it has to be built and put to target platform. My CQUERY, which I use to get top-level plug-in, can have a number of properties, named for example like &quot;buckminster.cquery.source.plN&quot;, which, if it is present, indicates, that I have to put &quot;plN&quot; into a workspace.<br>
<br>To implement this behavior I have to know a little more about Buckminster integration with PDE:<br>1) How can I export Eclipse plug-in using ant script called in Buckminster action? I need this to export unnecessary (in my workspace, not in the whole project) plug-ins to target platform as jars. Is there a standard ant task for this?<br>
2) How can I tell Buckminster not to import plug-in to workspace using ant script? I need this to stop Buckminster from importing plug-in, when it determines that this plug-in has to be exported to target platform, and so has not to be present in workspace.<br>
<br>Thanks.<br>

------=_Part_6753_26436958.1212593024970--
Re: [buckminster-dev] Different builds using Buckminster [message #19401 is a reply to message #17242] Thu, 05 June 2008 15:01 Go to previous messageGo to next message
Mikhail Kadan is currently offline Mikhail KadanFriend
Messages: 61
Registered: July 2009
Member
------=_Part_2353_2178195.1212678076224
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi.

Worked a little more on this issue. Found another approach, which uses such
a wonderful thing as MSPEC :)
So, back to our situation with "plA", "plB" and "plC". "plA" depends on
"plB" and "plC". I want to materialize "plA" and "plB" to my workspace, and
put "plC" to target platform.

I've read a small tutorial here:
http://dev.eclipse.org/newslists/news.eclipse.technology.buc kminster/msg00516.html
Based on it, I've created MSPEC:
<mspec ... materializer="workspace">
<mspecNode namePattern="^\QplA\E$" materializer="filesystem"
installLocation="c:/temp"/>
<mspecNode namePattern="^\QplB\E$" materializer="filesystem"
installLocation="c:/temp"/>
</mspec>

When I resolve it, I get "plA" and "plB" in my workspace, and "plC" in
desired location ("c:/temp" in this case).
Just what I needed. Almost.

Q1: My target platform location ("installLocation" in MSPEC) has to be set
to "{target.location}" Buckminster property (which points to current target
platform I guess) instead of hardcoded to "c:/temp". How can this be done?

Q2: Can I automatically package plugins into jars when materializing to
filesystem? I've found "unpack" node, but unfortunately not a "pack" one :'(

Q3: How can I automatically "Reload" target platform, after I have
materialized all the plugins to let Eclipse know that they have changed?
This I think have to be roughly equivalent to pressing "Reload" button on
"Preferences -> Plug-in Development -> Target Platform" page. Is there an
Ant task for this or I have to create my own?

Q4: What exactly is "targetPlatform" materializer and how it can be used?
I've tried to specify it and always got an error:
[0000] : Unable to obtain URI for plC:osgi.bundle$1.0.0#OSGi

Thanks.


ps Found a strange issue also. Maybe a bug. Let's compare two MSPECs in the
described earlier context of "plA", "plB" and "plC":

1:
<mspec ... materializer="workspace">
<mspecNode namePattern="^\QplC\E$" materializer="filesystem"
installLocation="c:/temp"/>
</mspec>

2:
<mspec ... materializer="filesystem" installLocation="c:/temp">
<mspecNode namePattern="^\QplA\E$" materializer="workspace"/>
<mspecNode namePattern="^\QplB\E$" materializer="workspace"/>
</mspec>

At first glance they are to made to perform similar actions:
1) "plA" and "plB" are materialized to workspace and then imported;
2) "plC" is materialized to filesystem;

MSPEC #1 does exatly this. While MSPEC #2 behaviour is different: it
meterialized ALL the plugins to filesystem, and then imports required to
workspace without copying source code. So, after execution of MSPEC #1 I
have two places where plugins are located: my "{workspace}/plugins" folder
and "{installLocation}" folder. After MSPEC #2 all my plugins are located in
"{installLocation}" folder and then some of them are imported to my
workspace without copying source.
Is this the right behaviour?

------=_Part_2353_2178195.1212678076224
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi.<br><br>Worked a little more on this issue. Found another approach, which uses such a wonderful thing as MSPEC :)<br>So, back to our situation with &quot;plA&quot;, &quot;plB&quot; and &quot;plC&quot;. &quot;plA&quot; depends on &quot;plB&quot; and &quot;plC&quot;. I want to materialize &quot;plA&quot; and &quot;plB&quot; to my workspace, and put &quot;plC&quot; to target platform.<br>
<br>I&#39;ve read a small tutorial here: <a href=" http://dev.eclipse.org/newslists/news.eclipse.technology.buc kminster/msg00516.html"> http://dev.eclipse.org/newslists/news.eclipse.technology.buc kminster/msg00516.html</a><br>
Based on it, I&#39;ve created MSPEC:<br>&lt;mspec ... materializer=&quot;workspace&quot;&gt;<br> &nbsp;&nbsp;&nbsp;&lt;mspecNode namePattern=&quot;^\QplA\E$&quot; materializer=&quot;filesystem&quot; installLocation=&quot;c:/temp&quot;/&gt;<br>
&nbsp;&nbsp;&nbsp;&lt;mspecNode namePattern=&quot;^\QplB\E$&quot; materializer=&quot;filesystem&quot; installLocation=&quot;c:/temp&quot;/&gt;<br>&lt;/mspec&gt; <br><br>When I resolve it, I get &quot;plA&quot; and &quot;plB&quot; in my workspace, and &quot;plC&quot; in desired location (&quot;c:/temp&quot; in this case).<br>
Just what I needed. Almost.<br><br>Q1: My target platform location (&quot;installLocation&quot; in MSPEC) has to be set to &quot;{target.location}&quot; Buckminster property (which points to current target platform I guess) instead of hardcoded to &quot;c:/temp&quot;. How can this be done?<br>
<br>Q2: Can I automatically package plugins into jars when materializing to filesystem? I&#39;ve found &quot;unpack&quot; node, but unfortunately not a &quot;pack&quot; one :&#39;(<br><br>Q3: How can I automatically &quot;Reload&quot; target platform, after I have materialized all the plugins to let Eclipse know that they have changed? This I think have to be roughly equivalent to pressing &quot;Reload&quot; button on &quot;Preferences -&gt; Plug-in Development -&gt; Target Platform&quot; page. Is there an Ant task for this or I have to create my own?<br>
<br>Q4: What exactly is &quot;targetPlatform&quot; materializer and how it can be used? I&#39;ve tried to specify it and always got an error:<br> [0000] : Unable to obtain URI for plC:osgi.bundle$1.0.0#OSGi<br><br>Thanks.<br>
<br><br>ps Found a strange issue also. Maybe a bug. Let&#39;s compare two MSPECs in the described earlier context of &quot;plA&quot;, &quot;plB&quot; and &quot;plC&quot;:<br><br>1:<br>&lt;mspec ... materializer=&quot;workspace&quot;&gt;<br>
&lt;mspecNode namePattern=&quot;^\QplC\E$&quot; materializer=&quot;filesystem&quot; installLocation=&quot;c:/temp&quot;/&gt;<br>&lt;/mspec&gt; <br><br>2:<br>&lt;mspec ... materializer=&quot;filesystem&quot; installLocation=&quot;c:/temp&quot;&gt;<br>
&lt;mspecNode namePattern=&quot;^\QplA\E$&quot; materializer=&quot;workspace&quot;/&gt;<br> &lt;mspecNode namePattern=&quot;^\QplB\E$&quot; materializer=&quot;workspace&quot;/&gt;<br>&lt;/mspec&gt; <br><br>At first glance they are to made to perform similar actions:<br>
1) &quot;plA&quot; and &quot;plB&quot; are materialized to workspace and then imported;<br>2) &quot;plC&quot; is materialized to filesystem;<br><br>MSPEC #1 does exatly this. While MSPEC #2 behaviour is different: it meterialized ALL the plugins to filesystem, and then imports required to workspace without copying source code. So, after execution of MSPEC #1 I have two places where plugins are located: my &quot;{workspace}/plugins&quot; folder and &quot;{installLocation}&quot; folder. After MSPEC #2 all my plugins are located in &quot;{installLocation}&quot; folder and then some of them are imported to my workspace without copying source.<br>
Is this the right behaviour?<br><br>

------=_Part_2353_2178195.1212678076224--
Re: [buckminster-dev] Different builds using Buckminster [message #19448 is a reply to message #17242] Thu, 05 June 2008 15:56 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Mikhail,

Mikhail Kadan wrote:
> Q1: My target platform location ("installLocation" in MSPEC) has to be
> set to "{target.location}" Buckminster property (which points to
> current target platform I guess) instead of hardcoded to "c:/temp".
> How can this be done?
You should use materializer="targetPlatform" and the installLocation
should either be null (in which case you get the target platform of the
installer) or an absolute path pointing to a valid target platform.

>
> Q2: Can I automatically package plugins into jars when materializing
> to filesystem? I've found "unpack" node, but unfortunately not a
> "pack" one :'(
Not sure I understand. The plug-in *is* a jar when you download it. If
you don't unpack, it will remain a jar.

>
> Q3: How can I automatically "Reload" target platform, after I have
> materialized all the plugins to let Eclipse know that they have
> changed? This I think have to be roughly equivalent to pressing
> "Reload" button on "Preferences -> Plug-in Development -> Target
> Platform" page. Is there an Ant task for this or I have to create my own?
>
I think you need to create your own ant-task for this. I would consider
it a good contribution to Buckminster if you'd like to submit a patch.

> Q4: What exactly is "targetPlatform" materializer and how it can be
> used? I've tried to specify it and always got an error:
> [0000] : Unable to obtain URI for plC:osgi.bundle$1.0.0#OSGi
>
The targetPlatform materializer will use the update manager (the old one
at present) to install features or free-standing plug-ins into the
designated target platform. I'm not sure why you get the error you get.
What is plC in this case and how was it obtained?

Regards,
Thomas Hallgren
Re: [buckminster-dev] Different builds using Buckminster [message #19493 is a reply to message #17242] Fri, 06 June 2008 22:05 Go to previous message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Mikhail Kadan wrote:
> > Not sure I understand. The plug-in *is* a jar when you download it. If
> > you don't unpack, it will remain a jar.
>
> In general yes, its true. But our plugins are located in SVN as sources.
> So there is a need to package them automatically.
>
In that case a full build is necessary. You can't really put sources
directly into the target platform. You need to use the workspace in
order to run the build.

Regards,
Thomas Hallgren
Previous Topic:Re: [buckminster-dev] 3.4 headless site a bit unwell?
Next Topic:Headless Buckminster for 3.4
Goto Forum:
  


Current Time: Tue Mar 19 08:15:02 GMT 2024

Powered by FUDForum. Page generated in 0.03721 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top