Home » Eclipse Projects » Oomph » Git clone task how-to
| |
| Re: Git clone task how-to [message #1423851 is a reply to message #1422765] |
Mon, 15 September 2014 04:41   |
 Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Cedric,
Comments below.
On 13/09/2014 12:30 PM, cedric wrote:
> Hello
>
> I would like to : clone git repo, add git repo to repo list, and finally
> import the projects in my workspace...
>
> I just created this task (and many others which fails) :
>
> <setupTask
> xsi:type="git:GitCloneTask"
> id="git.clone.toodledo-java"
> remoteURI="git@xxxxxxxx:cgava/toodledo-java.git">
> <description>da toodledo git clone description</description>
> </setupTask>
>
> Is it sufficient ?
That only creates the clone on disk...
> Shall I add an import project task ?
As Alexander mentions, you'll have to do something else to actually get
the projects into the workspace. A Projects Import Task is one way to
do that, but probably not the best way. Assuming the projects are
generally Eclipse plugins and features, better is to use a targlet task.
> Which variable contains the location where this repository have been
> cloned (my git clone lcation rule is : ${workspace.location/.git/}
> ${@id.remoteURI|gitRepository})
Variables are inferred based on the id of the task, i.e.,
<id>.<feature-name>. (Actually it uses
ExtendedMetaData.INSTANCE.getName(eAttribute), not eAttribute.getName()
so is influenced by the extended metadata annotations on the features.)
So the best way would be to use a targlet task and list your root
features/plugins and a source locator using the variable for the
location of your clone. This will ensure that all the dependencies of
your source projects are satisfied by the target platform, and will let
you avoid having to create a long list of all your projects... (And
note that you can create an Oomph -> Component Definition for projects
that aren't a feature or a plugin to make it look like an installable unit.)
Looking at example setups in the index will help. I've been trying to
author the targlet tasks so they consistently use
eclipse.target.platform to select alternative versions of the target
platform, i.e., Mars, Luna, Juno, and so on...
>
> Thank you for your help.
>
> Cedric
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Git clone task how-to [message #1424098 is a reply to message #1423851] |
Mon, 15 September 2014 13:04 |
|
Hi, Cedric, Ed,
If you look at the Papyrus model as an example, be aware that the
pattern for specifying targlets and project imports there is quite
different. Papyrus comprises such a large number of plug-in projects
that most of the development team doesn't maintain workspaces
containing all of those projects. Instead, the modus operandi is to
create a PDE target including an entire nightly build of Papyrus and
import only a subset of the plug-ins into the workspace that one
intends to edit.
For most cases, this is probably not the model that you most want to
follow. That would be the EMF model. :-)
However, Ed, you've got me thinking again about how I might revise this
scheme to simplify the Papyrus setup model and improve its
maintainability. Currently, I've got various sub(-sub)-projects
defined that partition our plug-ins into various
functional/architectural units. The Papyrus build does actually group
plug-ins by feature in no small degree, so I'm wondering whether I
can't leverage that to eliminate some of the redundancy of
project-import tasks.
My idea is like this: I would have a common targlet task that installs
the latest nightly build via the Papyrus SDK feature. That is still
needed in any case. But, the sub-projects would each define a targlet
with some specific Papyrus feature required (e.g., "SysML Diagrams")
and a source locator that would fetch those projects from the local git
clone.
My questions are:
* would the source locator cause the relevant plug-in projects to be
imported from git even if they are
also installed in the target platform via the common Papyrus SDK
nightly build targlet?
* and if so, would Oomph perhaps not install in the PDE target any
plug-ins (from the common SDK
build targlet) that were imported into the workspace by some other
targlet's source locator?
The reason why I need plug-ins to be in both the PDE target (as
binaries) and in the workspace is that I often run a run-time workbench
configuration taking only the PDE target and nothing from the
workspace, for the purpose of comparing the behaviour of the nightly
build against changes in progress in my workspace.
I do also still have some projects that aren't in any published Papyrus
build, such as releng material and developer tools. So, those would
need still to be managed by project-import tasks, and that's fine.
Thanks,
Christian
On 2014-09-15 04:41:27 +0000, Ed Merks said:
> Cedric,
>
> Comments below.
>
> On 13/09/2014 12:30 PM, cedric wrote:
>> Hello
>>
>> I would like to : clone git repo, add git repo to repo list, and finally
>> import the projects in my workspace...
>>
>> I just created this task (and many others which fails) :
>>
>> <setupTask
>> xsi:type="git:GitCloneTask"
>> id="git.clone.toodledo-java"
>> remoteURI="git@xxxxxxxx:cgava/toodledo-java.git">
>> <description>da toodledo git clone description</description>
>> </setupTask>
>>
>> Is it sufficient ?
> That only creates the clone on disk...
>> Shall I add an import project task ?
> As Alexander mentions, you'll have to do something else to actually get
> the projects into the workspace. A Projects Import Task is one way to
> do that, but probably not the best way. Assuming the projects are
> generally Eclipse plugins and features, better is to use a targlet task.
>> Which variable contains the location where this repository have been
>> cloned (my git clone lcation rule is : ${workspace.location/.git/}
>> ${@id.remoteURI|gitRepository})
> Variables are inferred based on the id of the task, i.e.,
> <id>.<feature-name>. (Actually it uses
> ExtendedMetaData.INSTANCE.getName(eAttribute), not eAttribute.getName()
> so is influenced by the extended metadata annotations on the features.)
>
> So the best way would be to use a targlet task and list your root
> features/plugins and a source locator using the variable for the
> location of your clone. This will ensure that all the dependencies of
> your source projects are satisfied by the target platform, and will let
> you avoid having to create a long list of all your projects... (And
> note that you can create an Oomph -> Component Definition for projects
> that aren't a feature or a plugin to make it look like an installable
> unit.)
>
> Looking at example setups in the index will help. I've been trying to
> author the targlet tasks so they consistently use
> eclipse.target.platform to select alternative versions of the target
> platform, i.e., Mars, Luna, Juno, and so on...
>>
>> Thank you for your help.
>>
>> Cedric
|
|
|
| Re: Git clone task how-to [message #1424547 is a reply to message #1424098] |
Tue, 16 September 2014 05:16 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Christian,
Comments below.
On 15/09/2014 3:04 PM, Christian W. Damus wrote:
> Hi, Cedric, Ed,
>
> If you look at the Papyrus model as an example, be aware that the
> pattern for specifying targlets and project imports there is quite
> different. Papyrus comprises such a large number of plug-in projects
> that most of the development team doesn't maintain workspaces
> containing all of those projects. Instead, the modus operandi is to
> create a PDE target including an entire nightly build of Papyrus and
> import only a subset of the plug-ins into the workspace that one
> intends to edit.
An interesting improvement of the targlet design
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=439951) is that it can
and will materialize both a source project and the corresponding binary
IU. So depending on what you make visible via the source locator and
via the repository URLs, you'll can get both or either.
>
> For most cases, this is probably not the model that you most want to
> follow. That would be the EMF model. :-)
>
> However, Ed, you've got me thinking again about how I might revise
> this scheme to simplify the Papyrus setup model and improve its
> maintainability. Currently, I've got various sub(-sub)-projects
> defined that partition our plug-ins into various
> functional/architectural units. The Papyrus build does actually group
> plug-ins by feature in no small degree, so I'm wondering whether I
> can't leverage that to eliminate some of the redundancy of
> project-import tasks.
I imagine many of these subsets are driven by the transitive
dependencies of a feature... So if you include the p2 URL for a full
SDK build in the targlet task, and specify a source locator that helps
restrict which projects are visible as IUs, you should be able to
achieve a similar goal.
Note also that (much like Buckminster), you can specify Component
Definition to turn a normal project into an IU with an ID, a version
range, and development-time requirements or a Component Extension to
specify additional development-time requirements.
>
> My idea is like this: I would have a common targlet task that
> installs the latest nightly build via the Papyrus SDK feature. That is
> still needed in any case. But, the sub-projects would each define a
> targlet with some specific Papyrus feature required (e.g., "SysML
> Diagrams") and a source locator that would fetch those projects from
> the local git clone.
Exactly.
>
> My questions are:
>
> * would the source locator cause the relevant plug-in projects to be
> imported from git even if they are
> also installed in the target platform via the common Papyrus SDK
> nightly build targlet?
In the end you only have a single target definition so depending on
what's visible via source locators and what's visible via p2 URLs you'll
get either only a source project, only a binary IU, or both.
> * and if so, would Oomph perhaps not install in the PDE target any
> plug-ins (from the common SDK
> build targlet) that were imported into the workspace by some other
> targlet's source locator?
It will generally try to install both a source version and a binary IU,
with preference for the former if available and with the later being
installed only if it's compatible, i.e., if the source bundle's version
is x.y.z.qualifier it will install a binary IU in the range of
[x.y.z,x.y.z+1).
>
> The reason why I need plug-ins to be in both the PDE target (as
> binaries) and in the workspace is that I often run a run-time
> workbench configuration taking only the PDE target and nothing from
> the workspace, for the purpose of comparing the behaviour of the
> nightly build against changes in progress in my workspace.
Yes, that makes sense. Another advantage of materializing both is that
you could materialize a workspace with a huge number of projects and
then selectively close a large number of them so that the build doesn't
take forever.
>
> I do also still have some projects that aren't in any published
> Papyrus build, such as releng material and developer tools. So, those
> would need still to be managed by project-import tasks, and that's fine.
In general, a projects import task is only needed if the project isn't
an installable unit, but given you can use a Component Definition to
turn a project into an IU, it's clear that a projects import task isn't
strictly needed at all. Also, given Component Definitions and Component
Extensions can specify Requirements (exactly like what you're doing with
the targlet task), it's possible to move most of the requirements you're
specifying in the targlet task to Component Definitions or Component
Extensions.
>
> Thanks,
>
> Christian
>
>
> On 2014-09-15 04:41:27 +0000, Ed Merks said:
>
>> Cedric,
>>
>> Comments below.
>>
>> On 13/09/2014 12:30 PM, cedric wrote:
>>> Hello
>>>
>>> I would like to : clone git repo, add git repo to repo list, and
>>> finally
>>> import the projects in my workspace...
>>>
>>> I just created this task (and many others which fails) :
>>>
>>> <setupTask
>>> xsi:type="git:GitCloneTask"
>>> id="git.clone.toodledo-java"
>>> remoteURI="git@xxxxxxxx:cgava/toodledo-java.git">
>>> <description>da toodledo git clone description</description>
>>> </setupTask>
>>>
>>> Is it sufficient ?
>> That only creates the clone on disk...
>>> Shall I add an import project task ?
>> As Alexander mentions, you'll have to do something else to actually
>> get the projects into the workspace. A Projects Import Task is one
>> way to do that, but probably not the best way. Assuming the projects
>> are generally Eclipse plugins and features, better is to use a
>> targlet task.
>>> Which variable contains the location where this repository have been
>>> cloned (my git clone lcation rule is : ${workspace.location/.git/}
>>> ${@id.remoteURI|gitRepository})
>> Variables are inferred based on the id of the task, i.e.,
>> <id>.<feature-name>. (Actually it uses
>> ExtendedMetaData.INSTANCE.getName(eAttribute), not
>> eAttribute.getName() so is influenced by the extended metadata
>> annotations on the features.)
>>
>> So the best way would be to use a targlet task and list your root
>> features/plugins and a source locator using the variable for the
>> location of your clone. This will ensure that all the dependencies
>> of your source projects are satisfied by the target platform, and
>> will let you avoid having to create a long list of all your
>> projects... (And note that you can create an Oomph -> Component
>> Definition for projects that aren't a feature or a plugin to make it
>> look like an installable unit.)
>>
>> Looking at example setups in the index will help. I've been trying
>> to author the targlet tasks so they consistently use
>> eclipse.target.platform to select alternative versions of the target
>> platform, i.e., Mars, Luna, Juno, and so on...
>>>
>>> Thank you for your help.
>>>
>>> Cedric
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Git clone task how-to [message #1424783 is a reply to message #1424547] |
Tue, 16 September 2014 12:12 |
|
Whoo, lots of goodies here to investigate. It would appear that you
have my use cases thoroughly covered. Can this tool with the funny
name get any better?
Thanks so much, Ed!
cW
On 2014-09-16 05:16:13 +0000, Ed Merks said:
> Christian,
>
> Comments below.
>
> On 15/09/2014 3:04 PM, Christian W. Damus wrote:
>> Hi, Cedric, Ed,
>>
>> If you look at the Papyrus model as an example, be aware that the
>> pattern for specifying targlets and project imports there is quite
>> different. Papyrus comprises such a large number of plug-in projects
>> that most of the development team doesn't maintain workspaces
>> containing all of those projects. Instead, the modus operandi is to
>> create a PDE target including an entire nightly build of Papyrus and
>> import only a subset of the plug-ins into the workspace that one
>> intends to edit.
> An interesting improvement of the targlet design
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=439951) is that it can
> and will materialize both a source project and the corresponding binary
> IU. So depending on what you make visible via the source locator and
> via the repository URLs, you'll can get both or either.
>>
>> For most cases, this is probably not the model that you most want to
>> follow. That would be the EMF model. :-)
>>
>> However, Ed, you've got me thinking again about how I might revise this
>> scheme to simplify the Papyrus setup model and improve its
>> maintainability. Currently, I've got various sub(-sub)-projects
>> defined that partition our plug-ins into various
>> functional/architectural units. The Papyrus build does actually group
>> plug-ins by feature in no small degree, so I'm wondering whether I
>> can't leverage that to eliminate some of the redundancy of
>> project-import tasks.
> I imagine many of these subsets are driven by the transitive
> dependencies of a feature... So if you include the p2 URL for a full
> SDK build in the targlet task, and specify a source locator that helps
> restrict which projects are visible as IUs, you should be able to
> achieve a similar goal.
>
> Note also that (much like Buckminster), you can specify Component
> Definition to turn a normal project into an IU with an ID, a version
> range, and development-time requirements or a Component Extension to
> specify additional development-time requirements.
>>
>> My idea is like this: I would have a common targlet task that installs
>> the latest nightly build via the Papyrus SDK feature. That is still
>> needed in any case. But, the sub-projects would each define a targlet
>> with some specific Papyrus feature required (e.g., "SysML Diagrams")
>> and a source locator that would fetch those projects from the local git
>> clone.
> Exactly.
>>
>> My questions are:
>>
>> * would the source locator cause the relevant plug-in projects to be
>> imported from git even if they are
>> also installed in the target platform via the common Papyrus SDK
>> nightly build targlet?
> In the end you only have a single target definition so depending on
> what's visible via source locators and what's visible via p2 URLs
> you'll get either only a source project, only a binary IU, or both.
>> * and if so, would Oomph perhaps not install in the PDE target any
>> plug-ins (from the common SDK
>> build targlet) that were imported into the workspace by some other
>> targlet's source locator?
> It will generally try to install both a source version and a binary IU,
> with preference for the former if available and with the later being
> installed only if it's compatible, i.e., if the source bundle's version
> is x.y.z.qualifier it will install a binary IU in the range of
> [x.y.z,x.y.z+1).
>>
>> The reason why I need plug-ins to be in both the PDE target (as
>> binaries) and in the workspace is that I often run a run-time workbench
>> configuration taking only the PDE target and nothing from the
>> workspace, for the purpose of comparing the behaviour of the nightly
>> build against changes in progress in my workspace.
> Yes, that makes sense. Another advantage of materializing both is that
> you could materialize a workspace with a huge number of projects and
> then selectively close a large number of them so that the build doesn't
> take forever.
>>
>> I do also still have some projects that aren't in any published Papyrus
>> build, such as releng material and developer tools. So, those would
>> need still to be managed by project-import tasks, and that's fine.
> In general, a projects import task is only needed if the project isn't
> an installable unit, but given you can use a Component Definition to
> turn a project into an IU, it's clear that a projects import task isn't
> strictly needed at all. Also, given Component Definitions and
> Component Extensions can specify Requirements (exactly like what you're
> doing with the targlet task), it's possible to move most of the
> requirements you're specifying in the targlet task to Component
> Definitions or Component Extensions.
>>
>> Thanks,
>>
>> Christian
>>
>>
>> On 2014-09-15 04:41:27 +0000, Ed Merks said:
>>
>>> Cedric,
>>>
>>> Comments below.
>>>
>>> On 13/09/2014 12:30 PM, cedric wrote:
>>>> Hello
>>>>
>>>> I would like to : clone git repo, add git repo to repo list, and finally
>>>> import the projects in my workspace...
>>>>
>>>> I just created this task (and many others which fails) :
>>>>
>>>> <setupTask
>>>> xsi:type="git:GitCloneTask"
>>>> id="git.clone.toodledo-java"
>>>> remoteURI="git@xxxxxxxx:cgava/toodledo-java.git">
>>>> <description>da toodledo git clone description</description>
>>>> </setupTask>
>>>>
>>>> Is it sufficient ?
>>> That only creates the clone on disk...
>>>> Shall I add an import project task ?
>>> As Alexander mentions, you'll have to do something else to actually get
>>> the projects into the workspace. A Projects Import Task is one way to
>>> do that, but probably not the best way. Assuming the projects are
>>> generally Eclipse plugins and features, better is to use a targlet task.
>>>> Which variable contains the location where this repository have been
>>>> cloned (my git clone lcation rule is : ${workspace.location/.git/}
>>>> ${@id.remoteURI|gitRepository})
>>> Variables are inferred based on the id of the task, i.e.,
>>> <id>.<feature-name>. (Actually it uses
>>> ExtendedMetaData.INSTANCE.getName(eAttribute), not eAttribute.getName()
>>> so is influenced by the extended metadata annotations on the features.)
>>>
>>> So the best way would be to use a targlet task and list your root
>>> features/plugins and a source locator using the variable for the
>>> location of your clone. This will ensure that all the dependencies of
>>> your source projects are satisfied by the target platform, and will let
>>> you avoid having to create a long list of all your projects... (And
>>> note that you can create an Oomph -> Component Definition for projects
>>> that aren't a feature or a plugin to make it look like an installable
>>> unit.)
>>>
>>> Looking at example setups in the index will help. I've been trying to
>>> author the targlet tasks so they consistently use
>>> eclipse.target.platform to select alternative versions of the target
>>> platform, i.e., Mars, Luna, Juno, and so on...
>>>>
>>>> Thank you for your help.
>>>>
>>>> Cedric
|
|
|
| Re: Git clone task how-to [message #1424795 is a reply to message #1424783] |
Tue, 16 September 2014 12:31 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Christian,
Yes, this was a feature Dennis Huebner requested. It seemed very
sensible to be able to switch between the workspace version and one from
a binary build easily... The Xtext project is quite huge too, and I
hate waiting for it to build every time I change something in emf.ecore,
but I often want to contribute bug fixes too. This way I can do both
easily...
On 16/09/2014 2:12 PM, Christian W. Damus wrote:
> Whoo, lots of goodies here to investigate. It would appear that you
> have my use cases thoroughly covered. Can this tool with the funny
> name get any better?
>
> Thanks so much, Ed!
>
> cW
>
>
> On 2014-09-16 05:16:13 +0000, Ed Merks said:
>
>> Christian,
>>
>> Comments below.
>>
>> On 15/09/2014 3:04 PM, Christian W. Damus wrote:
>>> Hi, Cedric, Ed,
>>>
>>> If you look at the Papyrus model as an example, be aware that the
>>> pattern for specifying targlets and project imports there is quite
>>> different. Papyrus comprises such a large number of plug-in
>>> projects that most of the development team doesn't maintain
>>> workspaces containing all of those projects. Instead, the modus
>>> operandi is to create a PDE target including an entire nightly build
>>> of Papyrus and import only a subset of the plug-ins into the
>>> workspace that one intends to edit.
>> An interesting improvement of the targlet design
>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=439951) is that it can
>> and will materialize both a source project and the corresponding
>> binary IU. So depending on what you make visible via the source
>> locator and via the repository URLs, you'll can get both or either.
>>>
>>> For most cases, this is probably not the model that you most want to
>>> follow. That would be the EMF model. :-)
>>>
>>> However, Ed, you've got me thinking again about how I might revise
>>> this scheme to simplify the Papyrus setup model and improve its
>>> maintainability. Currently, I've got various sub(-sub)-projects
>>> defined that partition our plug-ins into various
>>> functional/architectural units. The Papyrus build does actually
>>> group plug-ins by feature in no small degree, so I'm wondering
>>> whether I can't leverage that to eliminate some of the redundancy of
>>> project-import tasks.
>> I imagine many of these subsets are driven by the transitive
>> dependencies of a feature... So if you include the p2 URL for a full
>> SDK build in the targlet task, and specify a source locator that
>> helps restrict which projects are visible as IUs, you should be able
>> to achieve a similar goal.
>>
>> Note also that (much like Buckminster), you can specify Component
>> Definition to turn a normal project into an IU with an ID, a version
>> range, and development-time requirements or a Component Extension to
>> specify additional development-time requirements.
>>>
>>> My idea is like this: I would have a common targlet task that
>>> installs the latest nightly build via the Papyrus SDK feature. That
>>> is still needed in any case. But, the sub-projects would each
>>> define a targlet with some specific Papyrus feature required (e.g.,
>>> "SysML Diagrams") and a source locator that would fetch those
>>> projects from the local git clone.
>> Exactly.
>>>
>>> My questions are:
>>>
>>> * would the source locator cause the relevant plug-in projects to be
>>> imported from git even if they are
>>> also installed in the target platform via the common Papyrus SDK
>>> nightly build targlet?
>> In the end you only have a single target definition so depending on
>> what's visible via source locators and what's visible via p2 URLs
>> you'll get either only a source project, only a binary IU, or both.
>>> * and if so, would Oomph perhaps not install in the PDE target any
>>> plug-ins (from the common SDK
>>> build targlet) that were imported into the workspace by some other
>>> targlet's source locator?
>> It will generally try to install both a source version and a binary
>> IU, with preference for the former if available and with the later
>> being installed only if it's compatible, i.e., if the source bundle's
>> version is x.y.z.qualifier it will install a binary IU in the range
>> of [x.y.z,x.y.z+1).
>>>
>>> The reason why I need plug-ins to be in both the PDE target (as
>>> binaries) and in the workspace is that I often run a run-time
>>> workbench configuration taking only the PDE target and nothing from
>>> the workspace, for the purpose of comparing the behaviour of the
>>> nightly build against changes in progress in my workspace.
>> Yes, that makes sense. Another advantage of materializing both is
>> that you could materialize a workspace with a huge number of projects
>> and then selectively close a large number of them so that the build
>> doesn't take forever.
>>>
>>> I do also still have some projects that aren't in any published
>>> Papyrus build, such as releng material and developer tools. So,
>>> those would need still to be managed by project-import tasks, and
>>> that's fine.
>> In general, a projects import task is only needed if the project
>> isn't an installable unit, but given you can use a Component
>> Definition to turn a project into an IU, it's clear that a projects
>> import task isn't strictly needed at all. Also, given Component
>> Definitions and Component Extensions can specify Requirements
>> (exactly like what you're doing with the targlet task), it's possible
>> to move most of the requirements you're specifying in the targlet
>> task to Component Definitions or Component Extensions.
>>>
>>> Thanks,
>>>
>>> Christian
>>>
>>>
>>> On 2014-09-15 04:41:27 +0000, Ed Merks said:
>>>
>>>> Cedric,
>>>>
>>>> Comments below.
>>>>
>>>> On 13/09/2014 12:30 PM, cedric wrote:
>>>>> Hello
>>>>>
>>>>> I would like to : clone git repo, add git repo to repo list, and
>>>>> finally
>>>>> import the projects in my workspace...
>>>>>
>>>>> I just created this task (and many others which fails) :
>>>>>
>>>>> <setupTask
>>>>> xsi:type="git:GitCloneTask"
>>>>> id="git.clone.toodledo-java"
>>>>> remoteURI="git@xxxxxxxx:cgava/toodledo-java.git">
>>>>> <description>da toodledo git clone description</description>
>>>>> </setupTask>
>>>>>
>>>>> Is it sufficient ?
>>>> That only creates the clone on disk...
>>>>> Shall I add an import project task ?
>>>> As Alexander mentions, you'll have to do something else to actually
>>>> get the projects into the workspace. A Projects Import Task is
>>>> one way to do that, but probably not the best way. Assuming the
>>>> projects are generally Eclipse plugins and features, better is to
>>>> use a targlet task.
>>>>> Which variable contains the location where this repository have been
>>>>> cloned (my git clone lcation rule is : ${workspace.location/.git/}
>>>>> ${@id.remoteURI|gitRepository})
>>>> Variables are inferred based on the id of the task, i.e.,
>>>> <id>.<feature-name>. (Actually it uses
>>>> ExtendedMetaData.INSTANCE.getName(eAttribute), not
>>>> eAttribute.getName() so is influenced by the extended metadata
>>>> annotations on the features.)
>>>>
>>>> So the best way would be to use a targlet task and list your root
>>>> features/plugins and a source locator using the variable for the
>>>> location of your clone. This will ensure that all the
>>>> dependencies of your source projects are satisfied by the target
>>>> platform, and will let you avoid having to create a long list of
>>>> all your projects... (And note that you can create an Oomph ->
>>>> Component Definition for projects that aren't a feature or a plugin
>>>> to make it look like an installable unit.)
>>>>
>>>> Looking at example setups in the index will help. I've been trying
>>>> to author the targlet tasks so they consistently use
>>>> eclipse.target.platform to select alternative versions of the
>>>> target platform, i.e., Mars, Luna, Juno, and so on...
>>>>>
>>>>> Thank you for your help.
>>>>>
>>>>> Cedric
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Git clone task how-to [message #1425471 is a reply to message #1423512] |
Wed, 17 September 2014 11:05 |
Eclipse User |
|
|
|
Hi everybody
Thank you for your answers, I'am gonna try out. My projects are indeed not
java/eclipse project, but mere projects.
Anyway, I don't know HOW could I figure out all this without asking... My
level of java/eclipse is not very good at all, so I dont' feel very
comfortable at exploring the source to guess HOW setups tasks really
work.. I went into the org.eclipse.oomph.git project, to guess what
"perform" method was actually doing, but could not go further :(
Thank you again
See you next time for my next blocking question
Cedric
|
|
| |
Goto Forum:
Current Time: Thu Sep 19 21:50:44 GMT 2024
Powered by FUDForum. Page generated in 0.04100 seconds |
] 
Search
Help
Register
Login
Home
