Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Oomph » targlet resolution with sources and binaries
targlet resolution with sources and binaries [message #1732614] Wed, 18 May 2016 13:36 Go to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
Hi

While working on the integration of EMF Parsley into Neon, I noted a
strange thing concerning our Oomph setup. We have a separate stream
'neon-simrel' and we use http://download.eclipse.org/staging/neon/ for
resolving the target platform.

Now, the current milestone of our EMF Parsley features and bundles are
already in http://download.eclipse.org/staging/neon/ and when the
targlet is resolved, our EMF Parsley source projects are correctly
imported in the workspace but also the EMF Parsley bundles and features
are put in the target platform (or at least, I seem to understand),
which looks really strange... I also tried to separate the targlets so
that our main single root feature is defined in a targlet with only
source locator, and the requirements are in another targlet with remote
update sites
(https://git.eclipse.org/r/#/c/73039/1/devtools/org.eclipse.emf.parsley.oomph/EMFParsley.setup).
But the result is the same, I see in the log:

Computing prerequisite plan
Installing org.eclipse.emf.parsley.cdo.tests [0.8.0.v20160518-151627]
Installing org.eclipse.emf.parsley.dev.doc [0.8.0.v20160518-151627]
Installing org.eclipse.emf.parsley.dsl.ide [0.8.0.v20160518-151627]
Installing org.eclipse.emf.parsley.dsl.standalone [0.8.0.v20160518-151627]
Installing org.eclipse.emf.parsley.dsl.standalone.lib
[0.8.0.v20160518-151627]
Installing org.eclipse.emf.parsley.dsl.tests [0.8.0.v20160518-151627]

well, the bundle dsl.tests is not in the staging repository, and the
timestamp looks like it corresponds to my current time, so does that
mean that it is importing the source project or that it installs that in
the target platform?

thanks in advance
Lorenzo

--
Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book


Re: targlet resolution with sources and binaries [message #1732621 is a reply to message #1732614] Wed, 18 May 2016 14:42 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Lorenzo,

Comments below.

On 18.05.2016 15:36, Lorenzo Bettini wrote:
> Hi
>
> While working on the integration of EMF Parsley into Neon, I noted a
> strange thing concerning our Oomph setup. We have a separate stream
> 'neon-simrel' and we use http://download.eclipse.org/staging/neon/ for
> resolving the target platform.
>
> Now, the current milestone of our EMF Parsley features and bundles are
> already in http://download.eclipse.org/staging/neon/ and when the
> targlet is resolved, our EMF Parsley source projects are correctly
> imported in the workspace but also the EMF Parsley bundles and features
> are put in the target platform (or at least, I seem to understand),
Yes, I would expect that.
> which looks really strange... I also tried to separate the targlets so
> that our main single root feature is defined in a targlet with only
> source locator, and the requirements are in another targlet with remote
> update sites
> (https://git.eclipse.org/r/#/c/73039/1/devtools/org.eclipse.emf.parsley.oomph/EMFParsley.setup).
> But the result is the same, I see in the log:
The entire set of targlets is resolved as a whole, so it doesn't matter
how you decompose it. The overall setup requirements and the overall
set of active repositories (as well as p2 repositories induced from
source locators) are used...
>
> Computing prerequisite plan
> Installing org.eclipse.emf.parsley.cdo.tests [0.8.0.v20160518-151627]
> Installing org.eclipse.emf.parsley.dev.doc [0.8.0.v20160518-151627]
> Installing org.eclipse.emf.parsley.dsl.ide [0.8.0.v20160518-151627]
> Installing org.eclipse.emf.parsley.dsl.standalone [0.8.0.v20160518-151627]
> Installing org.eclipse.emf.parsley.dsl.standalone.lib
> [0.8.0.v20160518-151627]
> Installing org.eclipse.emf.parsley.dsl.tests [0.8.0.v20160518-151627]
>
> well, the bundle dsl.tests is not in the staging repository, and the
> timestamp looks like it corresponds to my current time, so does that
> mean that it is importing the source project or that it installs that in
> the target platform?
If they're available in source and binary form, you'll get the source
form in the workspace and the binary form in the target platform. Of
course with PDE the source form takes precedence so it doesn't matter
that there's a binary available.

It's an involved story to explain, but for projects like the platform
itself, it's often necessary to resolve binaries, which generally expect
to be resolved to other binaries. I.e., you might have just Equinox in
the workspace, but you want PDE and JDT in the TP so you can launch a
self-host IDE. Also, for large projects it's an advantage to be able to
close workspace projects and have the PDE automatically switch to
resolve to the binary form.


>
> thanks in advance
> Lorenzo
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: targlet resolution with sources and binaries [message #1732680 is a reply to message #1732621] Thu, 19 May 2016 07:05 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
Hi Ed

thank you for the explanation. Summarizing, I should not worry about
that :)

cheers
Lorenzo

On 18/05/2016 16:42, Ed Merks wrote:
> Lorenzo,
>
> Comments below.
>
> On 18.05.2016 15:36, Lorenzo Bettini wrote:
>> Hi
>>
>> While working on the integration of EMF Parsley into Neon, I noted a
>> strange thing concerning our Oomph setup. We have a separate stream
>> 'neon-simrel' and we use http://download.eclipse.org/staging/neon/ for
>> resolving the target platform.
>>
>> Now, the current milestone of our EMF Parsley features and bundles are
>> already in http://download.eclipse.org/staging/neon/ and when the
>> targlet is resolved, our EMF Parsley source projects are correctly
>> imported in the workspace but also the EMF Parsley bundles and features
>> are put in the target platform (or at least, I seem to understand),
> Yes, I would expect that.
>> which looks really strange... I also tried to separate the targlets so
>> that our main single root feature is defined in a targlet with only
>> source locator, and the requirements are in another targlet with remote
>> update sites
>> (https://git.eclipse.org/r/#/c/73039/1/devtools/org.eclipse.emf.parsley.oomph/EMFParsley.setup).
>>
>> But the result is the same, I see in the log:
> The entire set of targlets is resolved as a whole, so it doesn't matter
> how you decompose it. The overall setup requirements and the overall
> set of active repositories (as well as p2 repositories induced from
> source locators) are used...
>>
>> Computing prerequisite plan
>> Installing org.eclipse.emf.parsley.cdo.tests [0.8.0.v20160518-151627]
>> Installing org.eclipse.emf.parsley.dev.doc [0.8.0.v20160518-151627]
>> Installing org.eclipse.emf.parsley.dsl.ide [0.8.0.v20160518-151627]
>> Installing org.eclipse.emf.parsley.dsl.standalone
>> [0.8.0.v20160518-151627]
>> Installing org.eclipse.emf.parsley.dsl.standalone.lib
>> [0.8.0.v20160518-151627]
>> Installing org.eclipse.emf.parsley.dsl.tests [0.8.0.v20160518-151627]
>>
>> well, the bundle dsl.tests is not in the staging repository, and the
>> timestamp looks like it corresponds to my current time, so does that
>> mean that it is importing the source project or that it installs that in
>> the target platform?
> If they're available in source and binary form, you'll get the source
> form in the workspace and the binary form in the target platform. Of
> course with PDE the source form takes precedence so it doesn't matter
> that there's a binary available.
>
> It's an involved story to explain, but for projects like the platform
> itself, it's often necessary to resolve binaries, which generally expect
> to be resolved to other binaries. I.e., you might have just Equinox in
> the workspace, but you want PDE and JDT in the TP so you can launch a
> self-host IDE. Also, for large projects it's an advantage to be able to
> close workspace projects and have the PDE automatically switch to
> resolve to the binary form.
>
>
>>
>> thanks in advance
>> Lorenzo
>>
>


--
Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book


Re: targlet resolution with sources and binaries [message #1732684 is a reply to message #1732680] Thu, 19 May 2016 07:49 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Lorenzo,

Yes, it might seem a little odd, and I could give a long explanation
about how a target platform for many of the platform projects can't
resolve without this approach, but suffice to say, don't worry, be happy.


On 19.05.2016 09:05, Lorenzo Bettini wrote:
> Hi Ed
>
> thank you for the explanation. Summarizing, I should not worry about
> that :)
>
> cheers
> Lorenzo
>
> On 18/05/2016 16:42, Ed Merks wrote:
>> Lorenzo,
>>
>> Comments below.
>>
>> On 18.05.2016 15:36, Lorenzo Bettini wrote:
>>> Hi
>>>
>>> While working on the integration of EMF Parsley into Neon, I noted a
>>> strange thing concerning our Oomph setup. We have a separate stream
>>> 'neon-simrel' and we use http://download.eclipse.org/staging/neon/ for
>>> resolving the target platform.
>>>
>>> Now, the current milestone of our EMF Parsley features and bundles are
>>> already in http://download.eclipse.org/staging/neon/ and when the
>>> targlet is resolved, our EMF Parsley source projects are correctly
>>> imported in the workspace but also the EMF Parsley bundles and features
>>> are put in the target platform (or at least, I seem to understand),
>> Yes, I would expect that.
>>> which looks really strange... I also tried to separate the targlets so
>>> that our main single root feature is defined in a targlet with only
>>> source locator, and the requirements are in another targlet with remote
>>> update sites
>>> (https://git.eclipse.org/r/#/c/73039/1/devtools/org.eclipse.emf.parsley.oomph/EMFParsley.setup).
>>>
>>> But the result is the same, I see in the log:
>> The entire set of targlets is resolved as a whole, so it doesn't matter
>> how you decompose it. The overall setup requirements and the overall
>> set of active repositories (as well as p2 repositories induced from
>> source locators) are used...
>>> Computing prerequisite plan
>>> Installing org.eclipse.emf.parsley.cdo.tests [0.8.0.v20160518-151627]
>>> Installing org.eclipse.emf.parsley.dev.doc [0.8.0.v20160518-151627]
>>> Installing org.eclipse.emf.parsley.dsl.ide [0.8.0.v20160518-151627]
>>> Installing org.eclipse.emf.parsley.dsl.standalone
>>> [0.8.0.v20160518-151627]
>>> Installing org.eclipse.emf.parsley.dsl.standalone.lib
>>> [0.8.0.v20160518-151627]
>>> Installing org.eclipse.emf.parsley.dsl.tests [0.8.0.v20160518-151627]
>>>
>>> well, the bundle dsl.tests is not in the staging repository, and the
>>> timestamp looks like it corresponds to my current time, so does that
>>> mean that it is importing the source project or that it installs that in
>>> the target platform?
>> If they're available in source and binary form, you'll get the source
>> form in the workspace and the binary form in the target platform. Of
>> course with PDE the source form takes precedence so it doesn't matter
>> that there's a binary available.
>>
>> It's an involved story to explain, but for projects like the platform
>> itself, it's often necessary to resolve binaries, which generally expect
>> to be resolved to other binaries. I.e., you might have just Equinox in
>> the workspace, but you want PDE and JDT in the TP so you can launch a
>> self-host IDE. Also, for large projects it's an advantage to be able to
>> close workspace projects and have the PDE automatically switch to
>> resolve to the binary form.
>>
>>
>>> thanks in advance
>>> Lorenzo
>>>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: targlet resolution with sources and binaries [message #1733074 is a reply to message #1732684] Tue, 24 May 2016 09:00 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
Hi Ed

actually today our workspace setup does not seem to work anymore, and I fear it might be related to this thread...

We start to have this error during targlet resolution, which does not provide much information:

Calculating requirements and dependencies.
Cannot complete the request. Generating details.
ERROR: org.eclipse.equinox.p2.director code=10053 Cannot complete the install because one or more required items could not be found.
at org.eclipse.oomph.targlets.internal.core.TargletContainer.forceUpdate(TargletContainer.java:778)
at org.eclipse.oomph.setup.targlets.impl.TargletTaskImpl$4.run(TargletTaskImpl.java:1128)
at org.eclipse.oomph.util.pde.TargetPlatformUtil.runWithTargetPlatformService(TargetPlatformUtil.java:119)
at org.eclipse.oomph.setup.targlets.impl.TargletTaskImpl.perform(TargletTaskImpl.java:1036)
at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3021)
at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.access$1(SetupTaskPerformer.java:2964)
at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil$1.run(SetupTaskPerformer.java:4160)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)
at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil.performNeededSetupTasks(SetupTaskPerformer.java:4154)
at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil.access$0(SetupTaskPerformer.java:4152)
at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:2955)
at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:2930)
at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:2861)
at org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:555)
at org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:681)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
ERROR: org.eclipse.equinox.p2.director code=0 You requested to install 'workspace_requirements [1.0.0]' but it could not be found

