debugging sources when all project are built with "attach-sources"

[Mck-3]

All our projects are built with "attach-sources" which results in every
jar in our local repository paired with a matching -sources.jar

Mevenide, i presume, gets into some confusion when then debugging as all
these -sources.jar appear in the debugging sources list _before_ the
corresponding project sources. This gives headaches with the file in the
editor being read-only and will breakpoints not always working.

Is this a familiar problem? Could someone point to the part of the code
responsible for this behaviour?
any help would be appreciated.
~mck

--
"Be kind. For everyone you meet is fighting a hard battle." Plato
| semb.wever.org | sesat.no | sesam.no |

[Milos Kleint-2]

On Wed, Apr 9, 2008 at 9:00 AM, Mick Semb Wever <mick@...> wrote:

> All our projects are built with "attach-sources" which results in every
>  jar in our local repository paired with a matching -sources.jar
>
>  Mevenide, i presume, gets into some confusion when then debugging as all
>  these -sources.jar appear in the debugging sources list _before_ the
>  corresponding project sources. This gives headaches with the file in the
>  editor being read-only and will breakpoints not always working.
>
>  Is this a familiar problem? Could someone point to the part of the code
>  responsible for this behaviour?
>  any help would be appreciated.

probably a bug.
org.codehaus.mevenide.netbeans.debug.JPDAStart could be a starting point.
However it will probably boil down to what
SourceForBinaryQuery.findSourceRoots(url) api call returns, and how
the implementations of SourceForBinaryQueryImplementation  are ordered
in the META-INF/services

Milos

>  ~mck
>
>  --
>  "Be kind. For everyone you meet is fighting a hard battle." Plato
>  | semb.wever.org | sesat.no | sesam.no |
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Mck-3]

On Wed, 09 Apr 2008 09:13:22 +0200, Milos Kleint wrote:

>>  Is this a familiar problem? Could someone point to the part of the
>>  code responsible for this behaviour?
>>  any help would be appreciated.
>
> probably a bug.
> org.codehaus.mevenide.netbeans.debug.JPDAStart could be a starting
> point. However it will probably boil down to what
> SourceForBinaryQuery.findSourceRoots(url) api call returns, and how the
> implementations of SourceForBinaryQueryImplementation  are ordered in
> the META-INF/services

thanks milos! i take a look and see what i find...
~mck


--
"The reward of patience is patience." St. Augustine
| www.semb.wever.org | www.sesat.no | www.sesam.no |

[Mck-3]

>> However it will probably boil down to what
>> SourceForBinaryQuery.findSourceRoots(url) api call returns, and how the
>> implementations of SourceForBinaryQueryImplementation  are ordered in
>> the META-INF/services
>
> thanks milos! i take a look and see what i find...

A very quick guess:

 i only see RepositorySourceForBinaryQueryImpl registered through
META-INF/services

 i presume that MavenForBinaryQueryImpl is added at runtime via
NbMavenProject.getLookup() and so would be added to the end of registered
services.

But i can't see where the "added to the end" actually occurs.
Is it possible to add to the beginning?

There is a comment in
nb-project/src/main/resources/META-INF/services/org.netbeans.spi.java.queries.SourceForBinaryQueryImplementation

#position=999

Is this supposed to work? Or is it a TODO comment?

~mck

--
"Laugh, share some happiness with the world. God knows we all have
problems,
believe that sometimes it pays to act like a fool to make someone else
happy!" Anon
| www.semb.wever.org | www.sesat.no | www.sesam.no |

[Milos Kleint-2]

On Wed, Apr 9, 2008 at 2:55 PM, Mick Semb Wever <mick@...> wrote:

> >> However it will probably boil down to what
>  >> SourceForBinaryQuery.findSourceRoots(url) api call returns, and how the
>  >> implementations of SourceForBinaryQueryImplementation  are ordered in
>  >> the META-INF/services
>  >
>  > thanks milos! i take a look and see what i find...
>
>  A very quick guess:
>
>   i only see RepositorySourceForBinaryQueryImpl registered through
>  META-INF/services
>
>   i presume that MavenForBinaryQueryImpl is added at runtime via
>  NbMavenProject.getLookup() and so would be added to the end of registered
>  services.

weill the instance in lookup is collected by some global
(ProjectSourceForBinaryQueryImpl) implementation that delegates to the
project's lookup. We have a custom FileOwnerQueryImplemented that
matches the jar file in local repository to opened maven project. Thus
the project SFBQ should find the owner of teh jar file in local repo
and delegate to the project's impl in lookup.

>
>  But i can't see where the "added to the end" actually occurs.
>  Is it possible to add to the beginning?
>
>  There is a comment in
>  nb-project/src/main/resources/META-INF/services/org.netbeans.spi.java.queries.SourceForBinaryQueryImplementation
>
>  #position=999

that should mean the SFQ implementation should be fairly in the back
in the list of implementations..



>
>  Is this supposed to work? Or is it a TODO comment?

that is supposed to work, yes..

Milos

>
>  ~mck
>
>  --
>  "Laugh, share some happiness with the world. God knows we all have
>  problems,
>  believe that sometimes it pays to act like a fool to make someone else
>  happy!" Anon
>
>
> | www.semb.wever.org | www.sesat.no | www.sesam.no |
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Mck-3]

>>  A very quick guess:

>>
>>   i only see RepositorySourceForBinaryQueryImpl registered through
>>  META-INF/services
>>
>>   i presume that MavenForBinaryQueryImpl is added at runtime via
>>  NbMavenProject.getLookup() and so would be added to the end of
>>  registered services.
>
> weill the instance in lookup is collected by some global
> (ProjectSourceForBinaryQueryImpl) implementation that delegates to the
> project's lookup. We have a custom FileOwnerQueryImplemented that
> matches the jar file in local repository to opened maven project. Thus
> the project SFBQ should find the owner of teh jar file in local repo and
> delegate to the project's impl in lookup.

Ok i'm starting to see a bigger picture now.
And i see that this problem isn't just related to debugging.

When i "Go To Type..." i've always had duplicates of each class, one from
the project and one from the repository's jarfile.
see attached picture.

Previously (before -sources.jar were being propagated into the local
repository) choosing either class ended up, correctly, opening the
project's source file.
But now choosing the repository's jarfile version opens the read-only
version from inside the -sources.jar. It kinda makes sense, but
definitely isn't what i want.

Of course, even better would be to "collapse" the duplicates into one.

~mck


--
"Be kind. For everyone you meet is fighting a hard battle." Plato
| www.semb.wever.org | www.sesat.no | www.sesam.no |