Comment 1 Philipe Mulet 2004-07-08 11:10:40 EDT

The missing file is: 
InlineConstantRefactoring$InlineTargetCompilationUnit$InitializerExpressionRelo
cationPreparer$InitializerTraversal

and is defined in JDT/UI plugin.

Comment 2 Wassim Melhem 2004-07-08 11:32:53 EDT

When you build cheetah using the site builder, are you are building the JAR 
for jdt/core, or are you also building the JAR for jdt/ui?

Comment 3 Philipe Mulet 2004-07-08 11:34:00 EDT

I am building jdt/core, jdt/ui & jdt/debug.

Comment 4 Philipe Mulet 2004-07-08 11:34:35 EDT

It looks like it is missing a member type at depth 4 (its enclosing type are 
included in the JAR).

Comment 5 Wassim Melhem 2004-07-08 11:38:02 EDT

Moving to PDE-Build.

Comment 6 Wassim Melhem 2004-07-08 11:42:27 EDT

One possibility might be that the 256char-limit was exceeded, and therefore 
this inner class at depth4 had such a long name that it could not be generated.

What is the full location of your workspace?

Comment 7 Philipe Mulet 2004-07-08 12:14:03 EDT

Class file location is:

D:\eclipse\workspaces\dev3.1
\plugins\org.eclipse.jdt.ui\bin\org\eclipse\jdt\internal\corext\refactoring\cod
e\InlineConstantRefactoring$InlineTargetCompilationUnit$InitializerExpressionRe
locationPreparer$InitializerTraversal.class

Comment 8 Wassim Melhem 2004-07-08 12:32:17 EDT

Given that Philippe's workspace is at D:\Eclipse\workspaces\dev3.1\plugins,
when the JAR is built outside the workspace, the class file for this inner 
class will be written to the path below, which exceeds 256 chars, and hence it 
fails to be written there and is not included in the JAR.

D:\eclipse\workspaces\dev3.1
\plugins\.metadata\.plugins\org.eclipse.pde.ui\temp\destination\plugins\org.ecl
ipse.jdt.ui\org\eclipse\jdt\internal\corext\refactoring\cod
e\InlineConstantRefactoring$InlineTargetCompilationUnit$InitializerExpressionRe
locationPreparer$InitializerTraversal.class

Comment 9 Philipe Mulet 2004-07-08 13:04:01 EDT

Just curious: why are you rebuilding from scratch, instead of simply building 
an archive out of the output folder contents ?

Comment 10 Pascal Rapicault 2004-07-08 15:46:25 EDT

Because pde build totally ignores the notion of workspace, project, classpath 
etc. so it can build things out of a workspace (for example for the releng 
style build). 
This design choice seems to have been made back in the first version of pde.

Comment 11 Wassim Melhem 2004-08-30 22:35:05 EDT

Pascal, this one certainly deserves a readme for 3.0.1

Comment 12 Pascal Rapicault 2004-08-31 10:01:50 EDT

You are right since this can not be adressed without completly rewriting PDE 
build.

Comment 13 Pascal Rapicault 2004-08-31 14:07:30 EDT

Text for the readme:

PDE: 

Missing classes with long class names

When exporting plugins containing long class name (or deeply nested classes),
the resulting jar may not have those classes. This is due to the limitation of
file name length in the OS.

Comment 14 Pascal Rapicault 2004-08-31 14:37:15 EDT

Reviewed version of the text:


Missing classes from exported plug-ins

On some platforms due to limitations of the length of filenames,  the JARs
generated by the "File > Export.. > Deployable plug-ins and fragments"  function
may be missing class files.
This may happen if the workspace path, package names, or class names are too
long (see bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=69620).

Comment 15 Jim des Rivieres 2004-08-31 14:48:50 EDT

Added entry to 3.0.1 release notes.

Comment 16 Philipe Mulet 2004-09-01 03:39:02 EDT

One comment on the readme entry is that it reads like a user issue (due to OS 
limitation) as opposed to an issue in PDE itself, which it is actually. The 
problem is that PDE is using a temp folder which is fairly deeply nested, and 
thus, when combined with deep package structure, it reaches the OS limit. Not 
being able to deploy Eclipse with Eclipse is quite severe.

Comment 17 Jeff McAffer 2004-09-07 16:38:25 EDT

should this be closed now? or at least changed from 3.0.1?

