Home » Modeling » Epsilon » Building an Epsilon product is, well, hum...
| Building an Epsilon product is, well, hum... [message #8032] |
Tue, 06 January 2009 05:54  |
 Nicolas Rouquette
Messages: 157
Registered: July 2009 |
Senior Member |
|
|
At JPL, I use a Bamboo continuous build server to build a toolkit based
on Ganymede SR1 with the UML2Tools components. So far so good.
I checked out the full Epsilon enchilada from SVN because it provides a
really nice scripting mechanism I can use with UML2Tools diagrams.
In my development workspace, I can launch a runtime environment with
epsilon plugins or with a product which includes the epsilon features
and everything works fine. Then, I tried to update my Bamboo product
configuration to build Epsilon. That's when I got an endless string of
compilation problems...
05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
/ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source files
to
/ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
05-Jan-2009 20:43:49 [java] [javac] ----------
05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
/ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
(at line 21)
05-Jan-2009 20:43:49 [java] [javac] import
org.eclipse.epsilon.common.dt.console.EpsilonConsole;
05-Jan-2009 20:43:49 [java] [javac]
^^^^^^^^^^^^^^^^^^^^^^^^^^
05-Jan-2009 20:43:49 [java] [javac] The import
org.eclipse.epsilon.common cannot be resolved
05-Jan-2009 20:43:49 [java] [javac] ----------
05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
/ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
(at line 22)
05-Jan-2009 20:43:49 [java] [javac] import
org.eclipse.epsilon.common.dt.util.EclipseUtil;
05-Jan-2009 20:43:49 [java] [javac]
^^^^^^^^^^^^^^^^^^^^^^^^^^
05-Jan-2009 20:43:49 [java] [javac] The import
org.eclipse.epsilon.common cannot be resolved
05-Jan-2009 20:43:49 [java] [javac] ----------
05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
/ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
(at line 23)
05-Jan-2009 20:43:49 [java] [javac] import
org.eclipse.epsilon.common.dt.util.LogUtil;
05-Jan-2009 20:43:49 [java] [javac]
^^^^^^^^^^^^^^^^^^^^^^^^^^
05-Jan-2009 20:43:49 [java] [javac] The import
org.eclipse.epsilon.common cannot be resolved
05-Jan-2009 20:43:49 [java] [javac] ----------
05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
/ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
(at line 24)
05-Jan-2009 20:43:49 [java] [javac] import
org.eclipse.epsilon.commons.util.StringProperties;
05-Jan-2009 20:43:49 [java] [javac]
^^^^^^^^^^^^^^^^^^^^^^^^^^^
05-Jan-2009 20:43:49 [java] [javac] The import
org.eclipse.epsilon.commons cannot be resolved
To get a better clue about what's going on, I switched the PDE settings
to full paranoia mode, i.e., flag errors on the slightest whiff of
anything suspicious. In my experience, this is a really useful thing to
do because it helps weed out problems that can mask bigger problems
later on.
In this mode, I found that most Epsilon plugins fail to compile because
of the org.eclipse.epsilon.antlr plugin.
Other plugins have out-of-order plugin dependencies in their MANIFEST.MF
files. I have fixed some of these but it's hard to do this without some
information about the Epsilon plugin architecture, i.e., are there
layers? e.g.:
org.eclipse.epsilon.common.*
org.eclipse.epsilon.eol.*
org.eclipse.epsilon.????
org.eclipse.epsilon.????
Layering the dependencies helps resolve compilation problems.
I'm on a very tight schedule but I can help clean some of this.
It would be a shame to loose the Epsilon wizard capability for
unresolved compilation issues.
Suggestions?
-- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #8062 is a reply to message #8032] |
Tue, 06 January 2009 21:33  |
Nicolas Rouquette
Messages: 157
Registered: July 2009 |
Senior Member |
|
|
I managed to fix all problems which, roughly, fall into 3 categories.
1) out-of-order dependencies
e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
Require-Bundle: org.eclipse.epsilon.common.dt,
org.eclipse.jface,
org.eclipse.epsilon.commons,
org.eclipse.emf,
org.eclipse.emf.ecore,
org.eclipse.epsilon.emc.emf,
org.eclipse.epsilon.emc.emf.virtual,
org.eclipse.ui,
org.eclipse.core.runtime,
org.eclipse.epsilon.util.emf
fixed:
Require-Bundle: org.eclipse.core.runtime,
org.eclipse.jface,
org.eclipse.ui,
org.eclipse.emf,
org.eclipse.emf.ecore,
org.eclipse.epsilon.commons,
org.eclipse.epsilon.common.dt,
org.eclipse.epsilon.emc.emf,
org.eclipse.epsilon.emc.emf.virtual,
org.eclipse.epsilon.util.emf
2) missing indirect dependencies
e.g., org.eclipse.epsilon.antlr
This threw me off initially. I think that we can reduce the number of
indirect dependencies the plugins need once there the order of the
bundles is consistent with the dependencies for all epsilon plugins.
3) missing feature dependencies
the continuous build failed because epsilon.eugenia.feature is missing a
dependency on epsilon.feature.
see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
-- Nicolas.
-- Nicolas.
Nicolas Rouquette wrote:
> At JPL, I use a Bamboo continuous build server to build a toolkit based
> on Ganymede SR1 with the UML2Tools components. So far so good.
>
> I checked out the full Epsilon enchilada from SVN because it provides a
> really nice scripting mechanism I can use with UML2Tools diagrams.
> In my development workspace, I can launch a runtime environment with
> epsilon plugins or with a product which includes the epsilon features
> and everything works fine. Then, I tried to update my Bamboo product
> configuration to build Epsilon. That's when I got an endless string of
> compilation problems...
>
> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>
> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
> files to
> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>
> 05-Jan-2009 20:43:49 [java] [javac] ----------
> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
> (at line 21)
> 05-Jan-2009 20:43:49 [java] [javac] import
> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
> 05-Jan-2009 20:43:49 [java] [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 05-Jan-2009 20:43:49 [java] [javac] The import
> org.eclipse.epsilon.common cannot be resolved
> 05-Jan-2009 20:43:49 [java] [javac] ----------
> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
> (at line 22)
> 05-Jan-2009 20:43:49 [java] [javac] import
> org.eclipse.epsilon.common.dt.util.EclipseUtil;
> 05-Jan-2009 20:43:49 [java] [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 05-Jan-2009 20:43:49 [java] [javac] The import
> org.eclipse.epsilon.common cannot be resolved
> 05-Jan-2009 20:43:49 [java] [javac] ----------
> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
> (at line 23)
> 05-Jan-2009 20:43:49 [java] [javac] import
> org.eclipse.epsilon.common.dt.util.LogUtil;
> 05-Jan-2009 20:43:49 [java] [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 05-Jan-2009 20:43:49 [java] [javac] The import
> org.eclipse.epsilon.common cannot be resolved
> 05-Jan-2009 20:43:49 [java] [javac] ----------
> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
> (at line 24)
> 05-Jan-2009 20:43:49 [java] [javac] import
> org.eclipse.epsilon.commons.util.StringProperties;
> 05-Jan-2009 20:43:49 [java] [javac]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 05-Jan-2009 20:43:49 [java] [javac] The import
> org.eclipse.epsilon.commons cannot be resolved
>
> To get a better clue about what's going on, I switched the PDE settings
> to full paranoia mode, i.e., flag errors on the slightest whiff of
> anything suspicious. In my experience, this is a really useful thing to
> do because it helps weed out problems that can mask bigger problems
> later on.
>
> In this mode, I found that most Epsilon plugins fail to compile because
> of the org.eclipse.epsilon.antlr plugin.
>
> Other plugins have out-of-order plugin dependencies in their MANIFEST.MF
> files. I have fixed some of these but it's hard to do this without some
> information about the Epsilon plugin architecture, i.e., are there
> layers? e.g.:
>
> org.eclipse.epsilon.common.*
> org.eclipse.epsilon.eol.*
> org.eclipse.epsilon.????
> org.eclipse.epsilon.????
>
> Layering the dependencies helps resolve compilation problems.
>
> I'm on a very tight schedule but I can help clean some of this.
> It would be a shame to loose the Epsilon wizard capability for
> unresolved compilation issues.
>
> Suggestions?
>
> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #8126 is a reply to message #8062] |
Tue, 06 January 2009 23:36 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Nicolas,
Glad you managed to sort this one out and thanks for reporting back on
it! I hadn't ever come across such issues before as I'm using the "Build
all" facility of the update site editor which doesn't seem to care about
the specific order of dependencies (or is smart enough to sort/resolve
them behind the scene). Could you please attach a patch that aggregates
the fixes you've done to the bugzilla?
Cheers,
Dimitris
Nicolas Rouquette wrote:
> I managed to fix all problems which, roughly, fall into 3 categories.
>
> 1) out-of-order dependencies
>
> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>
> Require-Bundle: org.eclipse.epsilon.common.dt,
> org.eclipse.jface,
> org.eclipse.epsilon.commons,
> org.eclipse.emf,
> org.eclipse.emf.ecore,
> org.eclipse.epsilon.emc.emf,
> org.eclipse.epsilon.emc.emf.virtual,
> org.eclipse.ui,
> org.eclipse.core.runtime,
> org.eclipse.epsilon.util.emf
>
> fixed:
>
> Require-Bundle: org.eclipse.core.runtime,
> org.eclipse.jface,
> org.eclipse.ui,
> org.eclipse.emf,
> org.eclipse.emf.ecore,
> org.eclipse.epsilon.commons,
> org.eclipse.epsilon.common.dt,
> org.eclipse.epsilon.emc.emf,
> org.eclipse.epsilon.emc.emf.virtual,
> org.eclipse.epsilon.util.emf
>
> 2) missing indirect dependencies
>
> e.g., org.eclipse.epsilon.antlr
>
> This threw me off initially. I think that we can reduce the number of
> indirect dependencies the plugins need once there the order of the
> bundles is consistent with the dependencies for all epsilon plugins.
>
> 3) missing feature dependencies
>
> the continuous build failed because epsilon.eugenia.feature is missing a
> dependency on epsilon.feature.
>
> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>
> -- Nicolas.
>
> -- Nicolas.
>
> Nicolas Rouquette wrote:
>> At JPL, I use a Bamboo continuous build server to build a toolkit
>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>
>> I checked out the full Epsilon enchilada from SVN because it provides
>> a really nice scripting mechanism I can use with UML2Tools diagrams.
>> In my development workspace, I can launch a runtime environment with
>> epsilon plugins or with a product which includes the epsilon features
>> and everything works fine. Then, I tried to update my Bamboo product
>> configuration to build Epsilon. That's when I got an endless string of
>> compilation problems...
>>
>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>
>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>> files to
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 21)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.common cannot be resolved
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 22)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.common cannot be resolved
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 23)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.common.dt.util.LogUtil;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.common cannot be resolved
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 24)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.commons.util.StringProperties;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.commons cannot be resolved
>>
>> To get a better clue about what's going on, I switched the PDE
>> settings to full paranoia mode, i.e., flag errors on the slightest
>> whiff of anything suspicious. In my experience, this is a really
>> useful thing to do because it helps weed out problems that can mask
>> bigger problems later on.
>>
>> In this mode, I found that most Epsilon plugins fail to compile
>> because of the org.eclipse.epsilon.antlr plugin.
>>
>> Other plugins have out-of-order plugin dependencies in their
>> MANIFEST.MF files. I have fixed some of these but it's hard to do this
>> without some information about the Epsilon plugin architecture, i.e.,
>> are there layers? e.g.:
>>
>> org.eclipse.epsilon.common.*
>> org.eclipse.epsilon.eol.*
>> org.eclipse.epsilon.????
>> org.eclipse.epsilon.????
>>
>> Layering the dependencies helps resolve compilation problems.
>>
>> I'm on a very tight schedule but I can help clean some of this.
>> It would be a shame to loose the Epsilon wizard capability for
>> unresolved compilation issues.
>>
>> Suggestions?
>>
>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #8158 is a reply to message #8126] |
Wed, 07 January 2009 06:28 |
Nicolas Rouquette
Messages: 157
Registered: July 2009 |
Senior Member |
|
|
Indeed, I was initially thrown off as well because everything looked
peachy clean in my workspace with the usual PDE update site build
procedures. On the other hand, building from scratch is sufficiently
different that it is worth making sure all of the details that matter to
PDE are 100% kosher.
Another thing that threw me off was how to extract a patch given that I
had to disconnect my workspace copy of the epsilon plugins and share
them to the SVN repository of our continuous build server. That's
another unusual procedure that is new territory for me as well. The
patch seems fine though. In hindsight, I think that fixing the
out-of-order dependencies among plugins in MANIFEST.MF files should help
you avoid adding indirect plugins like org.eclipse.epsilon.antlr as I
did for (2) too many times for my taste.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
-- Nicolas.
Dimitrios Kolovos wrote:
> Hi Nicolas,
>
> Glad you managed to sort this one out and thanks for reporting back on
> it! I hadn't ever come across such issues before as I'm using the "Build
> all" facility of the update site editor which doesn't seem to care about
> the specific order of dependencies (or is smart enough to sort/resolve
> them behind the scene). Could you please attach a patch that aggregates
> the fixes you've done to the bugzilla?
>
> Cheers,
> Dimitris
>
> Nicolas Rouquette wrote:
>> I managed to fix all problems which, roughly, fall into 3 categories.
>>
>> 1) out-of-order dependencies
>>
>> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>>
>> Require-Bundle: org.eclipse.epsilon.common.dt,
>> org.eclipse.jface,
>> org.eclipse.epsilon.commons,
>> org.eclipse.emf,
>> org.eclipse.emf.ecore,
>> org.eclipse.epsilon.emc.emf,
>> org.eclipse.epsilon.emc.emf.virtual,
>> org.eclipse.ui,
>> org.eclipse.core.runtime,
>> org.eclipse.epsilon.util.emf
>>
>> fixed:
>>
>> Require-Bundle: org.eclipse.core.runtime,
>> org.eclipse.jface,
>> org.eclipse.ui,
>> org.eclipse.emf,
>> org.eclipse.emf.ecore,
>> org.eclipse.epsilon.commons,
>> org.eclipse.epsilon.common.dt,
>> org.eclipse.epsilon.emc.emf,
>> org.eclipse.epsilon.emc.emf.virtual,
>> org.eclipse.epsilon.util.emf
>>
>> 2) missing indirect dependencies
>>
>> e.g., org.eclipse.epsilon.antlr
>>
>> This threw me off initially. I think that we can reduce the number of
>> indirect dependencies the plugins need once there the order of the
>> bundles is consistent with the dependencies for all epsilon plugins.
>>
>> 3) missing feature dependencies
>>
>> the continuous build failed because epsilon.eugenia.feature is missing
>> a dependency on epsilon.feature.
>>
>> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>>
>> -- Nicolas.
>>
>> -- Nicolas.
>>
>> Nicolas Rouquette wrote:
>>> At JPL, I use a Bamboo continuous build server to build a toolkit
>>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>>
>>> I checked out the full Epsilon enchilada from SVN because it provides
>>> a really nice scripting mechanism I can use with UML2Tools diagrams.
>>> In my development workspace, I can launch a runtime environment with
>>> epsilon plugins or with a product which includes the epsilon features
>>> and everything works fine. Then, I tried to update my Bamboo product
>>> configuration to build Epsilon. That's when I got an endless string
>>> of compilation problems...
>>>
>>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>
>>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>>> files to
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 21)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.common cannot be resolved
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 22)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.common cannot be resolved
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 23)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.common.dt.util.LogUtil;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.common cannot be resolved
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 24)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.commons.util.StringProperties;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.commons cannot be resolved
>>>
>>> To get a better clue about what's going on, I switched the PDE
>>> settings to full paranoia mode, i.e., flag errors on the slightest
>>> whiff of anything suspicious. In my experience, this is a really
>>> useful thing to do because it helps weed out problems that can mask
>>> bigger problems later on.
>>>
>>> In this mode, I found that most Epsilon plugins fail to compile
>>> because of the org.eclipse.epsilon.antlr plugin.
>>>
>>> Other plugins have out-of-order plugin dependencies in their
>>> MANIFEST.MF files. I have fixed some of these but it's hard to do
>>> this without some information about the Epsilon plugin architecture,
>>> i.e., are there layers? e.g.:
>>>
>>> org.eclipse.epsilon.common.*
>>> org.eclipse.epsilon.eol.*
>>> org.eclipse.epsilon.????
>>> org.eclipse.epsilon.????
>>>
>>> Layering the dependencies helps resolve compilation problems.
>>>
>>> I'm on a very tight schedule but I can help clean some of this.
>>> It would be a shame to loose the Epsilon wizard capability for
>>> unresolved compilation issues.
>>>
>>> Suggestions?
>>>
>>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #8190 is a reply to message #8158] |
Wed, 07 January 2009 14:56 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Nicolas,
Thanks for submitting this patch. I've tried to merge it with my
workspace but I get a few errors which are probably due to the parallel
evolution of the two copies. What I'll do is I'll install a continuous
integration and build server in my machine and try to repeat the process
you went through (so that I can also get a better understanding of what
the problems are). I understand that Bamboo
(http://www.atlassian.com/software/bamboo/) is commercial software so I
was wondering if you have good experiences with any of the OS ones.
Cheers,
Dimitris
Nicolas Rouquette wrote:
> Indeed, I was initially thrown off as well because everything looked
> peachy clean in my workspace with the usual PDE update site build
> procedures. On the other hand, building from scratch is sufficiently
> different that it is worth making sure all of the details that matter to
> PDE are 100% kosher.
>
> Another thing that threw me off was how to extract a patch given that I
> had to disconnect my workspace copy of the epsilon plugins and share
> them to the SVN repository of our continuous build server. That's
> another unusual procedure that is new territory for me as well. The
> patch seems fine though. In hindsight, I think that fixing the
> out-of-order dependencies among plugins in MANIFEST.MF files should help
> you avoid adding indirect plugins like org.eclipse.epsilon.antlr as I
> did for (2) too many times for my taste.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>
> -- Nicolas.
>
> Dimitrios Kolovos wrote:
>> Hi Nicolas,
>>
>> Glad you managed to sort this one out and thanks for reporting back on
>> it! I hadn't ever come across such issues before as I'm using the
>> "Build all" facility of the update site editor which doesn't seem to
>> care about the specific order of dependencies (or is smart enough to
>> sort/resolve them behind the scene). Could you please attach a patch
>> that aggregates the fixes you've done to the bugzilla?
>>
>> Cheers,
>> Dimitris
>>
>> Nicolas Rouquette wrote:
>>> I managed to fix all problems which, roughly, fall into 3 categories.
>>>
>>> 1) out-of-order dependencies
>>>
>>> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>>>
>>> Require-Bundle: org.eclipse.epsilon.common.dt,
>>> org.eclipse.jface,
>>> org.eclipse.epsilon.commons,
>>> org.eclipse.emf,
>>> org.eclipse.emf.ecore,
>>> org.eclipse.epsilon.emc.emf,
>>> org.eclipse.epsilon.emc.emf.virtual,
>>> org.eclipse.ui,
>>> org.eclipse.core.runtime,
>>> org.eclipse.epsilon.util.emf
>>>
>>> fixed:
>>>
>>> Require-Bundle: org.eclipse.core.runtime,
>>> org.eclipse.jface,
>>> org.eclipse.ui,
>>> org.eclipse.emf,
>>> org.eclipse.emf.ecore,
>>> org.eclipse.epsilon.commons,
>>> org.eclipse.epsilon.common.dt,
>>> org.eclipse.epsilon.emc.emf,
>>> org.eclipse.epsilon.emc.emf.virtual,
>>> org.eclipse.epsilon.util.emf
>>>
>>> 2) missing indirect dependencies
>>>
>>> e.g., org.eclipse.epsilon.antlr
>>>
>>> This threw me off initially. I think that we can reduce the number of
>>> indirect dependencies the plugins need once there the order of the
>>> bundles is consistent with the dependencies for all epsilon plugins.
>>>
>>> 3) missing feature dependencies
>>>
>>> the continuous build failed because epsilon.eugenia.feature is
>>> missing a dependency on epsilon.feature.
>>>
>>> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>>>
>>> -- Nicolas.
>>>
>>> -- Nicolas.
>>>
>>> Nicolas Rouquette wrote:
>>>> At JPL, I use a Bamboo continuous build server to build a toolkit
>>>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>>>
>>>> I checked out the full Epsilon enchilada from SVN because it
>>>> provides a really nice scripting mechanism I can use with UML2Tools
>>>> diagrams.
>>>> In my development workspace, I can launch a runtime environment with
>>>> epsilon plugins or with a product which includes the epsilon
>>>> features and everything works fine. Then, I tried to update my
>>>> Bamboo product configuration to build Epsilon. That's when I got an
>>>> endless string of compilation problems...
>>>>
>>>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>>
>>>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>>>> files to
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>>
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 21)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.common cannot be resolved
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 22)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.common cannot be resolved
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 23)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.common.dt.util.LogUtil;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.common cannot be resolved
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 24)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.commons.util.StringProperties;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.commons cannot be resolved
>>>>
>>>> To get a better clue about what's going on, I switched the PDE
>>>> settings to full paranoia mode, i.e., flag errors on the slightest
>>>> whiff of anything suspicious. In my experience, this is a really
>>>> useful thing to do because it helps weed out problems that can mask
>>>> bigger problems later on.
>>>>
>>>> In this mode, I found that most Epsilon plugins fail to compile
>>>> because of the org.eclipse.epsilon.antlr plugin.
>>>>
>>>> Other plugins have out-of-order plugin dependencies in their
>>>> MANIFEST.MF files. I have fixed some of these but it's hard to do
>>>> this without some information about the Epsilon plugin architecture,
>>>> i.e., are there layers? e.g.:
>>>>
>>>> org.eclipse.epsilon.common.*
>>>> org.eclipse.epsilon.eol.*
>>>> org.eclipse.epsilon.????
>>>> org.eclipse.epsilon.????
>>>>
>>>> Layering the dependencies helps resolve compilation problems.
>>>>
>>>> I'm on a very tight schedule but I can help clean some of this.
>>>> It would be a shame to loose the Epsilon wizard capability for
>>>> unresolved compilation issues.
>>>>
>>>> Suggestions?
>>>>
>>>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #8222 is a reply to message #8062] |
Thu, 08 January 2009 05:22 |
Eclipse User |
|
|
|
Originally posted by: rafael.abstratt.com
I am too surprised that the order required bundles appear matter at all.
It sounds to me like a bug in PDE-build, as I don't think the OSGi
spec attributes any semantics to the order required bundles are listed.
Nicolas, do you have any idea why PDE Build seems to care about order?
Thanks,
Rafael
Nicolas Rouquette wrote:
> I managed to fix all problems which, roughly, fall into 3 categories.
>
> 1) out-of-order dependencies
>
> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>
> Require-Bundle: org.eclipse.epsilon.common.dt,
> org.eclipse.jface,
> org.eclipse.epsilon.commons,
> org.eclipse.emf,
> org.eclipse.emf.ecore,
> org.eclipse.epsilon.emc.emf,
> org.eclipse.epsilon.emc.emf.virtual,
> org.eclipse.ui,
> org.eclipse.core.runtime,
> org.eclipse.epsilon.util.emf
>
> fixed:
>
> Require-Bundle: org.eclipse.core.runtime,
> org.eclipse.jface,
> org.eclipse.ui,
> org.eclipse.emf,
> org.eclipse.emf.ecore,
> org.eclipse.epsilon.commons,
> org.eclipse.epsilon.common.dt,
> org.eclipse.epsilon.emc.emf,
> org.eclipse.epsilon.emc.emf.virtual,
> org.eclipse.epsilon.util.emf
>
> 2) missing indirect dependencies
>
> e.g., org.eclipse.epsilon.antlr
>
> This threw me off initially. I think that we can reduce the number of
> indirect dependencies the plugins need once there the order of the
> bundles is consistent with the dependencies for all epsilon plugins.
>
> 3) missing feature dependencies
>
> the continuous build failed because epsilon.eugenia.feature is missing a
> dependency on epsilon.feature.
>
> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>
> -- Nicolas.
>
> -- Nicolas.
>
> Nicolas Rouquette wrote:
>> At JPL, I use a Bamboo continuous build server to build a toolkit
>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>
>> I checked out the full Epsilon enchilada from SVN because it provides
>> a really nice scripting mechanism I can use with UML2Tools diagrams.
>> In my development workspace, I can launch a runtime environment with
>> epsilon plugins or with a product which includes the epsilon features
>> and everything works fine. Then, I tried to update my Bamboo product
>> configuration to build Epsilon. That's when I got an endless string of
>> compilation problems...
>>
>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>
>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>> files to
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 21)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.common cannot be resolved
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 22)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.common cannot be resolved
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 23)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.common.dt.util.LogUtil;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.common cannot be resolved
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 24)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.commons.util.StringProperties;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.commons cannot be resolved
>>
>> To get a better clue about what's going on, I switched the PDE
>> settings to full paranoia mode, i.e., flag errors on the slightest
>> whiff of anything suspicious. In my experience, this is a really
>> useful thing to do because it helps weed out problems that can mask
>> bigger problems later on.
>>
>> In this mode, I found that most Epsilon plugins fail to compile
>> because of the org.eclipse.epsilon.antlr plugin.
>>
>> Other plugins have out-of-order plugin dependencies in their
>> MANIFEST.MF files. I have fixed some of these but it's hard to do this
>> without some information about the Epsilon plugin architecture, i.e.,
>> are there layers? e.g.:
>>
>> org.eclipse.epsilon.common.*
>> org.eclipse.epsilon.eol.*
>> org.eclipse.epsilon.????
>> org.eclipse.epsilon.????
>>
>> Layering the dependencies helps resolve compilation problems.
>>
>> I'm on a very tight schedule but I can help clean some of this.
>> It would be a shame to loose the Epsilon wizard capability for
>> unresolved compilation issues.
>>
>> Suggestions?
>>
>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #9326 is a reply to message #8190] |
Tue, 27 January 2009 07:21 |
Nicolas Rouquette
Messages: 157
Registered: July 2009 |
Senior Member |
|
|
Dimitrios,
Unfortunately, I don't have a point of comparison between bamboo and OS
alternatives. Ideally, we should be able to just setup the same
continous build/test system that Eclipse itself uses; however, I haven't
figured out how to do that. It's one thing to do this for an Eclipse
project, it's quite another to do it in one's organization.
-- Nicolas.
Dimitrios Kolovos wrote:
> Hi Nicolas,
>
> Thanks for submitting this patch. I've tried to merge it with my
> workspace but I get a few errors which are probably due to the parallel
> evolution of the two copies. What I'll do is I'll install a continuous
> integration and build server in my machine and try to repeat the process
> you went through (so that I can also get a better understanding of what
> the problems are). I understand that Bamboo
> (http://www.atlassian.com/software/bamboo/) is commercial software so I
> was wondering if you have good experiences with any of the OS ones.
>
> Cheers,
> Dimitris
>
> Nicolas Rouquette wrote:
>> Indeed, I was initially thrown off as well because everything looked
>> peachy clean in my workspace with the usual PDE update site build
>> procedures. On the other hand, building from scratch is sufficiently
>> different that it is worth making sure all of the details that matter
>> to PDE are 100% kosher.
>>
>> Another thing that threw me off was how to extract a patch given that
>> I had to disconnect my workspace copy of the epsilon plugins and share
>> them to the SVN repository of our continuous build server. That's
>> another unusual procedure that is new territory for me as well. The
>> patch seems fine though. In hindsight, I think that fixing the
>> out-of-order dependencies among plugins in MANIFEST.MF files should
>> help you avoid adding indirect plugins like org.eclipse.epsilon.antlr
>> as I did for (2) too many times for my taste.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>>
>> -- Nicolas.
>>
>> Dimitrios Kolovos wrote:
>>> Hi Nicolas,
>>>
>>> Glad you managed to sort this one out and thanks for reporting back
>>> on it! I hadn't ever come across such issues before as I'm using the
>>> "Build all" facility of the update site editor which doesn't seem to
>>> care about the specific order of dependencies (or is smart enough to
>>> sort/resolve them behind the scene). Could you please attach a patch
>>> that aggregates the fixes you've done to the bugzilla?
>>>
>>> Cheers,
>>> Dimitris
>>>
>>> Nicolas Rouquette wrote:
>>>> I managed to fix all problems which, roughly, fall into 3 categories.
>>>>
>>>> 1) out-of-order dependencies
>>>>
>>>> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>>>>
>>>> Require-Bundle: org.eclipse.epsilon.common.dt,
>>>> org.eclipse.jface,
>>>> org.eclipse.epsilon.commons,
>>>> org.eclipse.emf,
>>>> org.eclipse.emf.ecore,
>>>> org.eclipse.epsilon.emc.emf,
>>>> org.eclipse.epsilon.emc.emf.virtual,
>>>> org.eclipse.ui,
>>>> org.eclipse.core.runtime,
>>>> org.eclipse.epsilon.util.emf
>>>>
>>>> fixed:
>>>>
>>>> Require-Bundle: org.eclipse.core.runtime,
>>>> org.eclipse.jface,
>>>> org.eclipse.ui,
>>>> org.eclipse.emf,
>>>> org.eclipse.emf.ecore,
>>>> org.eclipse.epsilon.commons,
>>>> org.eclipse.epsilon.common.dt,
>>>> org.eclipse.epsilon.emc.emf,
>>>> org.eclipse.epsilon.emc.emf.virtual,
>>>> org.eclipse.epsilon.util.emf
>>>>
>>>> 2) missing indirect dependencies
>>>>
>>>> e.g., org.eclipse.epsilon.antlr
>>>>
>>>> This threw me off initially. I think that we can reduce the number
>>>> of indirect dependencies the plugins need once there the order of
>>>> the bundles is consistent with the dependencies for all epsilon
>>>> plugins.
>>>>
>>>> 3) missing feature dependencies
>>>>
>>>> the continuous build failed because epsilon.eugenia.feature is
>>>> missing a dependency on epsilon.feature.
>>>>
>>>> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>>>>
>>>> -- Nicolas.
>>>>
>>>> -- Nicolas.
>>>>
>>>> Nicolas Rouquette wrote:
>>>>> At JPL, I use a Bamboo continuous build server to build a toolkit
>>>>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>>>>
>>>>> I checked out the full Epsilon enchilada from SVN because it
>>>>> provides a really nice scripting mechanism I can use with UML2Tools
>>>>> diagrams.
>>>>> In my development workspace, I can launch a runtime environment
>>>>> with epsilon plugins or with a product which includes the epsilon
>>>>> features and everything works fine. Then, I tried to update my
>>>>> Bamboo product configuration to build Epsilon. That's when I got an
>>>>> endless string of compilation problems...
>>>>>
>>>>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>>>
>>>>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>>>>> files to
>>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>>>
>>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>>> (at line 21)
>>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>>> org.eclipse.epsilon.common cannot be resolved
>>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>>> (at line 22)
>>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>>> org.eclipse.epsilon.common cannot be resolved
>>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>>> (at line 23)
>>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>>> org.eclipse.epsilon.common.dt.util.LogUtil;
>>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>>> org.eclipse.epsilon.common cannot be resolved
>>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>>> (at line 24)
>>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>>> org.eclipse.epsilon.commons.util.StringProperties;
>>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>>> org.eclipse.epsilon.commons cannot be resolved
>>>>>
>>>>> To get a better clue about what's going on, I switched the PDE
>>>>> settings to full paranoia mode, i.e., flag errors on the slightest
>>>>> whiff of anything suspicious. In my experience, this is a really
>>>>> useful thing to do because it helps weed out problems that can mask
>>>>> bigger problems later on.
>>>>>
>>>>> In this mode, I found that most Epsilon plugins fail to compile
>>>>> because of the org.eclipse.epsilon.antlr plugin.
>>>>>
>>>>> Other plugins have out-of-order plugin dependencies in their
>>>>> MANIFEST.MF files. I have fixed some of these but it's hard to do
>>>>> this without some information about the Epsilon plugin
>>>>> architecture, i.e., are there layers? e.g.:
>>>>>
>>>>> org.eclipse.epsilon.common.*
>>>>> org.eclipse.epsilon.eol.*
>>>>> org.eclipse.epsilon.????
>>>>> org.eclipse.epsilon.????
>>>>>
>>>>> Layering the dependencies helps resolve compilation problems.
>>>>>
>>>>> I'm on a very tight schedule but I can help clean some of this.
>>>>> It would be a shame to loose the Epsilon wizard capability for
>>>>> unresolved compilation issues.
>>>>>
>>>>> Suggestions?
>>>>>
>>>>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #9350 is a reply to message #8222] |
Tue, 27 January 2009 07:52 |
Nicolas Rouquette
Messages: 157
Registered: July 2009 |
Senior Member |
|
|
Rafael,
I've cross-posted to the PDE group where I hope someone can shed some
light on this issue which seems to be more general to me than just
building the Epsilon plugins/features in a continuous build environment.
Rafael Chaves wrote:
> I am too surprised that the order required bundles appear matter at all.
It is indeed surprising.
> It sounds to me like a bug in PDE-build, as I don't think the OSGi spec
> attributes any semantics to the order required bundles are listed.
Compare how we specify dependencies for plugins vs. features:
plugins => we can change the order of dependencies with up/down buttons
features => there is no support for editing the order of dependencies
If the ordering didn't matter, why would the PDE team bother to provide
the capability to edit it for plugins but not for features?
> Nicolas, do you have any idea why PDE Build seems to care about order?
Based on my experience, I can say 2 things for sure:
1) out-of-order plugin dependencies can trigger ClassNotFoundExceptions
when OSGi starts the plugin bundle.
2) in a fresh build, incompletely specified feature dependencies can
fail a build with the appearance of being some kind of out-of-order
dependency problem when in fact it is really a missing dependency problem.
3) these problems become more subtle to figure out with various idioms
for inversion of control (e.g., dependency injection, plugin extensions,
....)
-- Nicolas.
>
> Thanks,
>
> Rafael
>
> Nicolas Rouquette wrote:
>> I managed to fix all problems which, roughly, fall into 3 categories.
>>
>> 1) out-of-order dependencies
>>
>> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>>
>> Require-Bundle: org.eclipse.epsilon.common.dt,
>> org.eclipse.jface,
>> org.eclipse.epsilon.commons,
>> org.eclipse.emf,
>> org.eclipse.emf.ecore,
>> org.eclipse.epsilon.emc.emf,
>> org.eclipse.epsilon.emc.emf.virtual,
>> org.eclipse.ui,
>> org.eclipse.core.runtime,
>> org.eclipse.epsilon.util.emf
>>
>> fixed:
>>
>> Require-Bundle: org.eclipse.core.runtime,
>> org.eclipse.jface,
>> org.eclipse.ui,
>> org.eclipse.emf,
>> org.eclipse.emf.ecore,
>> org.eclipse.epsilon.commons,
>> org.eclipse.epsilon.common.dt,
>> org.eclipse.epsilon.emc.emf,
>> org.eclipse.epsilon.emc.emf.virtual,
>> org.eclipse.epsilon.util.emf
>>
>> 2) missing indirect dependencies
>>
>> e.g., org.eclipse.epsilon.antlr
>>
>> This threw me off initially. I think that we can reduce the number of
>> indirect dependencies the plugins need once there the order of the
>> bundles is consistent with the dependencies for all epsilon plugins.
>>
>> 3) missing feature dependencies
>>
>> the continuous build failed because epsilon.eugenia.feature is missing
>> a dependency on epsilon.feature.
>>
>> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>>
>> -- Nicolas.
>>
>> -- Nicolas.
>>
>> Nicolas Rouquette wrote:
>>> At JPL, I use a Bamboo continuous build server to build a toolkit
>>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>>
>>> I checked out the full Epsilon enchilada from SVN because it provides
>>> a really nice scripting mechanism I can use with UML2Tools diagrams.
>>> In my development workspace, I can launch a runtime environment with
>>> epsilon plugins or with a product which includes the epsilon features
>>> and everything works fine. Then, I tried to update my Bamboo product
>>> configuration to build Epsilon. That's when I got an endless string
>>> of compilation problems...
>>>
>>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>
>>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>>> files to
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 21)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.common cannot be resolved
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 22)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.common cannot be resolved
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 23)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.common.dt.util.LogUtil;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.common cannot be resolved
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 24)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.commons.util.StringProperties;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.commons cannot be resolved
>>>
>>> To get a better clue about what's going on, I switched the PDE
>>> settings to full paranoia mode, i.e., flag errors on the slightest
>>> whiff of anything suspicious. In my experience, this is a really
>>> useful thing to do because it helps weed out problems that can mask
>>> bigger problems later on.
>>>
>>> In this mode, I found that most Epsilon plugins fail to compile
>>> because of the org.eclipse.epsilon.antlr plugin.
>>>
>>> Other plugins have out-of-order plugin dependencies in their
>>> MANIFEST.MF files. I have fixed some of these but it's hard to do
>>> this without some information about the Epsilon plugin architecture,
>>> i.e., are there layers? e.g.:
>>>
>>> org.eclipse.epsilon.common.*
>>> org.eclipse.epsilon.eol.*
>>> org.eclipse.epsilon.????
>>> org.eclipse.epsilon.????
>>>
>>> Layering the dependencies helps resolve compilation problems.
>>>
>>> I'm on a very tight schedule but I can help clean some of this.
>>> It would be a shame to loose the Epsilon wizard capability for
>>> unresolved compilation issues.
>>>
>>> Suggestions?
>>>
>>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #11662 is a reply to message #9350] |
Tue, 10 February 2009 12:09 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Nicolas,
I see there are no replies to this thread in eclipse.platform.pde so I
was wondering if you've managed to make any progress on this yourself.
Cheers,
Dimitris
Nicolas Rouquette wrote:
> Rafael,
>
> I've cross-posted to the PDE group where I hope someone can shed some
> light on this issue which seems to be more general to me than just
> building the Epsilon plugins/features in a continuous build environment.
>
> Rafael Chaves wrote:
>> I am too surprised that the order required bundles appear matter at all.
>
> It is indeed surprising.
>
>> It sounds to me like a bug in PDE-build, as I don't think the OSGi
>> spec attributes any semantics to the order required bundles are listed.
>
> Compare how we specify dependencies for plugins vs. features:
>
> plugins => we can change the order of dependencies with up/down buttons
> features => there is no support for editing the order of dependencies
>
> If the ordering didn't matter, why would the PDE team bother to provide
> the capability to edit it for plugins but not for features?
>
>> Nicolas, do you have any idea why PDE Build seems to care about order?
>
> Based on my experience, I can say 2 things for sure:
>
> 1) out-of-order plugin dependencies can trigger ClassNotFoundExceptions
> when OSGi starts the plugin bundle.
>
> 2) in a fresh build, incompletely specified feature dependencies can
> fail a build with the appearance of being some kind of out-of-order
> dependency problem when in fact it is really a missing dependency problem.
>
> 3) these problems become more subtle to figure out with various idioms
> for inversion of control (e.g., dependency injection, plugin extensions,
> ...)
>
> -- Nicolas.
>
>>
>> Thanks,
>>
>> Rafael
>>
>> Nicolas Rouquette wrote:
>>> I managed to fix all problems which, roughly, fall into 3 categories.
>>>
>>> 1) out-of-order dependencies
>>>
>>> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>>>
>>> Require-Bundle: org.eclipse.epsilon.common.dt,
>>> org.eclipse.jface,
>>> org.eclipse.epsilon.commons,
>>> org.eclipse.emf,
>>> org.eclipse.emf.ecore,
>>> org.eclipse.epsilon.emc.emf,
>>> org.eclipse.epsilon.emc.emf.virtual,
>>> org.eclipse.ui,
>>> org.eclipse.core.runtime,
>>> org.eclipse.epsilon.util.emf
>>>
>>> fixed:
>>>
>>> Require-Bundle: org.eclipse.core.runtime,
>>> org.eclipse.jface,
>>> org.eclipse.ui,
>>> org.eclipse.emf,
>>> org.eclipse.emf.ecore,
>>> org.eclipse.epsilon.commons,
>>> org.eclipse.epsilon.common.dt,
>>> org.eclipse.epsilon.emc.emf,
>>> org.eclipse.epsilon.emc.emf.virtual,
>>> org.eclipse.epsilon.util.emf
>>>
>>> 2) missing indirect dependencies
>>>
>>> e.g., org.eclipse.epsilon.antlr
>>>
>>> This threw me off initially. I think that we can reduce the number of
>>> indirect dependencies the plugins need once there the order of the
>>> bundles is consistent with the dependencies for all epsilon plugins.
>>>
>>> 3) missing feature dependencies
>>>
>>> the continuous build failed because epsilon.eugenia.feature is
>>> missing a dependency on epsilon.feature.
>>>
>>> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>>>
>>> -- Nicolas.
>>>
>>> -- Nicolas.
>>>
>>> Nicolas Rouquette wrote:
>>>> At JPL, I use a Bamboo continuous build server to build a toolkit
>>>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>>>
>>>> I checked out the full Epsilon enchilada from SVN because it
>>>> provides a really nice scripting mechanism I can use with UML2Tools
>>>> diagrams.
>>>> In my development workspace, I can launch a runtime environment with
>>>> epsilon plugins or with a product which includes the epsilon
>>>> features and everything works fine. Then, I tried to update my
>>>> Bamboo product configuration to build Epsilon. That's when I got an
>>>> endless string of compilation problems...
>>>>
>>>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>>
>>>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>>>> files to
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>>
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 21)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.common cannot be resolved
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 22)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.common cannot be resolved
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 23)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.common.dt.util.LogUtil;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.common cannot be resolved
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 24)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.commons.util.StringProperties;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.commons cannot be resolved
>>>>
>>>> To get a better clue about what's going on, I switched the PDE
>>>> settings to full paranoia mode, i.e., flag errors on the slightest
>>>> whiff of anything suspicious. In my experience, this is a really
>>>> useful thing to do because it helps weed out problems that can mask
>>>> bigger problems later on.
>>>>
>>>> In this mode, I found that most Epsilon plugins fail to compile
>>>> because of the org.eclipse.epsilon.antlr plugin.
>>>>
>>>> Other plugins have out-of-order plugin dependencies in their
>>>> MANIFEST.MF files. I have fixed some of these but it's hard to do
>>>> this without some information about the Epsilon plugin architecture,
>>>> i.e., are there layers? e.g.:
>>>>
>>>> org.eclipse.epsilon.common.*
>>>> org.eclipse.epsilon.eol.*
>>>> org.eclipse.epsilon.????
>>>> org.eclipse.epsilon.????
>>>>
>>>> Layering the dependencies helps resolve compilation problems.
>>>>
>>>> I'm on a very tight schedule but I can help clean some of this.
>>>> It would be a shame to loose the Epsilon wizard capability for
>>>> unresolved compilation issues.
>>>>
>>>> Suggestions?
>>>>
>>>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #563490 is a reply to message #8032] |
Tue, 06 January 2009 21:33 |
Nicolas Rouquette
Messages: 157
Registered: July 2009 |
Senior Member |
|
|
I managed to fix all problems which, roughly, fall into 3 categories.
1) out-of-order dependencies
e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
Require-Bundle: org.eclipse.epsilon.common.dt,
org.eclipse.jface,
org.eclipse.epsilon.commons,
org.eclipse.emf,
org.eclipse.emf.ecore,
org.eclipse.epsilon.emc.emf,
org.eclipse.epsilon.emc.emf.virtual,
org.eclipse.ui,
org.eclipse.core.runtime,
org.eclipse.epsilon.util.emf
fixed:
Require-Bundle: org.eclipse.core.runtime,
org.eclipse.jface,
org.eclipse.ui,
org.eclipse.emf,
org.eclipse.emf.ecore,
org.eclipse.epsilon.commons,
org.eclipse.epsilon.common.dt,
org.eclipse.epsilon.emc.emf,
org.eclipse.epsilon.emc.emf.virtual,
org.eclipse.epsilon.util.emf
2) missing indirect dependencies
e.g., org.eclipse.epsilon.antlr
This threw me off initially. I think that we can reduce the number of
indirect dependencies the plugins need once there the order of the
bundles is consistent with the dependencies for all epsilon plugins.
3) missing feature dependencies
the continuous build failed because epsilon.eugenia.feature is missing a
dependency on epsilon.feature.
see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
-- Nicolas.
-- Nicolas.
Nicolas Rouquette wrote:
> At JPL, I use a Bamboo continuous build server to build a toolkit based
> on Ganymede SR1 with the UML2Tools components. So far so good.
>
> I checked out the full Epsilon enchilada from SVN because it provides a
> really nice scripting mechanism I can use with UML2Tools diagrams.
> In my development workspace, I can launch a runtime environment with
> epsilon plugins or with a product which includes the epsilon features
> and everything works fine. Then, I tried to update my Bamboo product
> configuration to build Epsilon. That's when I got an endless string of
> compilation problems...
>
> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>
> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
> files to
> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>
> 05-Jan-2009 20:43:49 [java] [javac] ----------
> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
> (at line 21)
> 05-Jan-2009 20:43:49 [java] [javac] import
> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
> 05-Jan-2009 20:43:49 [java] [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 05-Jan-2009 20:43:49 [java] [javac] The import
> org.eclipse.epsilon.common cannot be resolved
> 05-Jan-2009 20:43:49 [java] [javac] ----------
> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
> (at line 22)
> 05-Jan-2009 20:43:49 [java] [javac] import
> org.eclipse.epsilon.common.dt.util.EclipseUtil;
> 05-Jan-2009 20:43:49 [java] [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 05-Jan-2009 20:43:49 [java] [javac] The import
> org.eclipse.epsilon.common cannot be resolved
> 05-Jan-2009 20:43:49 [java] [javac] ----------
> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
> (at line 23)
> 05-Jan-2009 20:43:49 [java] [javac] import
> org.eclipse.epsilon.common.dt.util.LogUtil;
> 05-Jan-2009 20:43:49 [java] [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 05-Jan-2009 20:43:49 [java] [javac] The import
> org.eclipse.epsilon.common cannot be resolved
> 05-Jan-2009 20:43:49 [java] [javac] ----------
> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
> (at line 24)
> 05-Jan-2009 20:43:49 [java] [javac] import
> org.eclipse.epsilon.commons.util.StringProperties;
> 05-Jan-2009 20:43:49 [java] [javac]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 05-Jan-2009 20:43:49 [java] [javac] The import
> org.eclipse.epsilon.commons cannot be resolved
>
> To get a better clue about what's going on, I switched the PDE settings
> to full paranoia mode, i.e., flag errors on the slightest whiff of
> anything suspicious. In my experience, this is a really useful thing to
> do because it helps weed out problems that can mask bigger problems
> later on.
>
> In this mode, I found that most Epsilon plugins fail to compile because
> of the org.eclipse.epsilon.antlr plugin.
>
> Other plugins have out-of-order plugin dependencies in their MANIFEST.MF
> files. I have fixed some of these but it's hard to do this without some
> information about the Epsilon plugin architecture, i.e., are there
> layers? e.g.:
>
> org.eclipse.epsilon.common.*
> org.eclipse.epsilon.eol.*
> org.eclipse.epsilon.????
> org.eclipse.epsilon.????
>
> Layering the dependencies helps resolve compilation problems.
>
> I'm on a very tight schedule but I can help clean some of this.
> It would be a shame to loose the Epsilon wizard capability for
> unresolved compilation issues.
>
> Suggestions?
>
> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #563532 is a reply to message #8062] |
Tue, 06 January 2009 23:36 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Nicolas,
Glad you managed to sort this one out and thanks for reporting back on
it! I hadn't ever come across such issues before as I'm using the "Build
all" facility of the update site editor which doesn't seem to care about
the specific order of dependencies (or is smart enough to sort/resolve
them behind the scene). Could you please attach a patch that aggregates
the fixes you've done to the bugzilla?
Cheers,
Dimitris
Nicolas Rouquette wrote:
> I managed to fix all problems which, roughly, fall into 3 categories.
>
> 1) out-of-order dependencies
>
> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>
> Require-Bundle: org.eclipse.epsilon.common.dt,
> org.eclipse.jface,
> org.eclipse.epsilon.commons,
> org.eclipse.emf,
> org.eclipse.emf.ecore,
> org.eclipse.epsilon.emc.emf,
> org.eclipse.epsilon.emc.emf.virtual,
> org.eclipse.ui,
> org.eclipse.core.runtime,
> org.eclipse.epsilon.util.emf
>
> fixed:
>
> Require-Bundle: org.eclipse.core.runtime,
> org.eclipse.jface,
> org.eclipse.ui,
> org.eclipse.emf,
> org.eclipse.emf.ecore,
> org.eclipse.epsilon.commons,
> org.eclipse.epsilon.common.dt,
> org.eclipse.epsilon.emc.emf,
> org.eclipse.epsilon.emc.emf.virtual,
> org.eclipse.epsilon.util.emf
>
> 2) missing indirect dependencies
>
> e.g., org.eclipse.epsilon.antlr
>
> This threw me off initially. I think that we can reduce the number of
> indirect dependencies the plugins need once there the order of the
> bundles is consistent with the dependencies for all epsilon plugins.
>
> 3) missing feature dependencies
>
> the continuous build failed because epsilon.eugenia.feature is missing a
> dependency on epsilon.feature.
>
> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>
> -- Nicolas.
>
> -- Nicolas.
>
> Nicolas Rouquette wrote:
>> At JPL, I use a Bamboo continuous build server to build a toolkit
>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>
>> I checked out the full Epsilon enchilada from SVN because it provides
>> a really nice scripting mechanism I can use with UML2Tools diagrams.
>> In my development workspace, I can launch a runtime environment with
>> epsilon plugins or with a product which includes the epsilon features
>> and everything works fine. Then, I tried to update my Bamboo product
>> configuration to build Epsilon. That's when I got an endless string of
>> compilation problems...
>>
>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>
>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>> files to
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 21)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.common cannot be resolved
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 22)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.common cannot be resolved
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 23)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.common.dt.util.LogUtil;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.common cannot be resolved
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 24)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.commons.util.StringProperties;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.commons cannot be resolved
>>
>> To get a better clue about what's going on, I switched the PDE
>> settings to full paranoia mode, i.e., flag errors on the slightest
>> whiff of anything suspicious. In my experience, this is a really
>> useful thing to do because it helps weed out problems that can mask
>> bigger problems later on.
>>
>> In this mode, I found that most Epsilon plugins fail to compile
>> because of the org.eclipse.epsilon.antlr plugin.
>>
>> Other plugins have out-of-order plugin dependencies in their
>> MANIFEST.MF files. I have fixed some of these but it's hard to do this
>> without some information about the Epsilon plugin architecture, i.e.,
>> are there layers? e.g.:
>>
>> org.eclipse.epsilon.common.*
>> org.eclipse.epsilon.eol.*
>> org.eclipse.epsilon.????
>> org.eclipse.epsilon.????
>>
>> Layering the dependencies helps resolve compilation problems.
>>
>> I'm on a very tight schedule but I can help clean some of this.
>> It would be a shame to loose the Epsilon wizard capability for
>> unresolved compilation issues.
>>
>> Suggestions?
>>
>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #563554 is a reply to message #8126] |
Wed, 07 January 2009 06:28 |
Nicolas Rouquette
Messages: 157
Registered: July 2009 |
Senior Member |
|
|
Indeed, I was initially thrown off as well because everything looked
peachy clean in my workspace with the usual PDE update site build
procedures. On the other hand, building from scratch is sufficiently
different that it is worth making sure all of the details that matter to
PDE are 100% kosher.
Another thing that threw me off was how to extract a patch given that I
had to disconnect my workspace copy of the epsilon plugins and share
them to the SVN repository of our continuous build server. That's
another unusual procedure that is new territory for me as well. The
patch seems fine though. In hindsight, I think that fixing the
out-of-order dependencies among plugins in MANIFEST.MF files should help
you avoid adding indirect plugins like org.eclipse.epsilon.antlr as I
did for (2) too many times for my taste.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
-- Nicolas.
Dimitrios Kolovos wrote:
> Hi Nicolas,
>
> Glad you managed to sort this one out and thanks for reporting back on
> it! I hadn't ever come across such issues before as I'm using the "Build
> all" facility of the update site editor which doesn't seem to care about
> the specific order of dependencies (or is smart enough to sort/resolve
> them behind the scene). Could you please attach a patch that aggregates
> the fixes you've done to the bugzilla?
>
> Cheers,
> Dimitris
>
> Nicolas Rouquette wrote:
>> I managed to fix all problems which, roughly, fall into 3 categories.
>>
>> 1) out-of-order dependencies
>>
>> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>>
>> Require-Bundle: org.eclipse.epsilon.common.dt,
>> org.eclipse.jface,
>> org.eclipse.epsilon.commons,
>> org.eclipse.emf,
>> org.eclipse.emf.ecore,
>> org.eclipse.epsilon.emc.emf,
>> org.eclipse.epsilon.emc.emf.virtual,
>> org.eclipse.ui,
>> org.eclipse.core.runtime,
>> org.eclipse.epsilon.util.emf
>>
>> fixed:
>>
>> Require-Bundle: org.eclipse.core.runtime,
>> org.eclipse.jface,
>> org.eclipse.ui,
>> org.eclipse.emf,
>> org.eclipse.emf.ecore,
>> org.eclipse.epsilon.commons,
>> org.eclipse.epsilon.common.dt,
>> org.eclipse.epsilon.emc.emf,
>> org.eclipse.epsilon.emc.emf.virtual,
>> org.eclipse.epsilon.util.emf
>>
>> 2) missing indirect dependencies
>>
>> e.g., org.eclipse.epsilon.antlr
>>
>> This threw me off initially. I think that we can reduce the number of
>> indirect dependencies the plugins need once there the order of the
>> bundles is consistent with the dependencies for all epsilon plugins.
>>
>> 3) missing feature dependencies
>>
>> the continuous build failed because epsilon.eugenia.feature is missing
>> a dependency on epsilon.feature.
>>
>> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>>
>> -- Nicolas.
>>
>> -- Nicolas.
>>
>> Nicolas Rouquette wrote:
>>> At JPL, I use a Bamboo continuous build server to build a toolkit
>>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>>
>>> I checked out the full Epsilon enchilada from SVN because it provides
>>> a really nice scripting mechanism I can use with UML2Tools diagrams.
>>> In my development workspace, I can launch a runtime environment with
>>> epsilon plugins or with a product which includes the epsilon features
>>> and everything works fine. Then, I tried to update my Bamboo product
>>> configuration to build Epsilon. That's when I got an endless string
>>> of compilation problems...
>>>
>>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>
>>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>>> files to
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 21)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.common cannot be resolved
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 22)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.common cannot be resolved
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 23)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.common.dt.util.LogUtil;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.common cannot be resolved
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 24)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.commons.util.StringProperties;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.commons cannot be resolved
>>>
>>> To get a better clue about what's going on, I switched the PDE
>>> settings to full paranoia mode, i.e., flag errors on the slightest
>>> whiff of anything suspicious. In my experience, this is a really
>>> useful thing to do because it helps weed out problems that can mask
>>> bigger problems later on.
>>>
>>> In this mode, I found that most Epsilon plugins fail to compile
>>> because of the org.eclipse.epsilon.antlr plugin.
>>>
>>> Other plugins have out-of-order plugin dependencies in their
>>> MANIFEST.MF files. I have fixed some of these but it's hard to do
>>> this without some information about the Epsilon plugin architecture,
>>> i.e., are there layers? e.g.:
>>>
>>> org.eclipse.epsilon.common.*
>>> org.eclipse.epsilon.eol.*
>>> org.eclipse.epsilon.????
>>> org.eclipse.epsilon.????
>>>
>>> Layering the dependencies helps resolve compilation problems.
>>>
>>> I'm on a very tight schedule but I can help clean some of this.
>>> It would be a shame to loose the Epsilon wizard capability for
>>> unresolved compilation issues.
>>>
>>> Suggestions?
>>>
>>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #563576 is a reply to message #8158] |
Wed, 07 January 2009 14:56 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Nicolas,
Thanks for submitting this patch. I've tried to merge it with my
workspace but I get a few errors which are probably due to the parallel
evolution of the two copies. What I'll do is I'll install a continuous
integration and build server in my machine and try to repeat the process
you went through (so that I can also get a better understanding of what
the problems are). I understand that Bamboo
(http://www.atlassian.com/software/bamboo/) is commercial software so I
was wondering if you have good experiences with any of the OS ones.
Cheers,
Dimitris
Nicolas Rouquette wrote:
> Indeed, I was initially thrown off as well because everything looked
> peachy clean in my workspace with the usual PDE update site build
> procedures. On the other hand, building from scratch is sufficiently
> different that it is worth making sure all of the details that matter to
> PDE are 100% kosher.
>
> Another thing that threw me off was how to extract a patch given that I
> had to disconnect my workspace copy of the epsilon plugins and share
> them to the SVN repository of our continuous build server. That's
> another unusual procedure that is new territory for me as well. The
> patch seems fine though. In hindsight, I think that fixing the
> out-of-order dependencies among plugins in MANIFEST.MF files should help
> you avoid adding indirect plugins like org.eclipse.epsilon.antlr as I
> did for (2) too many times for my taste.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>
> -- Nicolas.
>
> Dimitrios Kolovos wrote:
>> Hi Nicolas,
>>
>> Glad you managed to sort this one out and thanks for reporting back on
>> it! I hadn't ever come across such issues before as I'm using the
>> "Build all" facility of the update site editor which doesn't seem to
>> care about the specific order of dependencies (or is smart enough to
>> sort/resolve them behind the scene). Could you please attach a patch
>> that aggregates the fixes you've done to the bugzilla?
>>
>> Cheers,
>> Dimitris
>>
>> Nicolas Rouquette wrote:
>>> I managed to fix all problems which, roughly, fall into 3 categories.
>>>
>>> 1) out-of-order dependencies
>>>
>>> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>>>
>>> Require-Bundle: org.eclipse.epsilon.common.dt,
>>> org.eclipse.jface,
>>> org.eclipse.epsilon.commons,
>>> org.eclipse.emf,
>>> org.eclipse.emf.ecore,
>>> org.eclipse.epsilon.emc.emf,
>>> org.eclipse.epsilon.emc.emf.virtual,
>>> org.eclipse.ui,
>>> org.eclipse.core.runtime,
>>> org.eclipse.epsilon.util.emf
>>>
>>> fixed:
>>>
>>> Require-Bundle: org.eclipse.core.runtime,
>>> org.eclipse.jface,
>>> org.eclipse.ui,
>>> org.eclipse.emf,
>>> org.eclipse.emf.ecore,
>>> org.eclipse.epsilon.commons,
>>> org.eclipse.epsilon.common.dt,
>>> org.eclipse.epsilon.emc.emf,
>>> org.eclipse.epsilon.emc.emf.virtual,
>>> org.eclipse.epsilon.util.emf
>>>
>>> 2) missing indirect dependencies
>>>
>>> e.g., org.eclipse.epsilon.antlr
>>>
>>> This threw me off initially. I think that we can reduce the number of
>>> indirect dependencies the plugins need once there the order of the
>>> bundles is consistent with the dependencies for all epsilon plugins.
>>>
>>> 3) missing feature dependencies
>>>
>>> the continuous build failed because epsilon.eugenia.feature is
>>> missing a dependency on epsilon.feature.
>>>
>>> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>>>
>>> -- Nicolas.
>>>
>>> -- Nicolas.
>>>
>>> Nicolas Rouquette wrote:
>>>> At JPL, I use a Bamboo continuous build server to build a toolkit
>>>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>>>
>>>> I checked out the full Epsilon enchilada from SVN because it
>>>> provides a really nice scripting mechanism I can use with UML2Tools
>>>> diagrams.
>>>> In my development workspace, I can launch a runtime environment with
>>>> epsilon plugins or with a product which includes the epsilon
>>>> features and everything works fine. Then, I tried to update my
>>>> Bamboo product configuration to build Epsilon. That's when I got an
>>>> endless string of compilation problems...
>>>>
>>>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>>
>>>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>>>> files to
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>>
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 21)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.common cannot be resolved
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 22)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.common cannot be resolved
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 23)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.common.dt.util.LogUtil;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.common cannot be resolved
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 24)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.commons.util.StringProperties;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.commons cannot be resolved
>>>>
>>>> To get a better clue about what's going on, I switched the PDE
>>>> settings to full paranoia mode, i.e., flag errors on the slightest
>>>> whiff of anything suspicious. In my experience, this is a really
>>>> useful thing to do because it helps weed out problems that can mask
>>>> bigger problems later on.
>>>>
>>>> In this mode, I found that most Epsilon plugins fail to compile
>>>> because of the org.eclipse.epsilon.antlr plugin.
>>>>
>>>> Other plugins have out-of-order plugin dependencies in their
>>>> MANIFEST.MF files. I have fixed some of these but it's hard to do
>>>> this without some information about the Epsilon plugin architecture,
>>>> i.e., are there layers? e.g.:
>>>>
>>>> org.eclipse.epsilon.common.*
>>>> org.eclipse.epsilon.eol.*
>>>> org.eclipse.epsilon.????
>>>> org.eclipse.epsilon.????
>>>>
>>>> Layering the dependencies helps resolve compilation problems.
>>>>
>>>> I'm on a very tight schedule but I can help clean some of this.
>>>> It would be a shame to loose the Epsilon wizard capability for
>>>> unresolved compilation issues.
>>>>
>>>> Suggestions?
>>>>
>>>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #563603 is a reply to message #8062] |
Thu, 08 January 2009 05:22 |
Rafael Chaves
Messages: 362
Registered: July 2009 |
Senior Member |
|
|
I am too surprised that the order required bundles appear matter at all.
It sounds to me like a bug in PDE-build, as I don't think the OSGi
spec attributes any semantics to the order required bundles are listed.
Nicolas, do you have any idea why PDE Build seems to care about order?
Thanks,
Rafael
Nicolas Rouquette wrote:
> I managed to fix all problems which, roughly, fall into 3 categories.
>
> 1) out-of-order dependencies
>
> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>
> Require-Bundle: org.eclipse.epsilon.common.dt,
> org.eclipse.jface,
> org.eclipse.epsilon.commons,
> org.eclipse.emf,
> org.eclipse.emf.ecore,
> org.eclipse.epsilon.emc.emf,
> org.eclipse.epsilon.emc.emf.virtual,
> org.eclipse.ui,
> org.eclipse.core.runtime,
> org.eclipse.epsilon.util.emf
>
> fixed:
>
> Require-Bundle: org.eclipse.core.runtime,
> org.eclipse.jface,
> org.eclipse.ui,
> org.eclipse.emf,
> org.eclipse.emf.ecore,
> org.eclipse.epsilon.commons,
> org.eclipse.epsilon.common.dt,
> org.eclipse.epsilon.emc.emf,
> org.eclipse.epsilon.emc.emf.virtual,
> org.eclipse.epsilon.util.emf
>
> 2) missing indirect dependencies
>
> e.g., org.eclipse.epsilon.antlr
>
> This threw me off initially. I think that we can reduce the number of
> indirect dependencies the plugins need once there the order of the
> bundles is consistent with the dependencies for all epsilon plugins.
>
> 3) missing feature dependencies
>
> the continuous build failed because epsilon.eugenia.feature is missing a
> dependency on epsilon.feature.
>
> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>
> -- Nicolas.
>
> -- Nicolas.
>
> Nicolas Rouquette wrote:
>> At JPL, I use a Bamboo continuous build server to build a toolkit
>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>
>> I checked out the full Epsilon enchilada from SVN because it provides
>> a really nice scripting mechanism I can use with UML2Tools diagrams.
>> In my development workspace, I can launch a runtime environment with
>> epsilon plugins or with a product which includes the epsilon features
>> and everything works fine. Then, I tried to update my Bamboo product
>> configuration to build Epsilon. That's when I got an endless string of
>> compilation problems...
>>
>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>
>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>> files to
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 21)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.common cannot be resolved
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 22)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.common cannot be resolved
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 23)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.common.dt.util.LogUtil;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.common cannot be resolved
>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>> (at line 24)
>> 05-Jan-2009 20:43:49 [java] [javac] import
>> org.eclipse.epsilon.commons.util.StringProperties;
>> 05-Jan-2009 20:43:49 [java] [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 05-Jan-2009 20:43:49 [java] [javac] The import
>> org.eclipse.epsilon.commons cannot be resolved
>>
>> To get a better clue about what's going on, I switched the PDE
>> settings to full paranoia mode, i.e., flag errors on the slightest
>> whiff of anything suspicious. In my experience, this is a really
>> useful thing to do because it helps weed out problems that can mask
>> bigger problems later on.
>>
>> In this mode, I found that most Epsilon plugins fail to compile
>> because of the org.eclipse.epsilon.antlr plugin.
>>
>> Other plugins have out-of-order plugin dependencies in their
>> MANIFEST.MF files. I have fixed some of these but it's hard to do this
>> without some information about the Epsilon plugin architecture, i.e.,
>> are there layers? e.g.:
>>
>> org.eclipse.epsilon.common.*
>> org.eclipse.epsilon.eol.*
>> org.eclipse.epsilon.????
>> org.eclipse.epsilon.????
>>
>> Layering the dependencies helps resolve compilation problems.
>>
>> I'm on a very tight schedule but I can help clean some of this.
>> It would be a shame to loose the Epsilon wizard capability for
>> unresolved compilation issues.
>>
>> Suggestions?
>>
>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #563925 is a reply to message #8190] |
Tue, 27 January 2009 07:21 |
Nicolas Rouquette
Messages: 157
Registered: July 2009 |
Senior Member |
|
|
Dimitrios,
Unfortunately, I don't have a point of comparison between bamboo and OS
alternatives. Ideally, we should be able to just setup the same
continous build/test system that Eclipse itself uses; however, I haven't
figured out how to do that. It's one thing to do this for an Eclipse
project, it's quite another to do it in one's organization.
-- Nicolas.
Dimitrios Kolovos wrote:
> Hi Nicolas,
>
> Thanks for submitting this patch. I've tried to merge it with my
> workspace but I get a few errors which are probably due to the parallel
> evolution of the two copies. What I'll do is I'll install a continuous
> integration and build server in my machine and try to repeat the process
> you went through (so that I can also get a better understanding of what
> the problems are). I understand that Bamboo
> (http://www.atlassian.com/software/bamboo/) is commercial software so I
> was wondering if you have good experiences with any of the OS ones.
>
> Cheers,
> Dimitris
>
> Nicolas Rouquette wrote:
>> Indeed, I was initially thrown off as well because everything looked
>> peachy clean in my workspace with the usual PDE update site build
>> procedures. On the other hand, building from scratch is sufficiently
>> different that it is worth making sure all of the details that matter
>> to PDE are 100% kosher.
>>
>> Another thing that threw me off was how to extract a patch given that
>> I had to disconnect my workspace copy of the epsilon plugins and share
>> them to the SVN repository of our continuous build server. That's
>> another unusual procedure that is new territory for me as well. The
>> patch seems fine though. In hindsight, I think that fixing the
>> out-of-order dependencies among plugins in MANIFEST.MF files should
>> help you avoid adding indirect plugins like org.eclipse.epsilon.antlr
>> as I did for (2) too many times for my taste.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>>
>> -- Nicolas.
>>
>> Dimitrios Kolovos wrote:
>>> Hi Nicolas,
>>>
>>> Glad you managed to sort this one out and thanks for reporting back
>>> on it! I hadn't ever come across such issues before as I'm using the
>>> "Build all" facility of the update site editor which doesn't seem to
>>> care about the specific order of dependencies (or is smart enough to
>>> sort/resolve them behind the scene). Could you please attach a patch
>>> that aggregates the fixes you've done to the bugzilla?
>>>
>>> Cheers,
>>> Dimitris
>>>
>>> Nicolas Rouquette wrote:
>>>> I managed to fix all problems which, roughly, fall into 3 categories.
>>>>
>>>> 1) out-of-order dependencies
>>>>
>>>> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>>>>
>>>> Require-Bundle: org.eclipse.epsilon.common.dt,
>>>> org.eclipse.jface,
>>>> org.eclipse.epsilon.commons,
>>>> org.eclipse.emf,
>>>> org.eclipse.emf.ecore,
>>>> org.eclipse.epsilon.emc.emf,
>>>> org.eclipse.epsilon.emc.emf.virtual,
>>>> org.eclipse.ui,
>>>> org.eclipse.core.runtime,
>>>> org.eclipse.epsilon.util.emf
>>>>
>>>> fixed:
>>>>
>>>> Require-Bundle: org.eclipse.core.runtime,
>>>> org.eclipse.jface,
>>>> org.eclipse.ui,
>>>> org.eclipse.emf,
>>>> org.eclipse.emf.ecore,
>>>> org.eclipse.epsilon.commons,
>>>> org.eclipse.epsilon.common.dt,
>>>> org.eclipse.epsilon.emc.emf,
>>>> org.eclipse.epsilon.emc.emf.virtual,
>>>> org.eclipse.epsilon.util.emf
>>>>
>>>> 2) missing indirect dependencies
>>>>
>>>> e.g., org.eclipse.epsilon.antlr
>>>>
>>>> This threw me off initially. I think that we can reduce the number
>>>> of indirect dependencies the plugins need once there the order of
>>>> the bundles is consistent with the dependencies for all epsilon
>>>> plugins.
>>>>
>>>> 3) missing feature dependencies
>>>>
>>>> the continuous build failed because epsilon.eugenia.feature is
>>>> missing a dependency on epsilon.feature.
>>>>
>>>> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>>>>
>>>> -- Nicolas.
>>>>
>>>> -- Nicolas.
>>>>
>>>> Nicolas Rouquette wrote:
>>>>> At JPL, I use a Bamboo continuous build server to build a toolkit
>>>>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>>>>
>>>>> I checked out the full Epsilon enchilada from SVN because it
>>>>> provides a really nice scripting mechanism I can use with UML2Tools
>>>>> diagrams.
>>>>> In my development workspace, I can launch a runtime environment
>>>>> with epsilon plugins or with a product which includes the epsilon
>>>>> features and everything works fine. Then, I tried to update my
>>>>> Bamboo product configuration to build Epsilon. That's when I got an
>>>>> endless string of compilation problems...
>>>>>
>>>>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>>>
>>>>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>>>>> files to
>>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>>>
>>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>>> (at line 21)
>>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>>> org.eclipse.epsilon.common cannot be resolved
>>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>>> (at line 22)
>>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>>> org.eclipse.epsilon.common cannot be resolved
>>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>>> (at line 23)
>>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>>> org.eclipse.epsilon.common.dt.util.LogUtil;
>>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>>> org.eclipse.epsilon.common cannot be resolved
>>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>>> (at line 24)
>>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>>> org.eclipse.epsilon.commons.util.StringProperties;
>>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>>> org.eclipse.epsilon.commons cannot be resolved
>>>>>
>>>>> To get a better clue about what's going on, I switched the PDE
>>>>> settings to full paranoia mode, i.e., flag errors on the slightest
>>>>> whiff of anything suspicious. In my experience, this is a really
>>>>> useful thing to do because it helps weed out problems that can mask
>>>>> bigger problems later on.
>>>>>
>>>>> In this mode, I found that most Epsilon plugins fail to compile
>>>>> because of the org.eclipse.epsilon.antlr plugin.
>>>>>
>>>>> Other plugins have out-of-order plugin dependencies in their
>>>>> MANIFEST.MF files. I have fixed some of these but it's hard to do
>>>>> this without some information about the Epsilon plugin
>>>>> architecture, i.e., are there layers? e.g.:
>>>>>
>>>>> org.eclipse.epsilon.common.*
>>>>> org.eclipse.epsilon.eol.*
>>>>> org.eclipse.epsilon.????
>>>>> org.eclipse.epsilon.????
>>>>>
>>>>> Layering the dependencies helps resolve compilation problems.
>>>>>
>>>>> I'm on a very tight schedule but I can help clean some of this.
>>>>> It would be a shame to loose the Epsilon wizard capability for
>>>>> unresolved compilation issues.
>>>>>
>>>>> Suggestions?
>>>>>
>>>>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #563953 is a reply to message #8222] |
Tue, 27 January 2009 07:52 |
Nicolas Rouquette
Messages: 157
Registered: July 2009 |
Senior Member |
|
|
Rafael,
I've cross-posted to the PDE group where I hope someone can shed some
light on this issue which seems to be more general to me than just
building the Epsilon plugins/features in a continuous build environment.
Rafael Chaves wrote:
> I am too surprised that the order required bundles appear matter at all.
It is indeed surprising.
> It sounds to me like a bug in PDE-build, as I don't think the OSGi spec
> attributes any semantics to the order required bundles are listed.
Compare how we specify dependencies for plugins vs. features:
plugins => we can change the order of dependencies with up/down buttons
features => there is no support for editing the order of dependencies
If the ordering didn't matter, why would the PDE team bother to provide
the capability to edit it for plugins but not for features?
> Nicolas, do you have any idea why PDE Build seems to care about order?
Based on my experience, I can say 2 things for sure:
1) out-of-order plugin dependencies can trigger ClassNotFoundExceptions
when OSGi starts the plugin bundle.
2) in a fresh build, incompletely specified feature dependencies can
fail a build with the appearance of being some kind of out-of-order
dependency problem when in fact it is really a missing dependency problem.
3) these problems become more subtle to figure out with various idioms
for inversion of control (e.g., dependency injection, plugin extensions,
....)
-- Nicolas.
>
> Thanks,
>
> Rafael
>
> Nicolas Rouquette wrote:
>> I managed to fix all problems which, roughly, fall into 3 categories.
>>
>> 1) out-of-order dependencies
>>
>> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>>
>> Require-Bundle: org.eclipse.epsilon.common.dt,
>> org.eclipse.jface,
>> org.eclipse.epsilon.commons,
>> org.eclipse.emf,
>> org.eclipse.emf.ecore,
>> org.eclipse.epsilon.emc.emf,
>> org.eclipse.epsilon.emc.emf.virtual,
>> org.eclipse.ui,
>> org.eclipse.core.runtime,
>> org.eclipse.epsilon.util.emf
>>
>> fixed:
>>
>> Require-Bundle: org.eclipse.core.runtime,
>> org.eclipse.jface,
>> org.eclipse.ui,
>> org.eclipse.emf,
>> org.eclipse.emf.ecore,
>> org.eclipse.epsilon.commons,
>> org.eclipse.epsilon.common.dt,
>> org.eclipse.epsilon.emc.emf,
>> org.eclipse.epsilon.emc.emf.virtual,
>> org.eclipse.epsilon.util.emf
>>
>> 2) missing indirect dependencies
>>
>> e.g., org.eclipse.epsilon.antlr
>>
>> This threw me off initially. I think that we can reduce the number of
>> indirect dependencies the plugins need once there the order of the
>> bundles is consistent with the dependencies for all epsilon plugins.
>>
>> 3) missing feature dependencies
>>
>> the continuous build failed because epsilon.eugenia.feature is missing
>> a dependency on epsilon.feature.
>>
>> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>>
>> -- Nicolas.
>>
>> -- Nicolas.
>>
>> Nicolas Rouquette wrote:
>>> At JPL, I use a Bamboo continuous build server to build a toolkit
>>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>>
>>> I checked out the full Epsilon enchilada from SVN because it provides
>>> a really nice scripting mechanism I can use with UML2Tools diagrams.
>>> In my development workspace, I can launch a runtime environment with
>>> epsilon plugins or with a product which includes the epsilon features
>>> and everything works fine. Then, I tried to update my Bamboo product
>>> configuration to build Epsilon. That's when I got an endless string
>>> of compilation problems...
>>>
>>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>
>>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>>> files to
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 21)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.common cannot be resolved
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 22)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.common cannot be resolved
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 23)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.common.dt.util.LogUtil;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.common cannot be resolved
>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>> (at line 24)
>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>> org.eclipse.epsilon.commons.util.StringProperties;
>>> 05-Jan-2009 20:43:49 [java] [javac]
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>> org.eclipse.epsilon.commons cannot be resolved
>>>
>>> To get a better clue about what's going on, I switched the PDE
>>> settings to full paranoia mode, i.e., flag errors on the slightest
>>> whiff of anything suspicious. In my experience, this is a really
>>> useful thing to do because it helps weed out problems that can mask
>>> bigger problems later on.
>>>
>>> In this mode, I found that most Epsilon plugins fail to compile
>>> because of the org.eclipse.epsilon.antlr plugin.
>>>
>>> Other plugins have out-of-order plugin dependencies in their
>>> MANIFEST.MF files. I have fixed some of these but it's hard to do
>>> this without some information about the Epsilon plugin architecture,
>>> i.e., are there layers? e.g.:
>>>
>>> org.eclipse.epsilon.common.*
>>> org.eclipse.epsilon.eol.*
>>> org.eclipse.epsilon.????
>>> org.eclipse.epsilon.????
>>>
>>> Layering the dependencies helps resolve compilation problems.
>>>
>>> I'm on a very tight schedule but I can help clean some of this.
>>> It would be a shame to loose the Epsilon wizard capability for
>>> unresolved compilation issues.
>>>
>>> Suggestions?
>>>
>>> -- Nicolas.
|
|
|
| Re: Building an Epsilon product is, well, hum... [message #564957 is a reply to message #9350] |
Tue, 10 February 2009 12:09 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Nicolas,
I see there are no replies to this thread in eclipse.platform.pde so I
was wondering if you've managed to make any progress on this yourself.
Cheers,
Dimitris
Nicolas Rouquette wrote:
> Rafael,
>
> I've cross-posted to the PDE group where I hope someone can shed some
> light on this issue which seems to be more general to me than just
> building the Epsilon plugins/features in a continuous build environment.
>
> Rafael Chaves wrote:
>> I am too surprised that the order required bundles appear matter at all.
>
> It is indeed surprising.
>
>> It sounds to me like a bug in PDE-build, as I don't think the OSGi
>> spec attributes any semantics to the order required bundles are listed.
>
> Compare how we specify dependencies for plugins vs. features:
>
> plugins => we can change the order of dependencies with up/down buttons
> features => there is no support for editing the order of dependencies
>
> If the ordering didn't matter, why would the PDE team bother to provide
> the capability to edit it for plugins but not for features?
>
>> Nicolas, do you have any idea why PDE Build seems to care about order?
>
> Based on my experience, I can say 2 things for sure:
>
> 1) out-of-order plugin dependencies can trigger ClassNotFoundExceptions
> when OSGi starts the plugin bundle.
>
> 2) in a fresh build, incompletely specified feature dependencies can
> fail a build with the appearance of being some kind of out-of-order
> dependency problem when in fact it is really a missing dependency problem.
>
> 3) these problems become more subtle to figure out with various idioms
> for inversion of control (e.g., dependency injection, plugin extensions,
> ...)
>
> -- Nicolas.
>
>>
>> Thanks,
>>
>> Rafael
>>
>> Nicolas Rouquette wrote:
>>> I managed to fix all problems which, roughly, fall into 3 categories.
>>>
>>> 1) out-of-order dependencies
>>>
>>> e,g, org.eclipse.epsilon.emc.emf.dt's MANIFEST.MF shows:
>>>
>>> Require-Bundle: org.eclipse.epsilon.common.dt,
>>> org.eclipse.jface,
>>> org.eclipse.epsilon.commons,
>>> org.eclipse.emf,
>>> org.eclipse.emf.ecore,
>>> org.eclipse.epsilon.emc.emf,
>>> org.eclipse.epsilon.emc.emf.virtual,
>>> org.eclipse.ui,
>>> org.eclipse.core.runtime,
>>> org.eclipse.epsilon.util.emf
>>>
>>> fixed:
>>>
>>> Require-Bundle: org.eclipse.core.runtime,
>>> org.eclipse.jface,
>>> org.eclipse.ui,
>>> org.eclipse.emf,
>>> org.eclipse.emf.ecore,
>>> org.eclipse.epsilon.commons,
>>> org.eclipse.epsilon.common.dt,
>>> org.eclipse.epsilon.emc.emf,
>>> org.eclipse.epsilon.emc.emf.virtual,
>>> org.eclipse.epsilon.util.emf
>>>
>>> 2) missing indirect dependencies
>>>
>>> e.g., org.eclipse.epsilon.antlr
>>>
>>> This threw me off initially. I think that we can reduce the number of
>>> indirect dependencies the plugins need once there the order of the
>>> bundles is consistent with the dependencies for all epsilon plugins.
>>>
>>> 3) missing feature dependencies
>>>
>>> the continuous build failed because epsilon.eugenia.feature is
>>> missing a dependency on epsilon.feature.
>>>
>>> see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260107
>>>
>>> -- Nicolas.
>>>
>>> -- Nicolas.
>>>
>>> Nicolas Rouquette wrote:
>>>> At JPL, I use a Bamboo continuous build server to build a toolkit
>>>> based on Ganymede SR1 with the UML2Tools components. So far so good.
>>>>
>>>> I checked out the full Epsilon enchilada from SVN because it
>>>> provides a really nice scripting mechanism I can use with UML2Tools
>>>> diagrams.
>>>> In my development workspace, I can launch a runtime environment with
>>>> epsilon plugins or with a product which includes the epsilon
>>>> features and everything works fine. Then, I tried to update my
>>>> Bamboo product configuration to build Epsilon. That's when I got an
>>>> endless string of compilation problems...
>>>>
>>>> 05-Jan-2009 20:43:49 [java] [mkdir] Created dir:
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>>
>>>> 05-Jan-2009 20:43:49 [java] [javac] Compiling 5 source
>>>> files to
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/temp.folder/@dot.bin
>>>>
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 1. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 21)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.common.dt.console.EpsilonConsole;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.common cannot be resolved
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 2. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 22)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.common.dt.util.EclipseUtil;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.common cannot be resolved
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 3. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 23)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.common.dt.util.LogUtil;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.common cannot be resolved
>>>> 05-Jan-2009 20:43:49 [java] [javac] ----------
>>>> 05-Jan-2009 20:43:49 [java] [javac] 4. ERROR in
>>>> /ramdisk/bamboo/TRUNK-MSTE/build/plugins/org.eclipse.epsilon .eugenia/src/org/eclipse/epsilon/eugenia/EolTransformationAc tionDelegate.java
>>>> (at line 24)
>>>> 05-Jan-2009 20:43:49 [java] [javac] import
>>>> org.eclipse.epsilon.commons.util.StringProperties;
>>>> 05-Jan-2009 20:43:49 [java] [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> 05-Jan-2009 20:43:49 [java] [javac] The import
>>>> org.eclipse.epsilon.commons cannot be resolved
>>>>
>>>> To get a better clue about what's going on, I switched the PDE
>>>> settings to full paranoia mode, i.e., flag errors on the slightest
>>>> whiff of anything suspicious. In my experience, this is a really
>>>> useful thing to do because it helps weed out problems that can mask
>>>> bigger problems later on.
>>>>
>>>> In this mode, I found that most Epsilon plugins fail to compile
>>>> because of the org.eclipse.epsilon.antlr plugin.
>>>>
>>>> Other plugins have out-of-order plugin dependencies in their
>>>> MANIFEST.MF files. I have fixed some of these but it's hard to do
>>>> this without some information about the Epsilon plugin architecture,
>>>> i.e., are there layers? e.g.:
>>>>
>>>> org.eclipse.epsilon.common.*
>>>> org.eclipse.epsilon.eol.*
>>>> org.eclipse.epsilon.????
>>>> org.eclipse.epsilon.????
>>>>
>>>> Layering the dependencies helps resolve compilation problems.
>>>>
>>>> I'm on a very tight schedule but I can help clean some of this.
>>>> It would be a shame to loose the Epsilon wizard capability for
>>>> unresolved compilation issues.
>>>>
>>>> Suggestions?
>>>>
>>>> -- Nicolas.
|
|
|
Goto Forum:
Current Time: Thu Apr 25 12:59:21 GMT 2024
Powered by FUDForum. Page generated in 0.04041 seconds |
] 
Search
Help
Register
Login
Home
