Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 274276

Summary:	WorkflowRunner - Fetching bundle version from MANIFEST.MF
Product:	[Modeling] EMFT	Reporter:	Dennis Huebner <dennis.huebner>
Component:	MWE	Assignee:	Karsten Thoms <karsten.thoms>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	minor
Priority:	P3	CC:	karsten.thoms, sven.efftinge
Version:	0.7
Target Milestone:	M2
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:
Bug Depends on:
Bug Blocks:	274171

Description Dennis Huebner

2009-04-29 06:50:44 EDT

The way how the Bundle version is fetched by WorkflowRunner is wrong.
We should investigate and correct this.
See org.eclipse.emf.mwe.core.WorkflowRunner.getVersion()

Comment 1 Patrick Schonbach

2009-05-22 11:05:27 EDT

I could have a look at it. However, it would be helpful, if you could specify exactly what is wrong with the current code. This would avoid a lot of guesswork about what you might have meant. :)

Comment 2 Dennis Huebner

2009-06-08 04:06:36 EDT

(In reply to comment #1)
> I could have a look at it. However, it would be helpful, if you could specify
> exactly what is wrong with the current code. This would avoid a lot of
> guesswork about what you might have meant. :)
> 

ResourceLoaderFactory.createResourceLoader().getResource(
					"META-INF/MANIFEST.MF").openStream()
Uses classloader, means it will load some of existing META-INF/MANIFEST.MF's in the classpath. ClassLoader can be also replaced using API, that will provide wrong information.

I think using the "real" ClassLoader => something like this.getClass().getResource("META-INF/MANIFEST.MF").openStream()
will be a better solution.

Comment 3 Patrick Schonbach

2009-06-12 06:58:55 EDT

Unfortunately, your proposed solution does not work. The "real" ClassLoader is not able to load "META-INF/MANIFEST.MF", because this directory is not on the classpath.

Comment 4 Karsten Thoms

2009-08-21 08:25:34 EDT

After talking with Dennis it came up that this could be only an issue when running in a non-Eclipse environment when multiple mwe.core jars are on the classpath. In this case it cannot be decided which is the right one and the first will be taken for fetching the serial number.

Alternative: Could the build version inserted to a constant in WorkflowRunner and replaced during the build?

Comment 5 Dennis Huebner

2009-08-21 08:46:34 EDT

(In reply to comment #4)
> After talking with Dennis it came up that this could be only an issue when
> running in a non-Eclipse environment when multiple mwe.core jars are on the
> classpath. In this case it cannot be decided which is the right one and the
> first will be taken for fetching the serial number.
> 
> Alternative: Could the build version inserted to a constant in WorkflowRunner
> and replaced during the build?
> 

Deeper investigation shows that mwe uses org.eclipse.emf.common.util.DelegatingResourceLocator to load resources. That means one will ever get the right MANIFEST.MF calling getResource(). There is even no need to check that the bundle name matches. ;)

Closing.

Comment 6 Sven Efftinge

2009-08-21 09:11:28 EDT

I've refactored the code, so that it is more explicit how it works.

Comment 7 Karsten Thoms

2009-08-21 09:37:47 EDT

Reduced the log level to warning when version cannot be fetched. Error is too strict.