| [Oomph] Import projects into workspace [message #1275632] |
Sun, 23 March 2014 10:54  |
|
Hi,
I'm not sure I got the idea of how to import projects into the workspace right. I figured out that I've to put an Automatic Source Locator in a Targlet container to make this work.
Is there any other way how to import projects with Oomph? I'd rather use the active Eclipse platform - and sometimes I'd just like to import plain java projects for a demo. Is that possible?
Attachment: oomph.png
(Size: 59.16KB, Downloaded 988 times)
|
|
|
| Re: [Oomph] Import projects into workspace [message #1275673 is a reply to message #1275632] |
Sun, 23 March 2014 12:16  |
|
Hi Marcel,
Funny coincidence: I'm currently playing with your new setup model in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=430937 ;-)
Comments below...
Am 23.03.2014 11:54, schrieb Marcel Bruch:
> Hi,
>
> I'm not sure I got the idea of how to import projects into the workspace right. I figured out that I've to put an Automatic Source Locator in a Targlet container to make this work.
Yes, this is usually a very easy way. Internally the TargletContainer uses the p2 planner for both the source projects
in your Git clone and the needed binary dependencies. The AutomaticSourceLocators are looking for .project files in your
Git clone.
I see that you've had some offline conversation with Ed about .project files that are not managed in Git, i.e., that
don't exist at workspace provisioning time. To me that seems a little weird, expecting that it should always be possible
to just import the projects into Eclipse with only Platform facilities. I think you should open a bugzilla and paste in
the relevant parts from your offline discussion.
> Is there any other way how to import projects with Oomph?
Pascal is working on:
429246: [Oomph] Import project by browsing file system
https://bugs.eclipse.org/bugs/show_bug.cgi?id=429246
But that will also make use of AutomaticSourceLocators.
> I'd rather use the active Eclipse platform
For what exactly?
> - and sometimes I'd just like to import plain java projects for a demo. Is that possible?
Would the ProjectsImportTask that Pascal is working on do what you're asking for?
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] Import projects into workspace [message #1275692 is a reply to message #1275673] |
Sun, 23 March 2014 13:04 |
|
> Funny coincidence: I'm currently playing with your new setup model in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=430937 
Beside many other things, I like the eclipse provisioning of our demo installation w/ example projects very much. Just neat. The setup file is under construction. See https://git.eclipse.org/r/#/c/23754/ for additional changes.
>> I figured out that I've to put an Automatic Source Locator in a Targlet container to make this work.
> Yes, this is usually a very easy way. Internally the TargletContainer uses the p2 planner for both the source
> projects in your Git clone and the needed binary dependencies. The AutomaticSourceLocators are looking for
> .project files in your Git clone.
The TargletContainer concept is new to me. We build our code with Tycho which is based on a .target definition. So, to me it looks a bit redundant to specify a TargletContainer AND a Target Definition. A simple task that imports src projects from the git Repo (w/o Targlet) is what I looked for. Bug 429246: [Oomph] Import project by browsing file system seems to go in that direction.
[...]
>> I'd rather use the active Eclipse platform
>For what exactly?
For the sake of "not needing anything else than that active platform"  It's for the provision of a demo workspace which has no such requirements yet. I thought there might be an easy way around this (to me) unnecessary step.
In particular this feels weird when importing source projects that are no bundles at all. But again, if Pascal makes the "simple" import work, this would fit my need.
Thanks,
Marcel
|
|
|
| Re: [Oomph] Import projects into workspace [message #1275704 is a reply to message #1275692] |
Sun, 23 March 2014 13:27 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Am 23.03.2014 14:04, schrieb Marcel Bruch:<br>
<blockquote cite="mid:lgmm55$pn0$1@xxxxxxxxe.org" type="cite">
<blockquote type="cite">Funny coincidence: I'm currently playing
with your new setup model in
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=430937">https://bugs.eclipse.org/bugs/show_bug.cgi?id=430937</a> ;)
<br>
</blockquote>
<br>
Beside many other things, I like the eclipse provisioning of our
demo installation w/ example projects very much. Just neat. The
setup file is under construction. See
<a class="moz-txt-link-freetext" href="https://git.eclipse.org/r/#/c/23754/">https://git.eclipse.org/r/#/c/23754/</a> for additional changes.
<br>
</blockquote>
I've just added a link to your setup model in the main index.
Changes that you apply to your model will be picked up automatically
from now on. Please note that Eclipse's web viewer for Git sometimes
suffers from delays up to 15 minutes.<br>
<br>
<blockquote cite="mid:lgmm55$pn0$1@xxxxxxxxe.org" type="cite">
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">I figured out that I've to put an
Automatic Source Locator in a Targlet container to make this
work.
<br>
</blockquote>
</blockquote>
<br>
<blockquote type="cite">Yes, this is usually a very easy way.
Internally the TargletContainer uses the p2 planner for both the
source
<br>
projects in your Git clone and the needed binary dependencies.
The AutomaticSourceLocators are looking for
<br>
.project files in your Git clone.
<br>
</blockquote>
<br>
The TargletContainer concept is new to me. </blockquote>
It is new ;-)<br>
<br>
<blockquote cite="mid:lgmm55$pn0$1@xxxxxxxxe.org" type="cite">We
build our code with Tycho which is based on a .target definition.
So, to me it looks a bit redundant to specify a TargletContainer
AND a Target Definition. A simple task that imports src projects
from the git Repo (w/o Targlet) is what I looked for. Bug 429246:
[Oomph] Import project by browsing file system seems to go in that
direction.
<br>
</blockquote>
Our TargletContainer seamlessly integrates with PDE's target
platform framework:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=17819" alt=""><br>
<br>
See the .target file that would result if you shared ("Share..."
button) this target definition in the preferences dialog:<br>
<br>
<?xml version="1.0" encoding="UTF-8" standalone="no"?><br>
<?pde version="3.8"?><target name="Modular Target"
sequenceNumber="4"><br>
<locations><br>
<location
xmlns:predicates=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/CDO/releng/predicates/1.0">"http://www.eclipse.org/CDO/releng/predicates/1.0"</a>
xmlns:setup=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/CDO/releng/setup/1.0">"http://www.eclipse.org/CDO/releng/setup/1.0"</a>
xmlns:xsi=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/XMLSchema-instance">"http://www.w3.org/2001/XMLSchema-instance"</a> id="Oomph"
type="Targlet"><br>
<targlet name="CDO Releng" xsi:type="setup:Targlet"><br>
<roots id="org.eclipse.emf.cdo.releng.all.feature.group"/><br>
<roots id="org.eclipse.emf.cdo.releng.release"/><br>
<sourceLocators
rootFolder="C:\develop\eclipse\cdo.releng\master\git\cdo.releng"><br>
<predicates xsi:type="predicates:NotPredicate"><br>
<operand pattern="org\.eclipse\.net4j.*"
xsi:type="predicates:NamePredicate"/><br>
</predicates><br>
</sourceLocators><br>
<repositoryLists name="Luna Dependencies"><br>
<p2Repositories
url=<a class="moz-txt-link-rfc2396E" href="http://hudson.eclipse.org/hudson/job/emf-cdo-integration/lastSuccessfulBuild/artifact">"http://hudson.eclipse.org/hudson/job/emf-cdo-integration/lastSuccessfulBuild/artifact"</a>/><br>
<p2Repositories
url=<a class="moz-txt-link-rfc2396E" href="http://download.eclipse.org/eclipse/updates/4.4milestones">"http://download.eclipse.org/eclipse/updates/4.4milestones"</a>/><br>
<p2Repositories
url=<a class="moz-txt-link-rfc2396E" href="http://download.eclipse.org/modeling/emf/emf/updates/2.10milestones">"http://download.eclipse.org/modeling/emf/emf/updates/2.10milestones"</a>/><br>
<p2Repositories
url=<a class="moz-txt-link-rfc2396E" href="http://download.eclipse.org/modeling/emf/cdo/orbit/latest-S">"http://download.eclipse.org/modeling/emf/cdo/orbit/latest-S"</a>/><br>
<p2Repositories
url=<a class="moz-txt-link-rfc2396E" href="http://download.eclipse.org/tools/buckminster/updates-4.3">"http://download.eclipse.org/tools/buckminster/updates-4.3"</a>/><br>
<p2Repositories
url=<a class="moz-txt-link-rfc2396E" href="http://download.eclipse.org/tools/gef/updates/milestones">"http://download.eclipse.org/tools/gef/updates/milestones"</a>/><br>
<p2Repositories
url=<a class="moz-txt-link-rfc2396E" href="http://download.eclipse.org/egit/updates">"http://download.eclipse.org/egit/updates"</a>/><br>
<p2Repositories
url=<a class="moz-txt-link-rfc2396E" href="http://download.eclipse.org/mylyn/snapshots/weekly">"http://download.eclipse.org/mylyn/snapshots/weekly"</a>/><br>
<p2Repositories
url=<a class="moz-txt-link-rfc2396E" href="http://download.eclipse.org/technology/nebula/snapshot">"http://download.eclipse.org/technology/nebula/snapshot"</a>/><br>
</repositoryLists><br>
</targlet><br>
</location><br>
</locations><br>
</target><br>
<br>
It's Tycho that doesn't go through PDE when it reads the .target
files. All <location>s with types different from
"InstallableUnit" are ignored by Tycho. I have already started an
in-depth discussion with Tobias Oberlies (Tycho committer, cc'ed)
and we're looking for ways to make Tycho leverage the information
specified in a Targlet-typed location.<br>
<br>
<blockquote cite="mid:lgmm55$pn0$1@xxxxxxxxe.org" type="cite">
<br>
[...]
<br>
<blockquote type="cite">
<blockquote type="cite">I'd rather use the active Eclipse
platform
<br>
</blockquote>
For what exactly?
<br>
</blockquote>
<br>
For the sake of "not needing anything else than that active
platform" :) It's for the provision of a demo workspace which has
no such requirements yet. I thought there might be an easy way
around this (to me) unnecessary step.
<br>
<br>
In particular this feels weird when importing source projects that
are no bundles at all. But again, if Pascal makes the "simple"
import work, this would fit my need.
<br>
</blockquote>
Okay, then let's hope for the best ;-)<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>
</body>
</html>
-
Attachment: gbhfihfe.png
(Size: 109.23KB, Downloaded 200 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.04262 seconds
] 
Search
Help
Register
Login
Home