Comment 18 Pascal Rapicault 2004-09-07 16:53:50 EDT

From a pde build point of view nothing else can be done now.

Comment 19 Wassim Melhem 2004-09-07 17:37:54 EDT

Pascal, I'm not sure this bug can be resolved as fixed because it is clearly 
not.
However, to solve this problem, you need to rewrite pde-build, so a better 
resolution might be as LATER.

Comment 20 Philipe Mulet 2004-09-08 03:40:30 EDT

I would also not consider this one as fixed since you did not fix anything, 
the problem is still here. At best, you could say wontfix, but clearly it 
prevents self-hosting so this is a mustfix at some point.

Comment 21 Pascal Rapicault 2004-09-08 08:50:52 EDT

The problem does not prevent self hosting but prevents plugin export.

Marking as fixed, wontfix or later is a question of point of view.
I marked as fixed because the only (unfortunate) solution for 3.0.1 that could 
be thought of has been implemented. Therefore regarding 3.0.1 it is fixed.

The fundamental problems which were known since 2.0 (by the previous owners of 
pde) but were not as striking as today are being considered. I'm writing an RFP 
capturing all the problems and a solution.

All that to say that a new bug should be open to capture all the issue.

Note that a short-term solution would be for PDE UI to propose to the users to 
pick a location were the export could happen.

Comment 22 Wassim Melhem 2006-01-08 23:36:48 EST

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

Comment 23 jernej srebrnic 2006-01-09 03:14:53 EST

upgraded from 1.5_03 to 1.5_06 and exports started warking ...
so  case in bug #122620 now works...
no workspace change, no refactor just new JDK (did not try jre)

Comment 24 David Williams 2006-01-09 15:35:27 EST

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

Comment 25 David Williams 2006-01-09 15:45:51 EST

I am reopening for a couple reasons. 

1. I don't see any mention of this in the readme file or help (using 3.1.1). 

2. I'm pretty sure there is no file name limit on windows xp (can't find any mention of that). There might be some related to the version and provider of the JRE, especially given comment #23.

3. Even if no fix is possible, seems that a warning/error could be devised so the build would not complete normally and let the user waste hours (or more) hunting down some odd bug. 

4. In a similar context (javadoc related), I've found some mention that there is "command length limit" on windows of 1000 characters (but *nix is typically 10000). Could this be the problem here? If so, a suggested work around at 
http://java.sun.com/j2se/javadoc/faq/
was to put the commands in a file, and then spec the command file on the command itself. If at all related, could such a trick be used here in this context? 

Comment 26 David Williams 2006-01-23 00:14:21 EST

(In reply to comment #25)
 
> I'm pretty sure there is no file name limit on windows xp (can't find any
> mention of that).

Ok, I take it back. The rumors are true, sort of. I've found the "designed for windows xp" spec 
is very explicit about file name lengths: 
in 
http://www.microsoft.com/winlogo/software/SWglossary.mspx
MAX_FILE A manifest constant defined in the windows.h include file. The current value assigned to MAX_FILE is 255.

MAX_PATH A manifest constant defined in the windows.h include file. The current value assigned to MAX_PATH is 260.