Took 18 seconds.
There are failed tasks.
Press Back to choose different settings or Cancel to abort.


Re: targlet resolution with sources and binaries [message #1733079 is a reply to message #1733074] Tue, 24 May 2016 09:17 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Lorenzo,

We have code like this:

// If we need source requirements.
workspaceRequirements.removeAll(binaryRequirements);
if (!workspaceRequirements.isEmpty())
{
// Build an artificial unit that requires all the license
features.
InstallableUnitDescription
workspaceRequirementsDescription = new InstallableUnitDescription();
workspaceRequirementsDescription.setId("workspace_requirements");
workspaceRequirementsDescription.setVersion(Version.createOSGi(1, 0, 0));
workspaceRequirementsDescription.setArtifacts(new
IArtifactKey[0]);
workspaceRequirementsDescription.setProperty(InstallableUnitDescription.PROP_TYPE_GROUP,
Boolean.TRUE.toString());
workspaceRequirementsDescription
.setCapabilities(new IProvidedCapability[] {
MetadataFactory.createProvidedCapability(IInstallableUnit.NAMESPACE_IU_ID,
workspaceRequirementsDescription.getId(),
workspaceRequirementsDescription.getVersion()) });
workspaceRequirementsDescription.addRequirements(workspaceRequirements);

IInstallableUnit workspaceRequirementsIU =
MetadataFactory.createInstallableUnit(workspaceRequirementsDescription);
ius.add(workspaceRequirementsIU);

profileChangeRequest.add(workspaceRequirementsIU);
}

So if there is a requirement for this, it should be present in the ius
in order to be able to resolve it.

Of course the Eclipse servers have been very badly behaved this
morning. I'm getting all kinds of timeouts and failures accessing p2
repositories. Perhaps it's related to that...


On 24.05.2016 11:00, Lorenzo Bettini wrote:
> Hi Ed
>
> actually today our workspace setup does not seem to work anymore, and
> I fear it might be related to this thread...
>
> We start to have this error during targlet resolution, which does not
> provide much information:
>
> Calculating requirements and dependencies.
> Cannot complete the request. Generating details.
> ERROR: org.eclipse.equinox.p2.director code=10053 Cannot complete the
> install because one or more required items could not be found.
> at
> org.eclipse.oomph.targlets.internal.core.TargletContainer.forceUpdate(TargletContainer.java:778)
> at
> org.eclipse.oomph.setup.targlets.impl.TargletTaskImpl$4.run(TargletTaskImpl.java:1128)
> at
> org.eclipse.oomph.util.pde.TargetPlatformUtil.runWithTargetPlatformService(TargetPlatformUtil.java:119)
> at
> org.eclipse.oomph.setup.targlets.impl.TargletTaskImpl.perform(TargletTaskImpl.java:1036)
> at
> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3021)
> at
> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.access$1(SetupTaskPerformer.java:2964)
> at
> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil$1.run(SetupTaskPerformer.java:4160)
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)
> at
> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil.performNeededSetupTasks(SetupTaskPerformer.java:4154)
> at
> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil.access$0(SetupTaskPerformer.java:4152)
> at
> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:2955)
> at
> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:2930)
> at
> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:2861)
> at
> org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:555)
> at
> org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:681)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> ERROR: org.eclipse.equinox.p2.director code=0 You requested to
> install 'workspace_requirements [1.0.0]' but it could not be found
>
> Took 18 seconds.
> There are failed tasks.
> Press Back to choose different settings or Cancel to abort.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: targlet resolution with sources and binaries [message #1733100 is a reply to message #1733079] Tue, 24 May 2016 11:31 Go to previous message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1812
Registered: July 2009
Location: Firenze, Italy
Senior Member
Ed, apparently it was due to the bad behavior of update sites you
mentioned. It seems to work now :)

