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

Bug 132073

Summary:	Filename length for plug-ins / new versioning scheme
Product:	[Eclipse Project] PDE	Reporter:	Sebastian Davids <sdavids>
Component:	Build	Assignee:	pde-build-inbox <pde-build-inbox>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P3	CC:	alexsani, jeffmcaffer, picard
Version:	3.2
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Sebastian Davids

2006-03-15 22:00:03 EST

Most platforms have max 255 characters for a filename.

Take this for example:

<parent>\eclipse\plugins\org.eclipse.rcp.source_3.2.0.v20060227-RI9KS6dRoJoH1GG\src\org.eclipse.jface.databinding_3.2.0.I20060307-0800

That's 127 characters just for the top-level plugin directory not counting the parent directory.

Let's say we unzip it on the desktop in German locale and you have:

C:\Dokumente und Einstellungen\<username>\Desktop

That's 40 more characters w/out the charactes of the user name.

One of Eclipse's charms has always been the ability to just unzip it anywhere on the filesystem and let it run.

This might be crippled by these excessively long filenames.

Comment 1 Sebastian Davids

2006-03-15 22:03:56 EST

bug 3046 might be affected as well

Comment 2 Sonia Dimitrov

2006-03-17 09:10:59 EST

Moving to PDE Build for comment.

Comment 3 Jeff McAffer

2006-04-03 23:11:46 EDT

In this particular case some of the version qualifier is generated which adds to bulk.  I'm also not sure why, for example the databinding plugin is qualified with what appears to be a build ID rather than a CVS tag but anyway, we are open to suggestions for how to work around this.

Iin the source plugin case there are clearly things that we can and should do.  for example, putting the source in jars would be one thing.  There is no real reason that the the whole source plugin could not be in one JAR.

Comment 4 Pascal Rapicault

2006-04-04 13:21:35 EDT

>There is no real reason that the the whole source plugin could not be in one JAR.
  If I remember properly, the reason was that pde could not support nested zips. 

Of course we could simply change the shape of source plug-ins to be jared and replace the src.zip by a folder which would contain the source code, but that would likely require more work than we want to do for 3.2.

Comment 5 Jeff McAffer

2006-04-04 15:14:36 EDT

definitely more than we want for 3.2.  

The issue is around source look up.  PDE should be able to serve up the source regardless of how it is packaged etc.

Comment 6 Kim Moir

2006-05-12 15:50:47 EDT

*** Bug 141433 has been marked as a duplicate of this bug. ***

Comment 7 Alain Picard

2006-11-26 13:31:13 EST

Just tried to unzip the new GMF-examples-2.0M3 into a standard:
"C:\eclipse\products\GMF-examples-2.0M3\"
and i get the same errors with instance such as:
C:\eclipse\products\GMF-examples-2.0M3\eclipse\plugins\org.eclipse.gmf.examples.source_1.0.0.v20061013-1330\src\org.eclipse.gmf.examples.runtime.diagram.logic.model.edit_1.0.1.v20061013-1330\icons\full\ctool16\CreateContainerElement_Element_WireConnectionPoint.gif
C:\eclipse\products\GMF-examples-2.0M3\eclipse\plugins\org.eclipse.gmf.examples.source_1.0.0.v20061013-1330\src\org.eclipse.gmf.examples.runtime.diagram.logic.model.edit_1.0.1.v20061013-1330\icons\full\ctool16\CreateContainerElement_children_InputOutputTerminal.gif
C:\eclipse\products\GMF-examples-2.0M3\eclipse\plugins\org.eclipse.gmf.examples.source_1.0.0.v20061013-1330\src\org.eclipse.gmf.examples.runtime.diagram.logic.model.edit_1.0.1.v20061013-1330\icons\full\ctool16\CreateContainerElement_children_WireConnectionPoint.gif

this is a real problem and it is very annoying. 

What is the suggested work-around?

Comment 8 Pascal Rapicault

2006-11-27 22:32:32 EST

Alain, did you get an error while unzipping?

Comment 9 Pascal Rapicault

2007-03-30 09:25:23 EDT


*** This bug has been marked as a duplicate of bug 175714 ***