Home » Modeling » EMF » [oomph] adding new setup will not add git repositories to view
| [oomph] adding new setup will not add git repositories to view [message #1269137] |
Tue, 11 March 2014 12:41  |
 Marco Descher
Messages: 198
Registered: October 2010
Location: Austria |
Senior Member |
|
|
Hy,
first of all thanks for your great tool. I am however having some problems getting the hang of it:
I created a setup with a git repo of my own project, and the git repository is cloned. Also the working set i selected is configured. I can't seem to get my repository shown in the git repositories view, however and none of the projects located in the repository actually gets included into Eclipse and hence shown in the working set?
Where in your setup model is this supposed to happen?! I could not find a hing in releng.set and platform.setup as there it simply seems enought to have the git repository cloned.
thanks for your help!
[Updated on: Tue, 11 March 2014 12:42] Report message to a moderator |
|
|
| Re: [oomph] adding new setup will not add git repositories to view [message #1269192 is a reply to message #1269137] |
Tue, 11 March 2014 13:56  |
|
Hi Marco,
The platform.setup model has been authored by Ed, so he may want to comment on that. The (CDO) releng.setup model uses a
"TargletTask" to provision both the target platform and the workspace.
Note that the GitCloneTask uses JGit and I don't think that it adds the cloned repo to EGit's repositories view. But
EGit would add it implicitely when you import projects from there (the TargletTask typically does this). I'm not sure
but this bug might be related: https://bugs.eclipse.org/bugs/show_bug.cgi?id=428584
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 11.03.2014 13:41, schrieb Marco Descher:
> Hy,
>
> first of all thanks for your great tool. I am however having some problems getting the hang of it:
>
> I created a setup with a git repo of my own project, and the git repository is cloned. Also the working set i selected
> is configured. I can't seem to get my repository shown in the git repositories view, however and none of the projects
> located in the repository actually gets included into Eclipse and hence shown in the working set?
>
> Where in your setup model is this supposed to happen?! I could not find a hing in releng.set and platform.setup as
> there it simply seems enought to have the git repository cloned.
>
> thanks for your help!
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [oomph] adding new setup will not add git repositories to view [message #1269239 is a reply to message #1269137] |
Tue, 11 March 2014 15:19 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Marco,
Comments below.
On 11/03/2014 1:41 PM, Marco Descher wrote:
> Hy,
>
> first of all thanks for your great tool. I am however having some
> problems getting the hang of it:
>
> I created a setup with a git repo of my own project, and the git
> repository is cloned. Also the working set i selected is configured. I
> can't seem to get my repository shown in the git repositories view,
> however and none of the projects located in the repository actually
> gets included into Eclipse and hence shown in the working set?
As Eike mentions, the repos should be added automatically when a project
is imported into the workspace for something in that clone. It doesn't
sound like you have a task that does this this step. As Eike mentions,
you can could use his newer Targelet task for this purpose, or the older
(Buckminster-based) Materialization task. In either case, you'd
specify root install units you want and automatic source locators and
repos in which to find those units. Things found in the source locators
will end up in the workspace and the rest will end up in the target
platform. Here's the XML for CDO.Releng's targelet task:
<setupTasks xsi:type="setup:TargletTask" name="CDO Releng">
<roots id="org.eclipse.emf.cdo.releng.all.feature.group"/>
<roots id="org.eclipse.emf.cdo.releng.release"/>
<sourceLocators rootFolder="${git.clone}">
<predicates xsi:type="predicates:NotPredicate">
<operand xsi:type="predicates:NamePredicate"
pattern="org\.eclipse\.net4j.*"/>
</predicates>
</sourceLocators>
<repositoryLists name="Luna Dependencies">
<p2Repositories
url="http://hudson.eclipse.org/hudson/job/emf-cdo-integration/lastSuccessfulBuild/artifact"/>
<p2Repositories
url="http://download.eclipse.org/eclipse/updates/4.4milestones"/>
<p2Repositories
url="http://download.eclipse.org/modeling/emf/emf/updates/2.10milestones"/>
<p2Repositories
url="http://download.eclipse.org/modeling/emf/cdo/orbit/latest-S"/>
<p2Repositories
url="http://download.eclipse.org/tools/buckminster/updates-4.3"/>
<p2Repositories
url="http://download.eclipse.org/tools/gef/updates/milestones"/>
<p2Repositories url="http://download.eclipse.org/egit/updates"/>
<p2Repositories
url="http://download.eclipse.org/mylyn/snapshots/weekly"/>
<p2Repositories
url="http://download.eclipse.org/technology/nebula/snapshot"/>
</repositoryLists>
</setupTasks>
Note how it specifies the root IDs and location of the folder into which
the clone was placed, and then a bunch of repos where to find other
dependencies. This combination induces a workspace and a target
platform. The Materialization task works similarly, but when writing
something new, I'd suggest going with a Targlet task. Targlets
themselves quite nicely integrated with the PDE...
>
> Where in your setup model is this supposed to happen?! I could not
> find a hing in releng.set and platform.setup as there it simply seems
> enought to have the git repository cloned.
>
> thanks for your help!
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [oomph] adding new setup will not add git repositories to view [message #1269416 is a reply to message #1269239] |
Tue, 11 March 2014 21:13 |
Marco Descher
Messages: 198
Registered: October 2010
Location: Austria |
Senior Member |
|
|
Thank you very much for the explanation! It starts making sense now! So if I use the Targlet approach to populate my workspace, is there any method to use and integrate an already existing *.target file I have within this source?
Because currently I am forced to provide an Installable Unit (as part of the Targlet Task definition), which will effectively create a new Target afai understand your explanation?! I want to stick to the target file because it is also used in the Tycho build and use the Targlet to populate the workspace only?!
Can I realize this scenario?
[Updated on: Tue, 11 March 2014 21:14] Report message to a moderator |
|
|
| Re: [oomph] adding new setup will not add git repositories to view [message #1269777 is a reply to message #1269416] |
Wed, 12 March 2014 07:19 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Marco,
Comments below.
On 11/03/2014 10:13 PM, Marco Descher wrote:
> Thank you very much for the explanation! It starts making sense now!
> So if I use the Targlet approach to populate my workspace, is there
> any method to use and integrate an already existing *.target file I
> have within this source?
Yes and no. A targlet is like a *.target except that it helps
materialize both the target platform and the workspace. Of course if
you look at a *.target file, it's essentially a list of IUs and
repositories, so using that same information in a targlet that you have
in your *.target accomplishes the same goal, with the advantage that it
uses a bundle pool shared across workspaces and shared with the
installed IDEs themselves, so performs better. The Materialization
task is similar. So while there is a Target Platform task, that only
works if the *.target being named is in the workspace, i.e., works well
only in combination with a Project Set Import....
>
> Because currently I am forced to provide an Installable Unit, which
> will effectively create a new Target afai understand your explanation?
It creates a well managed, fast-to-update target...
> ! I want to stick to the target file because it is also used in the
> Tycho build and use the Targlet to populate the workspace only?!
Targlet uses p2 to create an overall consistent installation so it
really does check that all dependencies are resolved either in the
workspace or the target platform...
>
> Can I realize this scenario?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | |
| Re: [oomph] adding new setup will not add git repositories to view [message #1269845 is a reply to message #1269777] |
Wed, 12 March 2014 08:45 |
|
I was about to reply to Marco, but you were quicker :P
Some comments below...
Am 12.03.2014 08:19, schrieb Ed Merks:
> Marco,
>
> Comments below.
>
> On 11/03/2014 10:13 PM, Marco Descher wrote:
>> Thank you very much for the explanation! It starts making sense now! So if I use the Targlet approach to populate my
>> workspace, is there any method to use and integrate an already existing *.target file I have within this source?
> Yes and no. A targlet is like a *.target except that it helps materialize both the target platform and the
> workspace. Of course if you look at a *.target file, it's essentially a list of IUs and repositories, so using that
> same information in a targlet that you have in your *.target accomplishes the same goal, with the advantage that it
> uses a bundle pool shared across workspaces and shared with the installed IDEs themselves, so performs better.
To be exact, the distinction is not between "normal" target definitions and targlets. I think it may be helpful to
understand some of the details, so let me explain:
A *target definition* is a PDE concept to define the *content* (features and bundles) of the *target platform*. Note the
cardinalities; there can be only one target platform but multiple definitions, with only one being active at a time).
The content is defined by one or more *locations* in the target definition. Note that in the PDE code these locations
are called "bundle containers". Each such bundle container is of a specific type, typically one of "Feature",
"Directory", "Profile" or "IU". These types correspond to what you see in the target definition editor, see
http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Fpreference_pages%2Ftarget_platform.htm
.. Most target definitions contain only IU-type bundle containers (i.e. "Software Site" locations).
Here are the major issues with the above:
1) PDE creates and maintains one bundle pool for the bundles that are installed through the UI bundle containers of all
target definitions in a *single* workspace. That means that dsik space and -- probably more importantly -- install time
is wasted when you work with multiple workspaces.
2) PDE's IUBundleContainer does NOT allow you to specify version *ranges* for IUs. I.e., you can't specify upper version
limits. But there are situations where that's absolutely needed. A current example is EcoreTools, that has ioncompatible
1.x and 2.x versions in the train.
3) PDE's target definitions know nothing about your sources although your sources are the ultimate root of your
dependency tree. Hence you must re-specify many of your dependencies in the target definition (i.e. the
IUBundleContainer). This results in redundant information with all its drawbacks.
4) PDE's target platform is not modular, i.e., the currently active target definition must be self-contained in a single
..target file. There's no way to compose the TP from multiple .target files. Whenever you want to add to the TP (even if
the addition is only meant to be temporary) you must edit a single file that is typically shared via SCM.
Please note that Buckminster nicel addresses the issues 2, 3 and 4. Unfortunately it adds new issues that I don't want
to outline here (please ask if you're interested in the details).
Our Targlets are an attempt to address all of these issues in PDE and Buckminster. The design is comparingly simple and
straight forward:
- We contribute a new bundle container implementation (type="Targlet") that is fully integrated with PDE's target
platform/definition framework.
- Our TargletBundleContainer contains one *or more* Targlets. Each targlet can be stored in a separate .targlet file,
i.e., it's truely modular (hence the "let" in targlet").
- Each targlet specifies a set of *root* IUs, a set of *source locators* and a set of p2 repos.
- The TargletBundleContainer computes the set of features and bundles to put into the TP by generating an in-memory p2
repository for all located source projects and adding it to the set of p2 repos. Then a single p2 planner call resolves
the dependencies starting from the merged set of root IUs. IUs found in real p2 repos are installed into the TP and IUs
found in the sources are imported as projects into the WS.
- The final installation happens into a TargletBundleContainer-specific profile in a *global* p2 agent/bundle pool. The
TargletBundleContainer is smart enough to keep a "working version" of the profile around in case the planner can't
resolve the current set of targlets inthe container.
- Your source IUs/projects can specify additional (development time) dependencies in special "component.ext" files.
Non-PDE projects can be handled by placing special "component.def" files next to their .project files.
The result is a modular, fast, reliable and redundancy-free target platform ;-)
> The Materialization task is similar. So while there is a Target Platform task, that only works if the *.target being
> named is in the workspace, i.e., works well only in combination with a Project Set Import....
Note that there's a related (simple) feature request: https://bugs.eclipse.org/bugs/show_bug.cgi?id=429246
>>
>> Because currently I am forced to provide an Installable Unit, which will effectively create a new Target afai
>> understand your explanation?
> It creates a well managed, fast-to-update target...
>> ! I want to stick to the target file because it is also used in the Tycho build and use the Targlet to populate the
>> workspace only?!
Others have already pointed out that it's not desirable "these things" separately for the local developement time
workspace (targlets) and for the Tycho build (single .target file). Of course I totally agree with this. IMHO this is
mostly because Tycho doesn't seem to use PDE to deal with its .target file. Tycho seems to parse the .target file itself
and ignore all BundleContainers except for the IUBundleContainers.
As I mentioned above, our targlets fully integrate with PDE, so you can for example save a target definition that
contains a TargletBundleContainer to a .target file (or load it from there). Here's an example, the .target file of
Oomph itself (when exported to the WS):
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?pde version="3.8"?><target name="Modular Target" sequenceNumber="0">
<locations>
<location xmlns:predicates="http://www.eclipse.org/CDO/releng/predicates/1.0"
xmlns:setup="http://www.eclipse.org/CDO/releng/setup/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
id="Oomph" type="Targlet">
<targlet name="CDO Releng" xsi:type="setup:Targlet">
<roots id="org.eclipse.emf.cdo.releng.all.feature.group"/>
<roots id="org.eclipse.emf.cdo.releng.release"/>
<sourceLocators rootFolder="C:\develop\eclipse\cdo.releng\master\git\cdo.releng">
<predicates xsi:type="predicates:NotPredicate">
<operand pattern="org\.eclipse\.net4j.*" xsi:type="predicates:NamePredicate"/>
</predicates>
</sourceLocators>
<repositoryLists name="Luna Dependencies">
<p2Repositories url="http://hudson.eclipse.org/hudson/job/emf-cdo-integration/lastSuccessfulBuild/artifact"/>
<p2Repositories url="http://download.eclipse.org/eclipse/updates/4.4milestones"/>
<p2Repositories url="http://download.eclipse.org/modeling/emf/emf/updates/2.10milestones"/>
<p2Repositories url="http://download.eclipse.org/modeling/emf/cdo/orbit/latest-S"/>
<p2Repositories url="http://download.eclipse.org/tools/buckminster/updates-4.3"/>
<p2Repositories url="http://download.eclipse.org/tools/gef/updates/milestones"/>
<p2Repositories url="http://download.eclipse.org/egit/updates"/>
<p2Repositories url="http://download.eclipse.org/mylyn/snapshots/weekly"/>
<p2Repositories url="http://download.eclipse.org/technology/nebula/snapshot"/>
</repositoryLists>
</targlet>
</location>
</locations>
</target>
So, if Tycho wouldn't ignore all non-IU locations you could probably just use the targlet-basd target definition with
Tycho. I hope that I'll have the chance to talk to those guys during EclipseCon ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> Targlet uses p2 to create an overall consistent installation so it really does check that all dependencies are
> resolved either in the workspace or the target platform...
>>
>> Can I realize this scenario?
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [oomph] adding new setup will not add git repositories to view [message #1269854 is a reply to message #1269807] |
Wed, 12 March 2014 08:55 |
|
Am 12.03.2014 09:05, schrieb Marco Descher:
> Hy Ed,
>
> why do I have to add root IUs for anything in my project? My project is an Eclipse RCP application, so I do not have
> anything that has to go into the target!
> I tried adding a feature out of my source, yet still no projects get included in the workspace :(
>
> This is really confusing me. All I want is to simply import all projects from the github repo into my workspace. I
> don't need a target change at this moment,
> nor do I have something in my source that has to go into the Eclipse target.
>
> So by your explanation a targlet populates both the target and the workspace, and the source locator is for populating
> the workspace?! Or the other way round,
> does a Targlet require a change of Target or is it possible to only populate the workspace?
We are aware that this can be a little confusing if you tend to see the TP and the WS as fundamentally different and
unrelated things. As I tried to explain in my other lengthy post we do think that they are inherently interrelated, more
exactly that the TP is inherently *induced* by things in the WS. Consequently it makes sense to resolve and install them
in one consistent operation. In fact I was thinking a long time about a better name than "Targlet" because that seems to
make your mind focus on TP-only things. But obviously I failed :P
In short, you have basically two choices:
1) Enjoy all the advantages of the targlet-based, holistic approach (and temporarily accept the duplicate maintenance
problem with the "legacy" .target files needed by Tycho).
2) Keep the traditional approach of treating TP and WS totally separatly. Then you need a TargetPlatformTask to import
your .target file. To get the .target file (and all your other source artifacts) into the WS you need a
ProjectSetImportTask or the coming ProjectsImportTask (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=429246 ).
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [oomph] adding new setup will not add git repositories to view [message #1269920 is a reply to message #1269867] |
Wed, 12 March 2014 10:11 |
|
Am 12.03.2014 10:12, schrieb Marco Descher:
> Ok, you got me there to choose option 1 ... yet I do not understand why my workspace is not being populated with the
> projects? Or is this unrelated to the targlet thingy with the EGit bug you reffered to?
I think the cause has been named by Ed already:
"It doesn't look like you specified root IUs for anything in your own projects. Just
org.eclipse.pde.feature.group. I'd expect you do specify the ID of some "root" feature(s) in your source or IDs of the
individual bundles [...]"
Components in the TP never "point" to components in the WS. All dependencies go from WS to TP or stay within the TP.
Consequently the p2 planner/resolver will never "visit" any source components if all your roots are in the TP.
The typical scenario is that your source code (e.g. working tree of the local Git clone) has a very small number
(ideally 1) of root components/features. If you list those as roots in your targlet they and everything they recursively
reference ends up in your WS and your TP, respectively.
Please note that the dependencies specified *in* your bundles and features typically make your projects *compile*
properly, but not necessarily *run* correctly. Typically you need to add a root IU such as
"org.eclipse.sdk.feature.group" to get the additional components into your TP that are needed for a runnable system. You
can't see that so easily in the example cdo.releng.setup model because I decided to specify these things in each bundle
that would need them at runtime separately in component.ext files.
> If I am not allowed to see TP and WS separately, could it be, that if the Targlet is not self-consistent in its
> inter-dependencies no import happens at all?
If all targlets together (often just 1) don't resolve correctly via p2 the TargletConatiner falls back to the last
working set of bundles/features for the TP. I don't think it can fall back to anything during the very initial targlet
specification attempts. But that doesn't seem to be your problem, see above ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [oomph] adding new setup will not add git repositories to view [message #1270039 is a reply to message #1269920] |
Wed, 12 March 2014 12:39 |
Marco Descher
Messages: 198
Registered: October 2010
Location: Austria |
Senior Member |
|
|
Hy Eike,
thanks a lot for the explanation! I could now successfully get the project explorer to be populated. I refer to a master IU in my targlet, that contains a component.def file.
Funny thing is, after deleting every thing and starting again, the workspace is not populated, just as before, although I provide the component.def. The logfile does not even
show the approach to opening the root IU I added.
Next to this (nevermind the populating problem) the following question arised
* I have the projects imported, yet they are not presented as being resource managed by git (the same accounts for the Vex installation target which I used as a simple starter example), why is that? In core.releng they are presented as source managed.
EDIT REMARK: The problem with the non-population was an invalid component.def, nevermind this!
[Updated on: Wed, 12 March 2014 12:45] Report message to a moderator |
|
|
| Re: [oomph] adding new setup will not add git repositories to view [message #1270081 is a reply to message #1269920] |
Wed, 12 March 2014 13:21 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hi,
Very interesting discussion I must say. I read the blog shoe for the
shoemakers, and there the basic idea is to make it easy to contribute to
various Eclipse projects on which many of us depend. This is a good
thing, I have countless cases, that I think. "If I want to work on a bug
for project Z, I need to do this and that..." and finally I don't and
just live with the limitation.
The discussion here (Some of it at least) is how to keep tycho releng
infra working with Oomph. Considering Ed's blog on Oomph, I wonder if
this is really the objective. I now CDO has a very extensive and complex
releng infra, I and wonder how Eike does combine (Or not) Oomph and
..target files which are used by tycho or bucky...
It seems I need to spend more time on releng then on the product itself,
so I would say we are need more shoes!
Cheers Christophe
On 12-03-14 11:11, Eike Stepper wrote:
> Am 12.03.2014 10:12, schrieb Marco Descher:
>> Ok, you got me there to choose option 1 ... yet I do not understand
>> why my workspace is not being populated with the projects? Or is this
>> unrelated to the targlet thingy with the EGit bug you reffered to?
> I think the cause has been named by Ed already:
>
> "It doesn't look like you specified root IUs for anything in your
> own projects. Just org.eclipse.pde.feature.group. I'd expect you do
> specify the ID of some "root" feature(s) in your source or IDs of the
> individual bundles [...]"
>
> Components in the TP never "point" to components in the WS. All
> dependencies go from WS to TP or stay within the TP. Consequently the p2
> planner/resolver will never "visit" any source components if all your
> roots are in the TP.
>
> The typical scenario is that your source code (e.g. working tree of the
> local Git clone) has a very small number (ideally 1) of root
> components/features. If you list those as roots in your targlet they and
> everything they recursively reference ends up in your WS and your TP,
> respectively.
>
> Please note that the dependencies specified *in* your bundles and
> features typically make your projects *compile* properly, but not
> necessarily *run* correctly. Typically you need to add a root IU such as
> "org.eclipse.sdk.feature.group" to get the additional components into
> your TP that are needed for a runnable system. You can't see that so
> easily in the example cdo.releng.setup model because I decided to
> specify these things in each bundle that would need them at runtime
> separately in component.ext files.
>
>
>> If I am not allowed to see TP and WS separately, could it be, that if
>> the Targlet is not self-consistent in its inter-dependencies no import
>> happens at all?
> If all targlets together (often just 1) don't resolve correctly via p2
> the TargletConatiner falls back to the last working set of
> bundles/features for the TP. I don't think it can fall back to anything
> during the very initial targlet specification attempts. But that doesn't
> seem to be your problem, see above ;-)
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
|
|
|
| Re: [oomph] adding new setup will not add git repositories to view [message #1270120 is a reply to message #1270039] |
Wed, 12 March 2014 14:11 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Marco,
Comments below.
On 12/03/2014 1:39 PM, Marco Descher wrote:
> Hy Eike,
>
> thanks a lot for the explanation! I could now successfully get the
> project explorer to be populated. I refer to a master IU in my
> targlet, that contains a component.def file.
> Funny thing is, after deleting every thing and starting again, the
> workspace is not populated, just as before, although I provide the
> component.def.
The isNeeded for TargletTask only checks whether there is a target
definition existing and whether it is active. It does not check if the
target definition is in synch with the underlying p2 repositories nor if
the projects are there in the workspace; especially the former is very
expensive (even with relatively fast internet connections).
Of course at any time you can do a manual update (the little
recycle/refresh button on the toolbar), and choose which tasks you want
to perform. This will run the full task and ensure that the workspace
has what it's supposed to have and that the target platform has the
latest stuff from the underlying p2 repositories.
> The logfile does not even
> show the approach to opening the root IU I added.
>
> Next to this (nevermind the populating problem) the following question
> arised
>
> * I have the projects imported, yet they are not presented as being
> resource managed by git (the same accounts for the Vex installation
> target which I used as a simple starter example), why is that?
A few people have reported that, but we've not been able to reproduce it
ourselves... Which version of egit are you installing? We've always
been using a nightly build...
> In core.releng they are presented as source managed.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [oomph] adding new setup will not add git repositories to view [message #1270129 is a reply to message #1270081] |
Wed, 12 March 2014 14:19 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Christophe,
Comments below.
On 12/03/2014 2:21 PM, Christophe Bouhier wrote:
>
> Hi,
>
> Very interesting discussion I must say. I read the blog shoe for the
> shoemakers, and there the basic idea is to make it easy to contribute
> to various Eclipse projects on which many of us depend. This is a good
> thing, I have countless cases, that I think. "If I want to work on a
> bug for project Z, I need to do this and that..." and finally I don't
> and just live with the limitation.
As long as those projects put in the effort to enable contribution...
We can only hope there will be peer pressure.
>
> The discussion here (Some of it at least) is how to keep tycho releng
> infra working with Oomph.
Yes, we have little experience with that.
> Considering Ed's blog on Oomph, I wonder if this is really the objective.
It's certainly an objective to be flexible... It would seem reasonable
that we provide a task to import projects from a git clone, and there's
already a task to active a *.target file in the workspace, so that's
really all that's needed. But I must say that *.target files are kind
of a mess, and worst of all, they're really not composable, whereas
targlets are designed to be composable... In the end, we don't want to
dictate how people should work but rather provide alternatives that work
reasonably...
> I now CDO has a very extensive and complex releng infra, I and wonder
> how Eike does combine (Or not) Oomph and .target files which are used
> by tycho or bucky...
I don't think he uses *.target files and he's still maintaining his
buckminster artifacts independent of the Oomph setup descriptions...
>
> It seems I need to spend more time on releng then on the product
> itself, so I would say we are need more shoes!
Releng is a nightmare and most folks who go near it end up burned,
including the ones who try to make the next generation improvement to
that disaster area...
>
> Cheers Christophe
>
>
>
> On 12-03-14 11:11, Eike Stepper wrote:
>> Am 12.03.2014 10:12, schrieb Marco Descher:
>>> Ok, you got me there to choose option 1 ... yet I do not understand
>>> why my workspace is not being populated with the projects? Or is this
>>> unrelated to the targlet thingy with the EGit bug you reffered to?
>> I think the cause has been named by Ed already:
>>
>> "It doesn't look like you specified root IUs for anything in your
>> own projects. Just org.eclipse.pde.feature.group. I'd expect you do
>> specify the ID of some "root" feature(s) in your source or IDs of the
>> individual bundles [...]"
>>
>> Components in the TP never "point" to components in the WS. All
>> dependencies go from WS to TP or stay within the TP. Consequently the p2
>> planner/resolver will never "visit" any source components if all your
>> roots are in the TP.
>>
>> The typical scenario is that your source code (e.g. working tree of the
>> local Git clone) has a very small number (ideally 1) of root
>> components/features. If you list those as roots in your targlet they and
>> everything they recursively reference ends up in your WS and your TP,
>> respectively.
>>
>> Please note that the dependencies specified *in* your bundles and
>> features typically make your projects *compile* properly, but not
>> necessarily *run* correctly. Typically you need to add a root IU such as
>> "org.eclipse.sdk.feature.group" to get the additional components into
>> your TP that are needed for a runnable system. You can't see that so
>> easily in the example cdo.releng.setup model because I decided to
>> specify these things in each bundle that would need them at runtime
>> separately in component.ext files.
>>
>>
>>> If I am not allowed to see TP and WS separately, could it be, that if
>>> the Targlet is not self-consistent in its inter-dependencies no import
>>> happens at all?
>> If all targlets together (often just 1) don't resolve correctly via p2
>> the TargletConatiner falls back to the last working set of
>> bundles/features for the TP. I don't think it can fall back to anything
>> during the very initial targlet specification attempts. But that doesn't
>> seem to be your problem, see above ;-)
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: [oomph] adding new setup will not add git repositories to view [message #1270155 is a reply to message #1270129] |
Wed, 12 March 2014 15:01 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
On 12-03-14 15:19, Ed Merks wrote:
> Christophe,
>
> Comments below.
>
> On 12/03/2014 2:21 PM, Christophe Bouhier wrote:
>>
>> Hi,
>>
>> Very interesting discussion I must say. I read the blog shoe for the
>> shoemakers, and there the basic idea is to make it easy to contribute
>> to various Eclipse projects on which many of us depend. This is a good
>> thing, I have countless cases, that I think. "If I want to work on a
>> bug for project Z, I need to do this and that..." and finally I don't
>> and just live with the limitation.
> As long as those projects put in the effort to enable contribution... We
> can only hope there will be peer pressure.
>>
>> The discussion here (Some of it at least) is how to keep tycho releng
>> infra working with Oomph.
> Yes, we have little experience with that.
>> Considering Ed's blog on Oomph, I wonder if this is really the objective.
> It's certainly an objective to be flexible... It would seem reasonable
> that we provide a task to import projects from a git clone, and there's
> already a task to active a *.target file in the workspace, so that's
> really all that's needed. But I must say that *.target files are kind
> of a mess, and worst of all, they're really not composable, whereas
> targlets are designed to be composable... In the end, we don't want to
> dictate how people should work but rather provide alternatives that work
> reasonably...
Not sure what composition means in details here, but I can share my
experience with the .target editor which is really not a good user
experience. I also experience that the cashed plugins for the TP are
some times corrupt and I need to clear the folder, and if you don't have
network connection, don't even think about editing your .target file
(Minding it would include http:// like locations for P2 repos), so yes
an alternative is welcome.
Should tycho have facilities to integrate with Oomph? Or are we heading
to some headless capabilities of Oomph and a Hudson plugin? Just trying
to pickup on the recent thinking on this...
>> I now CDO has a very extensive and complex releng infra, I and wonder
>> how Eike does combine (Or not) Oomph and .target files which are used
>> by tycho or bucky...
> I don't think he uses *.target files and he's still maintaining his
> buckminster artifacts independent of the Oomph setup descriptions...
Once you invest in bucky, it's hard to drop it... (All the time spend I
mean).
>>
>> It seems I need to spend more time on releng then on the product
>> itself, so I would say we are need more shoes!
> Releng is a nightmare and most folks who go near it end up burned,
> including the ones who try to make the next generation improvement to
> that disaster area...
mmmh wonder which project you refer to ;-)
>>
>> Cheers Christophe
>>
>>
>>
>> On 12-03-14 11:11, Eike Stepper wrote:
>>> Am 12.03.2014 10:12, schrieb Marco Descher:
>>>> Ok, you got me there to choose option 1 ... yet I do not understand
>>>> why my workspace is not being populated with the projects? Or is this
>>>> unrelated to the targlet thingy with the EGit bug you reffered to?
>>> I think the cause has been named by Ed already:
>>>
>>> "It doesn't look like you specified root IUs for anything in your
>>> own projects. Just org.eclipse.pde.feature.group. I'd expect you do
>>> specify the ID of some "root" feature(s) in your source or IDs of the
>>> individual bundles [...]"
>>>
>>> Components in the TP never "point" to components in the WS. All
>>> dependencies go from WS to TP or stay within the TP. Consequently the p2
>>> planner/resolver will never "visit" any source components if all your
>>> roots are in the TP.
>>>
>>> The typical scenario is that your source code (e.g. working tree of the
>>> local Git clone) has a very small number (ideally 1) of root
>>> components/features. If you list those as roots in your targlet they and
>>> everything they recursively reference ends up in your WS and your TP,
>>> respectively.
>>>
>>> Please note that the dependencies specified *in* your bundles and
>>> features typically make your projects *compile* properly, but not
>>> necessarily *run* correctly. Typically you need to add a root IU such as
>>> "org.eclipse.sdk.feature.group" to get the additional components into
>>> your TP that are needed for a runnable system. You can't see that so
>>> easily in the example cdo.releng.setup model because I decided to
>>> specify these things in each bundle that would need them at runtime
>>> separately in component.ext files.
>>>
>>>
>>>> If I am not allowed to see TP and WS separately, could it be, that if
>>>> the Targlet is not self-consistent in its inter-dependencies no import
>>>> happens at all?
>>> If all targlets together (often just 1) don't resolve correctly via p2
>>> the TargletConatiner falls back to the last working set of
>>> bundles/features for the TP. I don't think it can fall back to anything
>>> during the very initial targlet specification attempts. But that doesn't
>>> seem to be your problem, see above ;-)
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>
>>
>
|
|
| |
| Re: [oomph] adding new setup will not add git repositories to view [message #1270210 is a reply to message #1270155] |
Wed, 12 March 2014 17:28 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Am 12.03.2014 16:01, schrieb Christophe Bouhier:<br>
<blockquote cite="mid:lfpsrh$q8k$1@xxxxxxxxe.org" type="cite">Not
sure what composition means in details here, but I can share my
experience with the .target editor which is really not a good user
experience. </blockquote>
I tried to explain the differences between target definitions and
targlets in my other lengthy post in this thread. As I intend to
move parts of that to the Oomph/Targlet documentation I'd really
appreciate concrete feedback. Is it understandable?<br>
<br>
<blockquote cite="mid:lfpsrh$q8k$1@xxxxxxxxe.org" type="cite">I
also experience that the cashed plugins for the TP are some times
corrupt and I need to clear the folder,</blockquote>
That is a very severe concern regarding the use of bundle pools!
When one bundle gets corrupt all profiles that include it are
unusable and must be deleted together with the entire pool. To be
honest, this can (easily) happen to not-shared installations, too,
but then the effect is kind of "more local". To increase the trust
in our bundle pools I've recently created a very cool *Bundle Pool
Manager* that is available in the Oomph Installer dialog and in the
Oomph-installed IDE Preferences dialog:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=17722" alt=""><br>
<br>
It detects all pools and scans them for unused or damaged artifacts
and let's you selectively delete (garbage collect) or repair
(re-download) them. Later I plan to add functions such as
re-locating or splitting up pools. I hope that with this visibility
and managebility bundle pools can escape their, well, shadow
existence. They're so powerful.<br>
<br>
<blockquote cite="mid:lfpsrh$q8k$1@xxxxxxxxe.org" type="cite">
and if you don't have network connection, don't even think about
editing your .target file (Minding it would include <a class="moz-txt-link-freetext" href="http://">http://</a> like
locations for P2 repos), so yes an alternative is welcome.
<br>
</blockquote>
That's one of the reasons why we decided not to support IU
*selection*, which would require to load repo meta data. From my
.target times I also remember that I preferred to edit the files
with an XML editor :P<br>
<br>
<blockquote cite="mid:lfpsrh$q8k$1@xxxxxxxxe.org" type="cite">
Should tycho have facilities to integrate with Oomph? </blockquote>
That's what I suggested inmy other post and I hope to have the
chance to talk to some Tycho guys at EclipseCon.<br>
<br>
<blockquote cite="mid:lfpsrh$q8k$1@xxxxxxxxe.org" type="cite">Or
are we heading to some headless capabilities of Oomph and a Hudson
plugin? </blockquote>
In theory that would be imaginable, but for now I prefer to focus on
things that add new value instead of adding yet another build
technology. <br>
<br>
<blockquote cite="mid:lfpsrh$q8k$1@xxxxxxxxe.org" type="cite">Just
trying to pickup on the recent thinking on this...
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">I now CDO has a very extensive and
complex releng infra, I and wonder
<br>
how Eike does combine (Or not) Oomph and .target files which
are used
<br>
by tycho or bucky...
<br>
</blockquote>
I don't think he uses *.target files and he's still maintaining
his
<br>
buckminster artifacts independent of the Oomph setup
descriptions...
<br>
</blockquote>
Once you invest in bucky, it's hard to drop it... (All the time
spend I mean).
<br>
</blockquote>
Yeah, I've spent so much time with it and on it. It's a very
powerful technology but I maintain a growing list of issues. I've
contributed fixes for some of them but it seems unlikely that the
Buckminster team has resources to address the rest of them
(especially the fundamental issue that Buckminster uses an own
resolver that doesn't understand Import-Package). Now that our
Targlets do a very good job in local workspace provisioning I plan
to investigate the use of Tycho for my builds (see
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=427603">https://bugs.eclipse.org/bugs/show_bug.cgi?id=427603</a> ). You see, I
have an own interest in a good Targlet/Tycho integration ;-)<br>
<br>
<blockquote cite="mid:lfpsrh$q8k$1@xxxxxxxxe.org" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<br>
It seems I need to spend more time on releng then on the
product
<br>
itself, so I would say we are need more shoes!
<br>
</blockquote>
Releng is a nightmare and most folks who go near it end up
burned,
<br>
including the ones who try to make the next generation
improvement to
<br>
that disaster area...
<br>
</blockquote>
mmmh wonder which project you refer to ;-)
<br>
</blockquote>
To all :P<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<blockquote cite="mid:lfpsrh$q8k$1@xxxxxxxxe.org" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<br>
Cheers Christophe
<br>
<br>
<br>
<br>
On 12-03-14 11:11, Eike Stepper wrote:
<br>
<blockquote type="cite">Am 12.03.2014 10:12, schrieb Marco
Descher:
<br>
<blockquote type="cite">Ok, you got me there to choose
option 1 ... yet I do not understand
<br>
why my workspace is not being populated with the projects?
Or is this
<br>
unrelated to the targlet thingy with the EGit bug you
reffered to?
<br>
</blockquote>
I think the cause has been named by Ed already:
<br>
<br>
"It doesn't look like you specified root IUs for
anything in your
<br>
own projects. Just org.eclipse.pde.feature.group. I'd
expect you do
<br>
specify the ID of some "root" feature(s) in your source or
IDs of the
<br>
individual bundles [...]"
<br>
<br>
Components in the TP never "point" to components in the WS.
All
<br>
dependencies go from WS to TP or stay within the TP.
Consequently the p2
<br>
planner/resolver will never "visit" any source components if
all your
<br>
roots are in the TP.
<br>
<br>
The typical scenario is that your source code (e.g. working
tree of the
<br>
local Git clone) has a very small number (ideally 1) of root
<br>
components/features. If you list those as roots in your
targlet they and
<br>
everything they recursively reference ends up in your WS and
your TP,
<br>
respectively.
<br>
<br>
Please note that the dependencies specified *in* your
bundles and
<br>
features typically make your projects *compile* properly,
but not
<br>
necessarily *run* correctly. Typically you need to add a
root IU such as
<br>
"org.eclipse.sdk.feature.group" to get the additional
components into
<br>
your TP that are needed for a runnable system. You can't see
that so
<br>
easily in the example cdo.releng.setup model because I
decided to
<br>
specify these things in each bundle that would need them at
runtime
<br>
separately in component.ext files.
<br>
<br>
<br>
<blockquote type="cite">If I am not allowed to see TP and WS
separately, could it be, that if
<br>
the Targlet is not self-consistent in its
inter-dependencies no import
<br>
happens at all?
<br>
</blockquote>
If all targlets together (often just 1) don't resolve
correctly via p2
<br>
the TargletConatiner falls back to the last working set of
<br>
bundles/features for the TP. I don't think it can fall back
to anything
<br>
during the very initial targlet specification attempts. But
that doesn't
<br>
seem to be your problem, see above ;-)
<br>
<br>
Cheers
<br>
/Eike
<br>
<br>
----
<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a>
<br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
Attachment: ggigcjbg.png
(Size: 60.77KB, Downloaded 212 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [oomph] adding new setup will not add git repositories to view [message #1270818 is a reply to message #1270210] |
Thu, 13 March 2014 14:50 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
On 12-03-14 18:28, Eike Stepper wrote:
> Am 12.03.2014 16:01, schrieb Christophe Bouhier:
>> Not sure what composition means in details here, but I can share my
>> experience with the .target editor which is really not a good user
>> experience.
> I tried to explain the differences between target definitions and
> targlets in my other lengthy post in this thread. As I intend to move
> parts of that to the Oomph/Targlet documentation I'd really appreciate
> concrete feedback. Is it understandable?
I'll have another good look.
>
>> I also experience that the cashed plugins for the TP are some times
>> corrupt and I need to clear the folder,
> That is a very severe concern regarding the use of bundle pools! When
> one bundle gets corrupt all profiles that include it are unusable and
> must be deleted together with the entire pool. To be honest, this can
> (easily) happen to not-shared installations, too, but then the effect is
> kind of "more local". To increase the trust in our bundle pools I've
> recently created a very cool *Bundle Pool Manager* that is available in
> the Oomph Installer dialog and in the Oomph-installed IDE Preferences
> dialog:
Wow , x-mas is early this year!
>
>
>
> It detects all pools and scans them for unused or damaged artifacts and
> let's you selectively delete (garbage collect) or repair (re-download)
> them. Later I plan to add functions such as re-locating or splitting up
> pools. I hope that with this visibility and managebility bundle pools
> can escape their, well, shadow existence. They're so powerful.
>
>> and if you don't have network connection, don't even think about
>> editing your .target file (Minding it would include http:// like
>> locations for P2 repos), so yes an alternative is welcome.
> That's one of the reasons why we decided not to support IU *selection*,
> which would require to load repo meta data. From my .target times I also
> remember that I preferred to edit the files with an XML editor :P
Yeah, me too! Good old "open with..."
But.. no IU selection..? This is what I do now in the .target file, I
really need to be selective P2 repo by P2 repo.
>
>> Should tycho have facilities to integrate with Oomph?
> That's what I suggested inmy other post and I hope to have the chance to
> talk to some Tycho guys at EclipseCon.
>
>> Or are we heading to some headless capabilities of Oomph and a Hudson
>> plugin?
> In theory that would be imaginable, but for now I prefer to focus on
> things that add new value instead of adding yet another build technology.
>
>> Just trying to pickup on the recent thinking on this...
>>
>>>> I now CDO has a very extensive and complex releng infra, I and wonder
>>>> how Eike does combine (Or not) Oomph and .target files which are used
>>>> by tycho or bucky...
>>> I don't think he uses *.target files and he's still maintaining his
>>> buckminster artifacts independent of the Oomph setup descriptions...
>> Once you invest in bucky, it's hard to drop it... (All the time spend
>> I mean).
> Yeah, I've spent so much time with it and on it. It's a very powerful
> technology but I maintain a growing list of issues. I've contributed
> fixes for some of them but it seems unlikely that the Buckminster team
> has resources to address the rest of them (especially the fundamental
> issue that Buckminster uses an own resolver that doesn't understand
> Import-Package).Now that our Targlets do a very good job in local
> workspace provisioning I plan to investigate the use of Tycho for my
> builds (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=427603 ). You
> see, I have an own interest in a good Targlet/Tycho integration ;-)
>
I switched to tycho some time ago. Initially it was annoying to define
the Pom.xml on every single artifact. The Maven plugin is good help, but
it doesn't produce tycho pom's though. Also getting the .target file
correct was hard. (See above frustrations on the .target editor). All
with all it seemed more straight forward than buckminster. Some areas
need more figuring out still, like how to update versions and publish
build meta data.
>>>>
>>>> It seems I need to spend more time on releng then on the product
>>>> itself, so I would say we are need more shoes!
>>> Releng is a nightmare and most folks who go near it end up burned,
>>> including the ones who try to make the next generation improvement to
>>> that disaster area...
>> mmmh wonder which project you refer to ;-)
> To all :P
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>>>
>>>> Cheers Christophe
>>>>
>>>>
>>>>
>>>> On 12-03-14 11:11, Eike Stepper wrote:
>>>>> Am 12.03.2014 10:12, schrieb Marco Descher:
>>>>>> Ok, you got me there to choose option 1 ... yet I do not understand
>>>>>> why my workspace is not being populated with the projects? Or is this
>>>>>> unrelated to the targlet thingy with the EGit bug you reffered to?
>>>>> I think the cause has been named by Ed already:
>>>>>
>>>>> "It doesn't look like you specified root IUs for anything in your
>>>>> own projects. Just org.eclipse.pde.feature.group. I'd expect you do
>>>>> specify the ID of some "root" feature(s) in your source or IDs of the
>>>>> individual bundles [...]"
>>>>>
>>>>> Components in the TP never "point" to components in the WS. All
>>>>> dependencies go from WS to TP or stay within the TP. Consequently
>>>>> the p2
>>>>> planner/resolver will never "visit" any source components if all your
>>>>> roots are in the TP.
>>>>>
>>>>> The typical scenario is that your source code (e.g. working tree of
>>>>> the
>>>>> local Git clone) has a very small number (ideally 1) of root
>>>>> components/features. If you list those as roots in your targlet
>>>>> they and
>>>>> everything they recursively reference ends up in your WS and your TP,
>>>>> respectively.
>>>>>
>>>>> Please note that the dependencies specified *in* your bundles and
>>>>> features typically make your projects *compile* properly, but not
>>>>> necessarily *run* correctly. Typically you need to add a root IU
>>>>> such as
>>>>> "org.eclipse.sdk.feature.group" to get the additional components into
>>>>> your TP that are needed for a runnable system. You can't see that so
>>>>> easily in the example cdo.releng.setup model because I decided to
>>>>> specify these things in each bundle that would need them at runtime
>>>>> separately in component.ext files.
>>>>>
>>>>>
>>>>>> If I am not allowed to see TP and WS separately, could it be, that if
>>>>>> the Targlet is not self-consistent in its inter-dependencies no
>>>>>> import
>>>>>> happens at all?
>>>>> If all targlets together (often just 1) don't resolve correctly via p2
>>>>> the TargletConatiner falls back to the last working set of
>>>>> bundles/features for the TP. I don't think it can fall back to
>>>>> anything
>>>>> during the very initial targlet specification attempts. But that
>>>>> doesn't
>>>>> seem to be your problem, see above ;-)
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> ----
>>>>> http://www.esc-net.de
>>>>> http://thegordian.blogspot.com
>>>>> http://twitter.com/eikestepper
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
| |
| Re: [oomph] adding new setup will not add git repositories to view [message #1477049 is a reply to message #1270838] |
Mon, 17 November 2014 15:29 |
Marco Descher
Messages: 198
Registered: October 2010
Location: Austria |
Senior Member |
|
|
Eike,
could you please provide a short example on how to correctly use the TargetPlatformTask? I don't seem to get the properties right; I already have the resp. bundle imported in ws in ch.elexis.target/juno-target.target and the resp. task is part of the master stream. Yet it is not switching to it
<stream name="master">
<setupTask
xsi:type="pde:TargetPlatformTask"
id="ch.elexis.target"
name="ch.elexis.target/juno-target.target"/>
<setupTask
xsi:type="projects:ProjectsImportTask">
<sourceLocator
rootFolder="${core.git.clone.location}"/>
<sourceLocator
rootFolder="${base.git.clone.location}"/>
</setupTask>
</stream>
THANKS!!
[Updated on: Mon, 17 November 2014 15:29] Report message to a moderator |
|
|
| Re: [oomph] adding new setup will not add git repositories to view [message #1477815 is a reply to message #1477049] |
Tue, 18 November 2014 06:14 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Marco,
The "name" property should just be the name of the target definition, in
your case "juno-target".
On 17/11/2014 4:29 PM, Marco Descher wrote:
> Eike,
>
> could you please provide a short example on how to correctly use the
> TargetPlatformTask? I don't seem to get the properties right; I
> already have the resp. bundle imported in ws in
> ch.elexis.target/juno-target.target and the resp. task is part of the
> master stream. Yet it is not switching to it
>
> <stream name="master">
> <setupTask
> xsi:type="pde:TargetPlatformTask"
> id="ch.elexis.target"
> name="ch.elexis.target/juno-target.target"/>
> <setupTask
> xsi:type="projects:ProjectsImportTask">
> <sourceLocator
> rootFolder="${core.git.clone.location}"/>
> <sourceLocator
> rootFolder="${base.git.clone.location}"/>
> </setupTask>
> </stream>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Dec 26 16:24:25 GMT 2024
Powered by FUDForum. Page generated in 0.07268 seconds |
] 
Search
Help
Register
Login
Home
