| Cannot nest source folder inside library [message #257889] |
Wed, 31 December 2008 11:10  |
Eclipse User |
|
|
|
Originally posted by: Klaus.Wenger.Borland.com
Hello JDT community,
I read that 3.5M4 can handle nested source folders now given the right
exclude patterns.
When migrating our existing codebase that compiles perfectly well in 3.4.x
and has no nested source folders, I get the strangest of errors:
Cannot nest 'com.borland.star team.guy/src inside library 'com.borland.star
team.gui'
The .classpath file looks as following:
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry exported="true" kind="lib" path="sequoia.jar"/>
<classpathentry exported="true" kind="lib"
path="starteam-gui-resources.jar"/>
<classpathentry exported="true" kind="lib" path="starteam-gui.jar"/>
<classpathentry exported="true" kind="lib"
path="annotation-resources.jar"/>
<classpathentry exported="true" kind="lib" path="annotation.jar"/>
<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="src" path="src"/>
<classpathentry kind="src" path="src.geotools"/>
<classpathentry kind="src" path="src.garuda"/>
<classpathentry kind="src" path="src.res.ui"/>
<classpathentry kind="src" path="src.res.core"/>
<classpathentry kind="src" path="src.bluecove"/>
<classpathentry kind="output" path="bin"/>
</classpath>
Many thanks for giving this a glance,
k
|
|
|
| Re: Cannot nest source folder inside library [message #257894 is a reply to message #257889] |
Thu, 01 January 2009 17:26  |
| Eclipse User |
|
|
|
"Klaus Wenger" <Klaus.Wenger@Borland.com> wrote in message
news:gjgc4d$73r$1@build.eclipse.org...
> Hello JDT community,
>
> I read that 3.5M4 can handle nested source folders now given the right
> exclude patterns.
> When migrating our existing codebase that compiles perfectly well in 3.4.x
> and has no nested source folders, I get the strangest of errors:
>
> Cannot nest 'com.borland.star team.guy/src inside library
> 'com.borland.star team.gui'
>
>
> The .classpath file looks as following:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <classpath>
> <classpathentry exported="true" kind="lib" path="sequoia.jar"/>
> <classpathentry exported="true" kind="lib"
> path="starteam-gui-resources.jar"/>
> <classpathentry exported="true" kind="lib" path="starteam-gui.jar"/>
> <classpathentry exported="true" kind="lib"
> path="annotation-resources.jar"/>
> <classpathentry exported="true" kind="lib" path="annotation.jar"/>
> <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
> <classpathentry kind="con"
> path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
> <classpathentry kind="src" path="src"/>
> <classpathentry kind="src" path="src.geotools"/>
> <classpathentry kind="src" path="src.garuda"/>
> <classpathentry kind="src" path="src.res.ui"/>
> <classpathentry kind="src" path="src.res.core"/>
> <classpathentry kind="src" path="src.bluecove"/>
> <classpathentry kind="output" path="bin"/>
> </classpath>
Hi Klaus,
This sounds like perhaps it should be reported in Bugzilla, rather than
discussed here.
But I wonder, is that error message exactly correct, or is it mis-typed? I
am puzzled by the space in "star team", and by the fact that it is ".guy" in
one place and ".gui" in another. I don't think either spaces or hyphens
would be acceptable in a package name, so it seems like maybe there is a
mismatch between the directory structure and the package naming, which could
provoke problems. I am just guessing, because you don't really provide
enough information, e.g., you don't say anything about what your directory
structure is.
Are you able to reproduce this in a test scenario that would let Eclipse
developers see it happen?
Are there any other errors reported in the Eclipse error log?
|
|
|
| Re: Cannot nest source folder inside library [message #257998 is a reply to message #257894] |
Thu, 08 January 2009 12:28 |
| Eclipse User |
|
|
|
Originally posted by: Klaus.Wenger.Borland.com
This is a multi-part message in MIME format.
------=_NextPart_000_0009_01C9718C.9D1C0870
Content-Type: text/plain;
format=flowed;
charset="iso-8859-1";
reply-type=response
Content-Transfer-Encoding: 7bit
hello walter,
sorry about the mangled names in the listings, i had not noticed that spell
checking had wreaked havoc in the preformatted parts. i pasted the correct
..classpath contents below again.
first i thought it was the dot-notation i use for the source folders that
collided with the Java dot notation for packages and renamed them using
underscores instead. to no avail though. strangely enough i have the same
notation and a similar source root structure in other plug-ins which compile
just fine. i attached the directory tree listing of the plug-in to this mail
as you requested.
many thanks for giving this look,
klaus
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry exported="true" kind="lib" path="sequoia.jar"/>
<classpathentry exported="true" kind="lib"
path="starteam-gui-resources.jar"/>
<classpathentry exported="true" kind="lib" path="starteam-gui.jar"/>
<classpathentry exported="true" kind="lib" path="annotation-resources.jar"/>
<classpathentry exported="true" kind="lib" path="annotation.jar"/>
<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="src" path="src"/>
<classpathentry kind="src" path="src.geotools"/>
<classpathentry kind="src" path="src.garuda"/>
<classpathentry kind="src" path="src.res.ui"/>
<classpathentry kind="src" path="src.res.core"/>
<classpathentry kind="src" path="src.bluecove"/>
<classpathentry kind="output" path="bin"/>
</classpath>
"Walter Harley" <eclipse@cafewalter.com> wrote in message
news:gjjfu1$gpe$1@build.eclipse.org...
> "Klaus Wenger" <Klaus.Wenger@Borland.com> wrote in message
> news:gjgc4d$73r$1@build.eclipse.org...
>> Hello JDT community,
>>
>> I read that 3.5M4 can handle nested source folders now given the right
>> exclude patterns.
>> When migrating our existing codebase that compiles perfectly well in
>> 3.4.x and has no nested source folders, I get the strangest of errors:
>>
>> Cannot nest 'com.borland.star team.guy/src inside library
>> 'com.borland.star team.gui'
>>
>>
>> The .classpath file looks as following:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <classpath>
>> <classpathentry exported="true" kind="lib" path="sequoia.jar"/>
>> <classpathentry exported="true" kind="lib"
>> path="starteam-gui-resources.jar"/>
>> <classpathentry exported="true" kind="lib" path="starteam-gui.jar"/>
>> <classpathentry exported="true" kind="lib"
>> path="annotation-resources.jar"/>
>> <classpathentry exported="true" kind="lib" path="annotation.jar"/>
>> <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
>> <classpathentry kind="con"
>> path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
>> <classpathentry kind="src" path="src"/>
>> <classpathentry kind="src" path="src.geotools"/>
>> <classpathentry kind="src" path="src.garuda"/>
>> <classpathentry kind="src" path="src.res.ui"/>
>> <classpathentry kind="src" path="src.res.core"/>
>> <classpathentry kind="src" path="src.bluecove"/>
>> <classpathentry kind="output" path="bin"/>
>> </classpath>
>
> Hi Klaus,
>
> This sounds like perhaps it should be reported in Bugzilla, rather than
> discussed here.
>
> But I wonder, is that error message exactly correct, or is it mis-typed?
> I am puzzled by the space in "star team", and by the fact that it is
> ".guy" in one place and ".gui" in another. I don't think either spaces or
> hyphens would be acceptable in a package name, so it seems like maybe
> there is a mismatch between the directory structure and the package
> naming, which could provoke problems. I am just guessing, because you
> don't really provide enough information, e.g., you don't say anything
> about what your directory structure is.
>
> Are you able to reproduce this in a test scenario that would let Eclipse
> developers see it happen?
>
> Are there any other errors reported in the Eclipse error log?
>
------=_NextPart_000_0009_01C9718C.9D1C0870
Content-Type: text/plain;
format=flowed;
name="tree.txt";
reply-type=response
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="tree.txt"
Folder PATH listing for volume Vista 32-bit
Volume serial number is A027-8043
B:.
+---.apt_generated
+---.externalToolBuilders
+---.settings
+---bin
| +---com
| | +---bluecove
| | | \---tileit
| | | \---ui
| | | +---typeselection
| | | | +---jface
| | | | \---swt
| | | \---util
| | +---borland
| | | +---starteam
| | | | +---eclipse
| | | | | \---internal
| | | | | \---ui
| | | | | +---actiondelegates
| | | | | \---workarounds
| | | | +---gui
| | | | | +---adapters
| | | | | +---autorefresh
| | | | | +---breadcrumb
| | | | | +---compare
| | | | | +---context
| | | | | +---controller
| | | | | +---decoration
| | | | | +---editors
| | | | | +---find
| | | | | +---jface
| | | | | | +---action
| | | | | | +---dialogs
| | | | | | +---resource
| | | | | | +---utility
| | | | | | \---viewers
| | | | | +---model
| | | | | | \---action
| | | | | +---notification
| | | | | +---operations
| | | | | +---preferences
| | | | | +---properties
| | | | | +---search
| | | | | +---swt
| | | | | | +---controls
| | | | | | +---customlayout
| | | | | | +---dnd
| | | | | | \---utility
| | | | | +---util
| | | | | +---utility
| | | | | +---vcm
| | | | | | +---controller
| | | | | | +---controls
| | | | | | \---wizards
| | | | | +---view
| | | | | +---views
| | | | | +---widgets
| | | | | | +---event
| | | | | | \---swt
| | | | | \---wizards
| | | | | \---legacy
| | | | \---url
| | | \---team
| | | \---starteam
| | | +---core
| | | | +---autorefresh
| | | | +---common
| | | | +---elite
| | | | +---handle
| | | | +---internal
| | | | | \---model
| | | | +---items
| | | | +---jobs
| | | | +---operations
| | | | +---resman
| | | | \---state
| | | \---ui
| | | +---common_resources
| | | +---internal
| | | | +---actions
| | | | +---compare
| | | | +---context
| | | | +---datetimecomponents
| | | | +---decoration
| | | | +---dialogs
| | | | +---file
| | | | +---misc
| | | | +---operations
| | | | +---preferences
| | | | +---project
| | | | +---properties
| | | | +---resources
| | | | +---synchronize
| | | | | \---interim
| | | | | \---team_internal_ui_sync
| | | | +---uicontroladapters
| | | | +---util
| | | | +---views
| | | | \---wizards
| | | \---views
| | \---starbase
| | \---starteam
| | +---gui
| | | +---dialogs
| | | \---images
| | +---gui_core
| | | +---dialogs
| | | | \---renderer
| | | +---sort
| | | \---utility
| | \---gui_ui
| | +---basic
| | +---menus
| | +---toolbars
| | \---wizard
| \---org
| \---geowidgets
| \---framework
| \---swtadapters
+---icons
| \---full
| +---clcl16
| +---cview16
| +---dlcl16
| +---elcl16
| +---etool16
| +---eview16
| +---obj16
| +---ovr16
| +---wizards
| \---wizban
+---META-INF
+---resources.core
| \---com
| +---borland
| | \---team
| | \---starteam
| | \---core
| | +---autorefresh
| | +---common
| | +---elite
| | +---handle
| | +---internal
| | | \---model
| | +---items
| | +---jobs
| | +---operations
| | +---resman
| | \---state
| \---starbase
| \---starteam
| \---gui_core
| +---dialogs
| | \---renderer
| +---sort
| \---utility
+---resources.ui
| \---com
| +---borland
| | +---starteam
| | | \---eclipse
| | | \---internal
| | | \---ui
| | | +---actiondelegates
| | | \---workarounds
| | \---team
| | \---starteam
| | \---ui
| | +---common_resources
| | +---internal
| | | +---actions
| | | +---compare
| | | +---context
| | | +---datetimecomponents
| | | +---decoration
| | | +---dialogs
| | | +---file
| | | +---misc
| | | +---operations
| | | +---preferences
| | | +---project
| | | +---properties
| | | +---resources
| | | +---synchronize
| | | | \---interim
| | | | \---team_internal_ui_sync
| | | +---uicontroladapters
| | | +---util
| | | +---views
| | | \---wizards
| | \---views
| \---starbase
| \---starteam
| \---gui_ui
| +---basic
| +---menus
| +---toolbars
| \---wizard
+---schema
+---src
| \---com
| \---borland
| \---starteam
| \---gui
| +---adapters
| +---autorefresh
| +---breadcrumb
| +---compare
| +---context
| +---controller
| +---decoration
| +---editors
| +---find
| +---jface
| | +---action
| | +---dialogs
| | +---resource
| | +---utility
| | \---viewers
| +---model
| +---notification
| +---operations
| +---preferences
| +---properties
| +---search
| +---swt
| | +---controls
| | +---customlayout
| | +---dnd
| | \---utility
| +---utility
| +---vcm
| | +---controller
| | +---controls
| | \---wizards
| +---views
| +---widgets
| | +---event
| | \---swt
| \---wizards
| \---legacy
+---src.bluecove
| \---com
| \---bluecove
| \---tileit
| \---ui
| +---typeselection
| | +---jface
| | \---swt
| \---util
+---src.garuda
| \---com
| +---borland
| | \---starteam
| | +---gui
| | | +---model
| | | | \---action
| | | +---util
| | | \---view
| | \---url
| \---starbase
| \---starteam
| \---gui
| +---dialogs
| \---images
+---src.geotools
| \---org
| \---geowidgets
| \---framework
| \---swtadapters
+---src.res.core
| \---com
| +---borland
| | \---team
| | \---starteam
| | \---core
| | +---autorefresh
| | +---common
| | +---elite
| | +---handle
| | +---internal
| | | \---model
| | +---items
| | +---jobs
| | +---operations
| | +---resman
| | \---state
| \---starbase
| \---starteam
| \---gui_core
| +---dialogs
| | \---renderer
| +---sort
| \---utility
\---src.res.ui
\---com
+---borland
| +---starteam
| | \---eclipse
| | \---internal
| | \---ui
| | +---actiondelegates
| | \---workarounds
| \---team
| \---starteam
| \---ui
| +---common_resources
| +---internal
| | +---actions
| | +---compare
| | +---context
| | +---datetimecomponents
| | +---decoration
| | +---dialogs
| | +---file
| | +---misc
| | +---operations
| | +---preferences
| | +---project
| | +---properties
| | +---resources
| | +---synchronize
| | | \---interim
| | | \---team_internal_ui_sync
| | +---uicontroladapters
| | +---util
| | +---views
| | \---wizards
| \---views
\---starbase
\---starteam
\---gui_ui
+---basic
+---menus
+---toolbars
\---wizard
------=_NextPart_000_0009_01C9718C.9D1C0870--
|
|
|
| Re: Cannot nest source folder inside library [message #258170 is a reply to message #257998] |
Sun, 18 January 2009 04:48 |
| Eclipse User |
|
|
|
Originally posted by: Klaus.Wenger.Borland.com
.... ok, i found the culprit:
looks like eclipse 3.4.x was more tolerant when it came to manifest
statements in exported libraries within plug-ins.
we have two libraries (JARs) that stem from another Java-based product of
ours that have manifests featuring classpaths. those classpaths are ignored
or tolerated by 3.4.x but wreak havoc in 3.5. by eliminating the manifest
file in the exported library all is well again.
i hope this saves somebody else in the newsgroup time in the future.
cheers,
k
"Klaus Wenger" <Klaus.Wenger@Borland.com> wrote in message
news:gk5d47$un0$1@build.eclipse.org...
> hello walter,
>
> sorry about the mangled names in the listings, i had not noticed that
> spell
> checking had wreaked havoc in the preformatted parts. i pasted the correct
> .classpath contents below again.
>
> first i thought it was the dot-notation i use for the source folders that
> collided with the Java dot notation for packages and renamed them using
> underscores instead. to no avail though. strangely enough i have the same
> notation and a similar source root structure in other plug-ins which
> compile
> just fine. i attached the directory tree listing of the plug-in to this
> mail
> as you requested.
>
> many thanks for giving this look,
>
> klaus
>
> <?xml version="1.0" encoding="UTF-8"?>
> <classpath>
> <classpathentry exported="true" kind="lib" path="sequoia.jar"/>
> <classpathentry exported="true" kind="lib"
> path="starteam-gui-resources.jar"/>
> <classpathentry exported="true" kind="lib" path="starteam-gui.jar"/>
> <classpathentry exported="true" kind="lib"
> path="annotation-resources.jar"/>
> <classpathentry exported="true" kind="lib" path="annotation.jar"/>
> <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
> <classpathentry kind="con"
> path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
> <classpathentry kind="src" path="src"/>
> <classpathentry kind="src" path="src.geotools"/>
> <classpathentry kind="src" path="src.garuda"/>
> <classpathentry kind="src" path="src.res.ui"/>
> <classpathentry kind="src" path="src.res.core"/>
> <classpathentry kind="src" path="src.bluecove"/>
> <classpathentry kind="output" path="bin"/>
> </classpath>
>
>
> "Walter Harley" <eclipse@cafewalter.com> wrote in message
> news:gjjfu1$gpe$1@build.eclipse.org...
>> "Klaus Wenger" <Klaus.Wenger@Borland.com> wrote in message
>> news:gjgc4d$73r$1@build.eclipse.org...
>>> Hello JDT community,
>>>
>>> I read that 3.5M4 can handle nested source folders now given the right
>>> exclude patterns.
>>> When migrating our existing codebase that compiles perfectly well in
>>> 3.4.x and has no nested source folders, I get the strangest of errors:
>>>
>>> Cannot nest 'com.borland.star team.guy/src inside library
>>> 'com.borland.star team.gui'
>>>
>>>
>>> The .classpath file looks as following:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <classpath>
>>> <classpathentry exported="true" kind="lib" path="sequoia.jar"/>
>>> <classpathentry exported="true" kind="lib"
>>> path="starteam-gui-resources.jar"/>
>>> <classpathentry exported="true" kind="lib" path="starteam-gui.jar"/>
>>> <classpathentry exported="true" kind="lib"
>>> path="annotation-resources.jar"/>
>>> <classpathentry exported="true" kind="lib" path="annotation.jar"/>
>>> <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
>>> <classpathentry kind="con"
>>> path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
>>> <classpathentry kind="src" path="src"/>
>>> <classpathentry kind="src" path="src.geotools"/>
>>> <classpathentry kind="src" path="src.garuda"/>
>>> <classpathentry kind="src" path="src.res.ui"/>
>>> <classpathentry kind="src" path="src.res.core"/>
>>> <classpathentry kind="src" path="src.bluecove"/>
>>> <classpathentry kind="output" path="bin"/>
>>> </classpath>
>>
>> Hi Klaus,
>>
>> This sounds like perhaps it should be reported in Bugzilla, rather than
>> discussed here.
>>
>> But I wonder, is that error message exactly correct, or is it mis-typed?
>> I am puzzled by the space in "star team", and by the fact that it is
>> ".guy" in one place and ".gui" in another. I don't think either spaces
>> or
>> hyphens would be acceptable in a package name, so it seems like maybe
>> there is a mismatch between the directory structure and the package
>> naming, which could provoke problems. I am just guessing, because you
>> don't really provide enough information, e.g., you don't say anything
>> about what your directory structure is.
>>
>> Are you able to reproduce this in a test scenario that would let Eclipse
>> developers see it happen?
>>
>> Are there any other errors reported in the Eclipse error log?
>>
>
|
|
|
|
| Re: Cannot nest source folder inside library [message #260283 is a reply to message #258193] |
Fri, 29 May 2009 05:23 |
| Eclipse User |
|
|
|
hello walter,
my wording sounded more drastic than the situation warranted ... i need to
use more smileys. no havoc was wrought and only a compilation error listed
in the Problem view part.
anyways, the problem seemes to have been addressed in the latest builds for
which i am ever so grateful. i could have worked around the problem by
stripping the bundled JARs off their violating manifest entries but the fix
definitely saves me quite some time.
thanks for your look under the bonnet and have fun!
k
"Walter Harley" <eclipse@cafewalter.com> wrote in message
news:gl3rg9$mmj$1@build.eclipse.org...
> "Klaus Wenger" <Klaus.Wenger@Borland.com> wrote in message
> news:gkuttt$esc$1@build.eclipse.org...
>> ... ok, i found the culprit:
>>
>> looks like eclipse 3.4.x was more tolerant when it came to manifest
>> statements in exported libraries within plug-ins.
>>
>> we have two libraries (JARs) that stem from another Java-based product of
>> ours that have manifests featuring classpaths. those classpaths are
>> ignored or tolerated by 3.4.x but wreak havoc in 3.5. by eliminating the
>> manifest file in the exported library all is well again.
>
> Ah, interesting. It's true that manifest classpaths do not get along with
> plugins - they're two mutually incompatible ways of expressing runtime
> dependencies. But I'm surprised to hear that it "wreaked havoc"; I would
> have guessed they would just be gracefully ignored. It might be worth
> entering a bug report, with some details on exactly what havoc was
> wrought.
>
|
|
|
Powered by
FUDForum. Page generated in 0.75398 seconds
Home