The hard part of the problem seems to be that you can "drill down" directory by directory, and end up making paths who's total length is way over 260. 
But, else where, 
http://download.microsoft.com/download/9/d/0/9d0c9c38-6560-442e-92ee-37e3a29b9873/XPx64LogoTestFramework_v2-0-0.doc
they are explicit that "while the application does not need to support max_path and max_file, there can be no loss of data" .. and they explicitly give some "drill down" tests ... so, I think it still a valid bug that no error is reported when the file is "lost" during the build or package process. 
[And, as far as I'm concerned, you could drill down all you want is that led to success :) 

Comment 27 Philipe Mulet 2006-01-23 03:44:44 EST

Re: comment 21.

This problem prevents full self-hosting experience, where developers are expected to patch their IDE with their ongoing developments, and assess its quality. This part is broken, and we have to use our own Ant scripts, and not use plugin export which is not working.

Re: fixed/later/wontfix argument - I disagree. Adding an entry in a readme is by no mean a proper fix. A fix would mean that the original problem is no longer happening. Is that the case ? I believe no. 

Comment 28 Powell Quiring 2006-01-23 09:47:40 EST

Can a failure message be generated that includes an explination of how to work around the problem?

Comment 29 Pascal Rapicault 2006-02-14 14:41:27 EST

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

Comment 30 Michael Long 2006-02-14 15:35:37 EST

(In reply to comment #29)
> *** Bug 127825 has been marked as a duplicate of this bug. ***

Just a note on the difference between 127825 and this bug.   In 127825, inner classes are not an issue.  Also, the filename is much shorter than 256 characters.   The package structure + filename only equals 106 characters.   The maximum length drops to less than 75 characters on RCP exports to archives.

Comment 31 Wassim Melhem 2006-03-31 17:05:59 EST

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

Comment 32 Ted Bashor 2006-04-27 15:32:41 EDT

Another vote for this bug... I wasted several hours trying to figure out why my plugins exported from 3.1.2 were missing class files.  Moving to 1.5_06 fixed the problem.

Comment 33 Pascal Rapicault 2006-05-04 14:00:59 EDT

Still haven't find a way around that. sorry not for 3.2.

Comment 34 Pascal Rapicault 2006-05-04 14:27:06 EDT

I thought I had put some details in this bug but I can't find them anymore. So here they are:
The core of the problem is that when class files are not being copied, PDE build or PDE UI are not in control. The copy of the class files is done by Ant copy tasks, and it is there that it shokes. I'm not even sure if a message is being given by Ant. If Ant gives a warning, then it might be possible to write an ant listener to watch for the output of the build and report an error is something wrong is going on, but this is tricky business that would have to be put in pde ui, and it is too late.

Comment 35 Wassim Melhem 2006-05-04 14:30:34 EDT

Pascal, pde/ui already has an ant listener.  That is how we know/report when compiler errors occur.

I therefore suspect that Ant is not complaining about the missing inner classes at all.  Otherwise, we would have been notified.

Comment 36 Pascal Rapicault 2006-05-04 14:43:22 EDT

Do you listen for warnings?

Comment 37 Wassim Melhem 2006-05-04 14:49:00 EDT

No, only to errors.  

I think at some point, we listened to warnings as well but there were too many of them and they were all insignificant to the export process.

Comment 38 David Williams 2006-05-04 16:17:42 EDT

If this is thought to be "just an ant limitation" ... what's the theory for why moving to 1.5_06 fixes the problem? 

And, I'm not saying it is not related to ant ... or even cygwin used to have similar issues ... but .. just wondering if "the fix" in 1.5_06 was worth investigating?

Comment 39 Pascal Rapicault 2006-05-04 16:25:47 EDT

Ok, could anyone who had the problem attach a simple project and the exact path of their workspace on their disk so that I can investigate a bit more?

Comment 40 Philipe Mulet 2006-05-04 16:48:22 EDT

My original post was exporting JDT/UI plugin from 3.0 branch, workspace location was likely: "d:/eclipse/workspaces/dev3.0/plugins/".

Comment 41 Michael Long 2006-05-04 17:02:21 EDT

Created attachment 40431 [details]
A sample project exported to file system then zipped

This is a plug-in project created to demonstrate this bug.  In this zipped archive, the project was exported using the "File System" destination.   The resulting folder was then zipped.    ** All files are present in this archive. **

Comment 42 Michael Long 2006-05-04 17:08:16 EDT

Created attachment 40434 [details]
Same project, exported as plug-in to archive

This is the same project as "A sample project exported to file system then zipped" , however, this time exported as a deployable plug-in to an archive zip.   **The interface that was present in the file system export is no longer present in the plugin jar.**    This workspace was located at:   c:\Documents and Settings\mllong1\client-workspace\

Comment 43 Pascal Rapicault 2006-05-04 17:10:36 EDT

Thanks a lot, I will take a look yet another time.

Comment 44 Todd E. Williams 2006-05-09 17:29:06 EDT

Pascal,
Thank you from the referral from Bug #140907.  I agree with you that this bug is precisely what we're seeing.  In fact, I have an easy test case for you to run to confirm the issue.  Here's the scenario:

1) Load org.eclipse.wst.sse.ui (and prereq's I suppose) from CVS
2) Export the plugin to an archive using the PDE
3) Note that the following class is not included:
org.eclipse.wst.sse.ui.internal.contentoutline.ConfigurableContentOutlinePage$SelectionProvider$PostSelectionChangedListener

