Home » Eclipse Projects » Eclipse Platform » Plugin export generates "logs.zip", notifying errors in a error-free workbench
| Plugin export generates "logs.zip", notifying errors in a error-free workbench [message #324661] |
Wed, 30 January 2008 08:01  |
Eclipse User |
|
|
|
Hi,
i've been trying to export several projects as a deployable set of files
(Ed Willink's UMLX CVS sources), but always get errors on export. These
errors are typical java errors, as my java code was incorrect. They only
arise during export, and notified through a "logs.zip" file, containing
a .txt file per project.The curious thing is that there are no errors on
my workspace. However, if I launch the runtime workbench, the plugin works.
I think it might be something related with the JRE/JDK used, but I tried
to configure every single option on eclipse to work with 1.6, but it
keeps on. Reinstalling didn't work either.
I have JDK and JRE 1.6 installed and working with Eclipse 3.4M4. This
was happening as well with M3.
|
|
|
| Re: Plugin export generates "logs.zip", notifying errors in a error-free workbench [message #324663 is a reply to message #324661] |
Wed, 30 January 2008 08:14  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Víctor,
Without details I doubt anyone can answer this. Specifically what types
of errors are you getting?
Víctor Roldán Betancort wrote:
> Hi,
>
> i've been trying to export several projects as a deployable set of
> files (Ed Willink's UMLX CVS sources), but always get errors on
> export. These errors are typical java errors, as my java code was
> incorrect. They only arise during export, and notified through a
> "logs.zip" file, containing a .txt file per project.The curious thing
> is that there are no errors on my workspace. However, if I launch the
> runtime workbench, the plugin works.
>
> I think it might be something related with the JRE/JDK used, but I
> tried to configure every single option on eclipse to work with 1.6,
> but it keeps on. Reinstalling didn't work either.
>
> I have JDK and JRE 1.6 installed and working with Eclipse 3.4M4. This
> was happening as well with M3.
|
|
|
| Re: Plugin export generates "logs.zip", notifying errors in a error-free workbench [message #324664 is a reply to message #324663] |
Wed, 30 January 2008 08:41 |
| Eclipse User |
|
|
|
Excuse me, I didn't know whether showing these errors might be useful.
Most of them (if not all of them) related with "@override" tag. I also
checked the preferences -> java -> compiler -> errors/warnings, but its
like during export the compiler had its own preferences. Let me show you
a few (note none of these errors do actually exist in the workspace):
************************************************************ ************************************
# 30/01/08 13:31:23 GMT
# Eclipse Java Compiler 0.829, pre-3.4.0 milestone-4, Copyright IBM Corp
2000, 2007. All rights reserved.
----------
1. ERROR in C:\victor\Mis documentos\workspace
M4\org.eclipse.gmt.umlx.common\src\org\eclipse\gmt\umlx\alie n\mapping\MappingMetaData.java
(at line 42)
public int compare(IMappingMetaData o1, IMappingMetaData o2) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The method compare(IMappingMetaData, IMappingMetaData) of type
MappingMetaData.ImportComparator must override a superclass method
----------
2. ERROR in C:\victor\Mis documentos\workspace
M4\org.eclipse.gmt.umlx.common\src\org\eclipse\gmt\umlx\alie n\mapping\MappingMetaData.java
(at line 90)
public IMappingMetaDataRegistry createMappingMetaDataRegistry(EPackage
rootEPackage, AlienXMIResourceAdapterFactory resourceAdapterFactory) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The method createMappingMetaDataRegistry(EPackage,
AlienXMIResourceAdapterFactory) of type MappingMetaData.RegistryFactory
must override a superclass method
----------
2 problems (2 errors)
************************************************************ ************************************
Hope this is more illustrative.
Ed Merks escribió:
> Víctor,
>
> Without details I doubt anyone can answer this. Specifically what types
> of errors are you getting?
>
>
> Víctor Roldán Betancort wrote:
>> Hi,
>>
>> i've been trying to export several projects as a deployable set of
>> files (Ed Willink's UMLX CVS sources), but always get errors on
>> export. These errors are typical java errors, as my java code was
>> incorrect. They only arise during export, and notified through a
>> "logs.zip" file, containing a .txt file per project.The curious thing
>> is that there are no errors on my workspace. However, if I launch the
>> runtime workbench, the plugin works.
>>
>> I think it might be something related with the JRE/JDK used, but I
>> tried to configure every single option on eclipse to work with 1.6,
>> but it keeps on. Reinstalling didn't work either.
>>
>> I have JDK and JRE 1.6 installed and working with Eclipse 3.4M4. This
>> was happening as well with M3.
|
|
|
| Re: Plugin export generates "logs.zip", notifying errors in a error-free workbench [message #324670 is a reply to message #324664] |
Wed, 30 January 2008 10:09 |
| Eclipse User |
|
|
|
Originally posted by: dmsubs.NOSPAM.consertum.com
This look like a compiler conformance-level problem. Is conformance set to 1.4?
--
Derek
Víctor Roldán Betancort wrote:
> Excuse me, I didn't know whether showing these errors might be useful.
> Most of them (if not all of them) related with "@override" tag. I also
> checked the preferences -> java -> compiler -> errors/warnings, but its
> like during export the compiler had its own preferences. Let me show you
> a few (note none of these errors do actually exist in the workspace):
>
> ************************************************************ ************************************
>
> # 30/01/08 13:31:23 GMT
> # Eclipse Java Compiler 0.829, pre-3.4.0 milestone-4, Copyright IBM Corp
> 2000, 2007. All rights reserved.
> ----------
> 1. ERROR in C:\victor\Mis documentos\workspace
> M4\org.eclipse.gmt.umlx.common\src\org\eclipse\gmt\umlx\alie n\mapping\MappingMetaData.java
> (at line 42)
> public int compare(IMappingMetaData o1, IMappingMetaData o2) {
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The method compare(IMappingMetaData, IMappingMetaData) of type
> MappingMetaData.ImportComparator must override a superclass method
> ----------
> 2. ERROR in C:\victor\Mis documentos\workspace
> M4\org.eclipse.gmt.umlx.common\src\org\eclipse\gmt\umlx\alie n\mapping\MappingMetaData.java
> (at line 90)
> public IMappingMetaDataRegistry
> createMappingMetaDataRegistry(EPackage rootEPackage,
> AlienXMIResourceAdapterFactory resourceAdapterFactory) {
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> The method createMappingMetaDataRegistry(EPackage,
> AlienXMIResourceAdapterFactory) of type MappingMetaData.RegistryFactory
> must override a superclass method
> ----------
> 2 problems (2 errors)
> ************************************************************ ************************************
>
>
> Hope this is more illustrative.
>
> Ed Merks escribió:
>> Víctor,
>>
>> Without details I doubt anyone can answer this. Specifically what
>> types of errors are you getting?
>>
>>
>> Víctor Roldán Betancort wrote:
>>> Hi,
>>>
>>> i've been trying to export several projects as a deployable set of
>>> files (Ed Willink's UMLX CVS sources), but always get errors on
>>> export. These errors are typical java errors, as my java code was
>>> incorrect. They only arise during export, and notified through a
>>> "logs.zip" file, containing a .txt file per project.The curious thing
>>> is that there are no errors on my workspace. However, if I launch the
>>> runtime workbench, the plugin works.
>>>
>>> I think it might be something related with the JRE/JDK used, but I
>>> tried to configure every single option on eclipse to work with 1.6,
>>> but it keeps on. Reinstalling didn't work either.
>>>
>>> I have JDK and JRE 1.6 installed and working with Eclipse 3.4M4. This
>>> was happening as well with M3.
|
|
| | | | | |
| Re: Plugin export generates "logs.zip", notifying errors in a error-free workbench [message #324678 is a reply to message #324676] |
Wed, 30 January 2008 11:14 |
| Eclipse User |
|
|
|
It does only need 6.0 due to @override tags (probably). You are right,
but it's not my code...
Ed Merks escribió:
> Víctor,
>
> If you need Java 5.0 or 6.0 you should really specify that. It does
> mean minimum... Does the code really depend on 6.0? That doesn't seem
> like such a good idea...
>
>
> Víctor Roldán Betancort wrote:
>> Yeah, it seems the manifest declared using 1.5. So when I executed
>> "update classpath", many errors appeared. Maybe changing that value?
>>
>> I thought that "minimum required execution environment" meant
>> "minimum", and not "exact". Once I set manifest to Java 1.6, "update
>> classpath" does not introduce any error. Lets see if this way I can
>> export without
>> error. Is it ok if I leave that value empty?
>>
>>
>> Ed Merks escribió:
>>> Víctor,
>>>
>>> Is this properly specified via the MANIFEST.MF's execution
>>> environment? (If you do PDE Tools->Update classpath on the project
>>> does that mess things up?)
>>>
>>>
>>> Víctor Roldán Betancort wrote:
>>>> I've it set to 6.0, which is what the author is actually using.
>>>>
>>>> Derek Morris escribió:
>>>>> This look like a compiler conformance-level problem. Is conformance
>>>>> set to 1.4?
|
|
|
| Re: Plugin export generates "logs.zip", notifying errors in a error-free workbench [message #324684 is a reply to message #324677] |
Wed, 30 January 2008 12:15 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Víctor,
I would suggest having a chat with Ed W about the 6.0 dependency. Most
things in Eclipse require minimally 1.4 and in fact EMF was the first
thing to start placing a hard requirements on 5.0, so requiring 6.0
merely for the convenience of using @Override for overriding interface
methods is probably not a good idea...
Víctor Roldán Betancort wrote:
> Ed,
>
> after modifying every single manifest.mf, it worked, I successfully
> exported without any error. Thank you very much, I had several
> headaches with this issue.
>
> Ed Merks escribió:
>> Víctor,
>>
>> Is this properly specified via the MANIFEST.MF's execution
>> environment? (If you do PDE Tools->Update classpath on the project
>> does that mess things up?)
>>
>>
>> Víctor Roldán Betancort wrote:
>>> I've it set to 6.0, which is what the author is actually using.
>>>
>>> Derek Morris escribió:
>>>> This look like a compiler conformance-level problem. Is conformance
>>>> set to 1.4?
|
|
|
| Re: Plugin export generates "logs.zip", notifying errors in a error-free workbench [message #324718 is a reply to message #324684] |
Thu, 31 January 2008 03:05 |
| Eclipse User |
|
|
|
Ed,
thank you for your suggestion, I totally agree with you. It's a very
strange situation. These sources are configured to use 1.5
(manifest.mf), including workspace configuration. But the sources
include these "@override" tags only introduced by java 1.6. I guess Ed W
made a transition to java 1.6 during development of UMLX, thats why some
classes have the @override tag and some others don't.
I think it's just a matter of removing them and setting the whole
project to 1.5. I'll try to have a chat with him and explain the situation.
Ed Merks escribió:
> Víctor,
>
> I would suggest having a chat with Ed W about the 6.0 dependency. Most
> things in Eclipse require minimally 1.4 and in fact EMF was the first
> thing to start placing a hard requirements on 5.0, so requiring 6.0
> merely for the convenience of using @Override for overriding interface
> methods is probably not a good idea...
>
>
> Víctor Roldán Betancort wrote:
>> Ed,
>>
>> after modifying every single manifest.mf, it worked, I successfully
>> exported without any error. Thank you very much, I had several
>> headaches with this issue.
>>
>> Ed Merks escribió:
>>> Víctor,
>>>
>>> Is this properly specified via the MANIFEST.MF's execution
>>> environment? (If you do PDE Tools->Update classpath on the project
>>> does that mess things up?)
>>>
>>>
>>> Víctor Roldán Betancort wrote:
>>>> I've it set to 6.0, which is what the author is actually using.
>>>>
>>>> Derek Morris escribió:
>>>>> This look like a compiler conformance-level problem. Is conformance
>>>>> set to 1.4?
|
|
|
| Re: Plugin export generates "logs.zip", notifying errors in a error-free workbench [message #324725 is a reply to message #324718] |
Thu, 31 January 2008 05:43 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Víctor,
To me its kind of a nasty and general problem that many of the Java
settings can be controlled indirectly via the MANIFEST.MF and also
directly via properties on the project. This allows folks to specify
things inconsistently and in the past has led to the commonly recurring
problem that folks fix their build path and then find they can't run
their plugin for precisely the reason that the build path needs to be
specified via the MANIFEST.MF's dependencies in order to fix both the
build and the runtime problem at once. It seems to me Chris did
something to warn about this for Eclipse 3.4, but this inconsistent
execution environment is another flavor; I know the recently fixed a
bug where changing the MANIFEST.MF execution environment doesn't
automatically update the project's corresponding settings...
Víctor Roldán Betancort wrote:
> Ed,
>
> thank you for your suggestion, I totally agree with you. It's a very
> strange situation. These sources are configured to use 1.5
> (manifest.mf), including workspace configuration. But the sources
> include these "@override" tags only introduced by java 1.6. I guess Ed
> W made a transition to java 1.6 during development of UMLX, thats why
> some classes have the @override tag and some others don't.
>
> I think it's just a matter of removing them and setting the whole
> project to 1.5. I'll try to have a chat with him and explain the
> situation.
>
> Ed Merks escribió:
>> Víctor,
>>
>> I would suggest having a chat with Ed W about the 6.0 dependency.
>> Most things in Eclipse require minimally 1.4 and in fact EMF was the
>> first thing to start placing a hard requirements on 5.0, so requiring
>> 6.0 merely for the convenience of using @Override for overriding
>> interface methods is probably not a good idea...
>>
>>
>> Víctor Roldán Betancort wrote:
>>> Ed,
>>>
>>> after modifying every single manifest.mf, it worked, I
>>> successfully exported without any error. Thank you very much, I had
>>> several headaches with this issue.
>>>
>>> Ed Merks escribió:
>>>> Víctor,
>>>>
>>>> Is this properly specified via the MANIFEST.MF's execution
>>>> environment? (If you do PDE Tools->Update classpath on the
>>>> project does that mess things up?)
>>>>
>>>>
>>>> Víctor Roldán Betancort wrote:
>>>>> I've it set to 6.0, which is what the author is actually using.
>>>>>
>>>>> Derek Morris escribió:
>>>>>> This look like a compiler conformance-level problem. Is
>>>>>> conformance set to 1.4?
|
|
|
| Re: Plugin export generates "logs.zip", notifying errors in a error-free workbench [message #324726 is a reply to message #324725] |
Thu, 31 January 2008 06:04 |
| Eclipse User |
|
|
|
Ed,
as you say, this issue leads to common inconsistencies, as happened to
me. I've finally fixed the projects, by first changing minimum execution
environment variable in manifest.mf (set to 1.5) and then executing PDE
Tools -> update classpath, which changed not only user libraries, but
also project settings, setting compiler compliance level to 1.5. This
last procedure seems to be the shortest (also maybe the safest?) way to
have an uniform compliance level in a project.
I'm using 3.4M4, and when I modified MANIFEST.MF, project settings
didn't change. I hope the fix would automatically synchronize these
settings.
Then the only remaining thing was, one by one, taking out each erroneous
"@override" tag. Exporting the plugins is no longer a problem.
Ed Merks escribió:
> Víctor,
>
> To me its kind of a nasty and general problem that many of the Java
> settings can be controlled indirectly via the MANIFEST.MF and also
> directly via properties on the project. This allows folks to specify
> things inconsistently and in the past has led to the commonly recurring
> problem that folks fix their build path and then find they can't run
> their plugin for precisely the reason that the build path needs to be
> specified via the MANIFEST.MF's dependencies in order to fix both the
> build and the runtime problem at once. It seems to me Chris did
> something to warn about this for Eclipse 3.4, but this inconsistent
> execution environment is another flavor; I know the recently fixed a
> bug where changing the MANIFEST.MF execution environment doesn't
> automatically update the project's corresponding settings...
>
>
> Víctor Roldán Betancort wrote:
>> Ed,
>>
>> thank you for your suggestion, I totally agree with you. It's a very
>> strange situation. These sources are configured to use 1.5
>> (manifest.mf), including workspace configuration. But the sources
>> include these "@override" tags only introduced by java 1.6. I guess Ed
>> W made a transition to java 1.6 during development of UMLX, thats why
>> some classes have the @override tag and some others don't.
>>
>> I think it's just a matter of removing them and setting the whole
>> project to 1.5. I'll try to have a chat with him and explain the
>> situation.
>>
>> Ed Merks escribió:
>>> Víctor,
>>>
>>> I would suggest having a chat with Ed W about the 6.0 dependency.
>>> Most things in Eclipse require minimally 1.4 and in fact EMF was the
>>> first thing to start placing a hard requirements on 5.0, so requiring
>>> 6.0 merely for the convenience of using @Override for overriding
>>> interface methods is probably not a good idea...
>>>
>>>
>>> Víctor Roldán Betancort wrote:
>>>> Ed,
>>>>
>>>> after modifying every single manifest.mf, it worked, I
>>>> successfully exported without any error. Thank you very much, I had
>>>> several headaches with this issue.
>>>>
>>>> Ed Merks escribió:
>>>>> Víctor,
>>>>>
>>>>> Is this properly specified via the MANIFEST.MF's execution
>>>>> environment? (If you do PDE Tools->Update classpath on the
>>>>> project does that mess things up?)
>>>>>
>>>>>
>>>>> Víctor Roldán Betancort wrote:
>>>>>> I've it set to 6.0, which is what the author is actually using.
>>>>>>
>>>>>> Derek Morris escribió:
>>>>>>> This look like a compiler conformance-level problem. Is
>>>>>>> conformance set to 1.4?
|
|
|
Goto Forum:
Current Time: Thu Jul 17 23:18:48 EDT 2025
Powered by FUDForum. Page generated in 0.31362 seconds |
Home