On 24/05/2016 11:17, Ed Merks wrote:
> Lorenzo,
>
> We have code like this:
>
> // If we need source requirements.
> workspaceRequirements.removeAll(binaryRequirements);
> if (!workspaceRequirements.isEmpty())
> {
> // Build an artificial unit that requires all the license
> features.
> InstallableUnitDescription
> workspaceRequirementsDescription = new InstallableUnitDescription();
> workspaceRequirementsDescription.setId("workspace_requirements");
> workspaceRequirementsDescription.setVersion(Version.createOSGi(1, 0, 0));
> workspaceRequirementsDescription.setArtifacts(new
> IArtifactKey[0]);
> workspaceRequirementsDescription.setProperty(InstallableUnitDescription.PROP_TYPE_GROUP,
> Boolean.TRUE.toString());
> workspaceRequirementsDescription
> .setCapabilities(new IProvidedCapability[] {
> MetadataFactory.createProvidedCapability(IInstallableUnit.NAMESPACE_IU_ID,
> workspaceRequirementsDescription.getId(),
> workspaceRequirementsDescription.getVersion()) });
> workspaceRequirementsDescription.addRequirements(workspaceRequirements);
>
> IInstallableUnit workspaceRequirementsIU =
> MetadataFactory.createInstallableUnit(workspaceRequirementsDescription);
> ius.add(workspaceRequirementsIU);
>
> profileChangeRequest.add(workspaceRequirementsIU);
> }
>
> So if there is a requirement for this, it should be present in the ius
> in order to be able to resolve it.
>
> Of course the Eclipse servers have been very badly behaved this
> morning. I'm getting all kinds of timeouts and failures accessing p2
> repositories. Perhaps it's related to that...
>
>
> On 24.05.2016 11:00, Lorenzo Bettini wrote:
>> Hi Ed
>>
>> actually today our workspace setup does not seem to work anymore, and
>> I fear it might be related to this thread...
>>
>> We start to have this error during targlet resolution, which does not
>> provide much information:
>>
>> Calculating requirements and dependencies.
>> Cannot complete the request. Generating details.
>> ERROR: org.eclipse.equinox.p2.director code=10053 Cannot complete the
>> install because one or more required items could not be found.
>> at
>> org.eclipse.oomph.targlets.internal.core.TargletContainer.forceUpdate(TargletContainer.java:778)
>>
>> at
>> org.eclipse.oomph.setup.targlets.impl.TargletTaskImpl$4.run(TargletTaskImpl.java:1128)
>>
>> at
>> org.eclipse.oomph.util.pde.TargetPlatformUtil.runWithTargetPlatformService(TargetPlatformUtil.java:119)
>>
>> at
>> org.eclipse.oomph.setup.targlets.impl.TargletTaskImpl.perform(TargletTaskImpl.java:1036)
>>
>> at
>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3021)
>>
>> at
>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.access$1(SetupTaskPerformer.java:2964)
>>
>> at
>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil$1.run(SetupTaskPerformer.java:4160)
>>
>> at
>> org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
>> at
>> org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)
>> at
>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil.performNeededSetupTasks(SetupTaskPerformer.java:4154)
>>
>> at
>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer$WorkspaceUtil.access$0(SetupTaskPerformer.java:4152)
>>
>> at
>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:2955)
>>
>> at
>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:2930)
>>
>> at
>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:2861)
>>
>> at
>> org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:555)
>>
>> at
>> org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:681)
>>
>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
>> ERROR: org.eclipse.equinox.p2.director code=0 You requested to
>> install 'workspace_requirements [1.0.0]' but it could not be found
>>
>> Took 18 seconds.
>> There are failed tasks.
>> Press Back to choose different settings or Cancel to abort.
>


--
Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book


Previous Topic:self-extracting exe: add path to the JVM
Next Topic:Eclipse Custom Plugin Installation Error
Goto Forum:
  


Current Time: Thu Mar 28 16:07:48 GMT 2024

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

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

Back to the top