Since I've seen conversations about workspace location, this fails for me with a workspace located at "C:\dev\workspaces\5RC2D".  I don't know that this is the only file that is not included, but it's representative.  Additionally, I counted the length of the fully-qualified classname and it's 125 characters so if there is a 255 character limit on the path then the PDE would have to be using some very long temp directory paths to go over that.

Thanks in advance for looking into this again.  It's truly an important issue to find a solution to from our perspective since it prevents WTP from being built from the PDE.

Comment 45 Todd E. Williams 2006-05-09 18:47:01 EDT

One thought on this... the limitation might not be the length of the file name but rather the length of a command that windows can take in a shell from the Ant process.  Just a thought.

Comment 46 Kai-Uwe Maetzel 2006-05-09 19:06:05 EDT

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

Comment 47 Todd E. Williams 2006-05-09 19:54:30 EDT

Re: Comment #45: The maximum command line length in Windows XP is 8K, according to Microsoft here: http://support.microsoft.com/default.aspx?scid=kb;en-us;830473
So, my speculation that this might be the issue seems unfounded.

Comment 48 Pascal Rapicault 2006-05-09 21:28:06 EDT

Thanks to the test case by Michael and a deep investigation through layers of crap. I came to the conclusion that the problem is coming from Java, which is able to list the content of a folder that contains long filenames but can not create the corresponding file object.

Here is a snippet of code that will exhibit the problem if you create a file with a very long name in the folder specified in the first line of code.

 File f = new File("C:/Documents and Settings/mlllong1/client-workspace/.metadata/.plugins/org.eclipse.pde.core/temp/destination/plugins/com.test.for.eclpse.bug.per.request/@dot/com/test/forplugin/eclpse/bug/per/request/model/object/facade");
 String[] files = f.list();
 System.out.println(f.isDirectory());
 for (int i = 0; i < files.length; i++) {
  System.out.println(files[i]);
  System.out.println(new File(f, files[i]).exists());
 }

I'm looking in providing a patch to the apache ant team to at least report a warning when something like that happens.

Comment 49 Todd E. Williams 2006-05-10 18:34:54 EDT

I've got a bit more information that hopefully will allow others to work around this issue. We've noticed that the export performs differently depending on whether the target is an archive or a directory. We initially encountered the issues recounted here when exporting to an archive.  However, we've since noticed that if we export to a directory instead, that the classes that were not present in the archive export are now included.  Exporting to a directory instead of an archive seems to work as a reliable workaround for us and was tested with Eclipse 3.2RC2 and JDK's 1.4.2_08 and 1.4.2_11.

One other piece of information that might be related is this bug in the JDK (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182812) titled "FileOutputStream constructor throws FileNotFoundException with long file names"

Comment 50 Kai-Uwe Maetzel 2006-05-10 20:24:19 EDT

(In reply to comment #49)
> Exporting to a directory
> instead of an archive seems to work as a reliable workaround for us and was
> tested with Eclipse 3.2RC2 and JDK's 1.4.2_08 and 1.4.2_11.

I tried the same. For me it didn't make a difference whether I exported to a archive or directory. In both cases the inner classes were not included.

Comment 51 Pascal Rapicault 2006-05-10 21:08:10 EDT

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

Comment 52 Todd E. Williams 2006-06-22 15:09:05 EDT

We ran across this issue again today and found a definitive solution.  This "long path" issue is definately caused by the JDK bug I referenced in comment #49.  The solution is simply to launch Eclipse with the latest 1.5 JDK, which fixed the bug.  The default JRE in the workspace can still be whatever you'd like as it has no impact on this particular part of the export process.  

I hope providing a workaround gives this a little closure and helps everyone out a bit.

Comment 53 Wassim Melhem 2006-06-22 20:13:35 EDT

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

Comment 54 Pascal Rapicault 2006-06-27 11:43:01 EDT

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

Comment 55 Jean-Michel Lemieux 2006-07-31 10:32:19 EDT

Confirmed that switching from 1.4 to 1.5.0_07 fixed the problem for me as well. 

Comment 56 Andrew Niefer 2006-08-01 10:52:49 EDT

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

Comment 57 Andrew Niefer 2007-03-29 18:57:17 EDT

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

Comment 58 Pascal Rapicault 2007-03-30 09:49:39 EDT

Now that 1.5 is the norm and that 1.5 fixes the problem. I will close as wontfix.

Comment 59 Andrew Niefer 2007-09-05 17:52:24 EDT

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