IvyDE Source Attachments?

[Craig Setera-3]

I've been reading with some interest the conversation about source (as
conf or type).  I'm not really too worked up about which way to
represent them, but I'm very interested in getting source attachments
working in IvyDE now that I know it should be possible.  Unfortunately,
I'm having trouble getting it to actually work and I'm not sure what is
going on.  I have defined my artifacts as:

<publications>
<artifact name="mb-common" ext="jar" type="jar" conf="dist"/>
<artifact name="mb-common-src" ext="jar" type="source" conf="dist"/>
</publications>

In stepping through the Ivy code, I can see that it has found the
appropriate source artifact going into the
PreferenceStoreInfo#getSourceAttachment:

/Users/setera/.ivy2/adhoc/repository/mfoundry.mbanking/mb-common/2.1.13/jars/mb-common-2.1.13-src.jar

When stepping into:

     public IPath getSourceAttachment(Path path) {
         String srcPath =
preferenceStore.getString(path.toPortableString() + SRC_SUFFIX);

Unfortunately, this always seems to return the project as the root,
which isn't correct in this case:

/MB_Common

I'm not entirely sure what is going on or what those project-level
preferences should be doing.  Can anyone shed some light on this?

Thanks,
Craig

[topher1120]

I got this to work in a bit of a different way.  Not sure if it's really
correct, but it publishes to our Maven repo correctly (also have it
publishing javadoc this way).  Let's take my project for some additional
unit test functions called unit-test-utils
After my base build, but before my publish, the build directory looks like:
  - jar
      - unit-test-utils.jar
  - javadoc
      - unit-test-utils.jar
  - source
      - unit-test-utils.jar

In ivy.xml, do the following:
   add 'xmlns:m="http://ant.apache.org/ivy/maven"' to the ivy-module element

  then my publications look like:
  <artifact conf="default" name="unit-test-utils" type="jar" ext="jar"  />
  <artifact conf="default" name="unit-test-utils" type="source" ext="jar"
m:classifier="sources" />
  <artifact conf="default" name="unit-test-utils" type="javadoc" ext="jar"
m:classifier="javadoc" />

In ivysettings.xml, my publishing resolver looks like:
<url name="publish_snapshot" m2compatible="true">
    <artifact
            pattern="
http://mavenhost/repo/[organization]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]"
/>
</url>

Finally, my publishing target in ant looks like:
<ivy:publish pubrevision="${ivyPubRevision}" resolver="publish_snapshot"
update="true" overwrite="true">
      <artifacts pattern="${build.dir}/[type]/[artifact].[ext]" />
</ivy:publish>

Once I do this, then IvyDE pulls the source into the other projects that
rely on this project.

Hope this helps.

Thanks,
topher


On Fri, Oct 30, 2009 at 6:51 AM, Craig Setera <craig@...> wrote:

> I've been reading with some interest the conversation about source (as conf
> or type).  I'm not really too worked up about which way to represent them,
> but I'm very interested in getting source attachments working in IvyDE now
> that I know it should be possible.  Unfortunately, I'm having trouble
> getting it to actually work and I'm not sure what is going on.  I have
> defined my artifacts as:
>
> <publications>
> <artifact name="mb-common" ext="jar" type="jar" conf="dist"/>
> <artifact name="mb-common-src" ext="jar" type="source" conf="dist"/>
> </publications>
>
> In stepping through the Ivy code, I can see that it has found the
> appropriate source artifact going into the
> PreferenceStoreInfo#getSourceAttachment:
>
>
> /Users/setera/.ivy2/adhoc/repository/mfoundry.mbanking/mb-common/2.1.13/jars/mb-common-2.1.13-src.jar
>
> When stepping into:
>
>    public IPath getSourceAttachment(Path path) {
>        String srcPath = preferenceStore.getString(path.toPortableString() +
> SRC_SUFFIX);
>
> Unfortunately, this always seems to return the project as the root, which
> isn't correct in this case:
>
> /MB_Common
>
> I'm not entirely sure what is going on or what those project-level
> preferences should be doing.  Can anyone shed some light on this?
>
> Thanks,
> Craig
>
>

[Nicolas Lalevée]

Le 30 oct. 2009 à 13:51, Craig Setera a écrit :

> I've been reading with some interest the conversation about source  
> (as conf or type).  I'm not really too worked up about which way to  
> represent them, but I'm very interested in getting source  
> attachments working in IvyDE now that I know it should be possible.  
> Unfortunately, I'm having trouble getting it to actually work and  
> I'm not sure what is going on.  I have defined my artifacts as:
>
> <publications>
> <artifact name="mb-common" ext="jar" type="jar" conf="dist"/>
> <artifact name="mb-common-src" ext="jar" type="source" conf="dist"/>
> </publications>
>
> In stepping through the Ivy code, I can see that it has found the  
> appropriate source artifact going into the  
> PreferenceStoreInfo#getSourceAttachment:
>
> /Users/setera/.ivy2/adhoc/repository/mfoundry.mbanking/mb-common/
> 2.1.13/jars/mb-common-2.1.13-src.jar
>
> When stepping into:
>
>    public IPath getSourceAttachment(Path path) {
>        String srcPath = preferenceStore.getString
> (path.toPortableString() + SRC_SUFFIX);
>
> Unfortunately, this always seems to return the project as the root,  
> which isn't correct in this case:
>
> /MB_Common
>
> I'm not entirely sure what is going on or what those project-level  
> preferences should be doing.  Can anyone shed some light on this?

The code you are looking into should probably get removed as no UI has  
been developed to control theses. Then I am wondering why your Eclipse  
return a non null value in the code you describes.
If you want to debug, you should better look into  
IvyClasspathContainerMapper to know what is happening.

At least in your use case seems correct, I see no reason IvyDE  
wouldn't attach sources.
In your setup, have you at least "-src" in your sources suffixes ? and  
have you at least "source" in your source type ?

Nicolas

[Craig Setera-3]

> The code you are looking into should probably get removed as no UI has
> been developed to control theses. Then I am wondering why your Eclipse
> return a non null value in the code you describes.
> If you want to debug, you should better look into
> IvyClasspathContainerMapper to know what is happening.
>
> At least in your use case seems correct, I see no reason IvyDE
> wouldn't attach sources.
> In your setup, have you at least "-src" in your sources suffixes ? and
> have you at least "source" in your source type ?
>
> Nicolas
>

Source types: source
Source suffixes: -source,-sources,-src

So, I've no idea why this wouldn't work.  It certainly *seems* like it
should work.  Any other pointers would be greatly appreciated.

Thanks,
Craig

[Stephen Haberman]

Craig Setera-3 wrote:

So, I've no idea why this wouldn't work.  It certainly *seems* like it
should work.  Any other pointers would be greatly appreciated.

I just had some fun--so, I had a jar that wasn't having its source attached, couldn't figure it out. Checked out the IvyDE source, the IvyContainerClasspathMapper code looked very sensible. Of course, trunk is different than the release version I was running, so I decide to try trunk. Build the feature dev zip, installed it.

Still didn't work. Using the IvyDE Eclipse project, I did Debug As Eclipse, open up my project in its workspace, and it works. Wtf. Technically I was using a PDK Eclipse install for the IvyDE project, and a plain Java Eclipse install for my project, but that shouldn't matter.

After some adventures, I got it to work in my plain Java Eclipse install by just deleting and recreating my workspace. Then it worked the first time. No idea what cruft was in my old workspace keeping it from working. I downgraded to the release version and it is continuing to work just fine.

Before getting it to work, I had cleared the resolution cache and re-downloaded the artifacts from the repo. That didn't fix it. Admittedly, I did not try the "clean cache > all" button, nor the individual "every repository" cache or "default-cache"--no real idea what those are anyway (an explanation would be nice).

For what its worth, while running trunk, I ran into a few stacktraces.

The first seemed to be because I was use a workspace-level ivy settings file:

java.lang.NullPointerException
        at org.eclipse.core.internal.variables.StringSubstitutionEngine.substitute(StringSubstitutionEngine.java:137)
        at org.eclipse.core.internal.variables.StringSubstitutionEngine.performStringSubstitution(StringSubstitutionEngine.java:86)
        at org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:580)
        at org.apache.ivyde.eclipse.cpcontainer.IvySettingsSetup.getResolvedIvySettingsPath(IvySettingsSetup.java:62)
        at org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerState.getIvy(IvyClasspathContainerState.java:212)
        at org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerState.doGetIvy(IvyClasspathContainerState.java:183)
        at org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerState.getIvy(IvyClasspathContainerState.java:135)
        at org.apache.ivyde.eclipse.cpcontainer.IvyResolveJob.run(IvyResolveJob.java:69)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

The setting was originally an absolute file (since that is all the released version supports). I tried a workspace file and got this stack trace:

Java Model Exception: Java Model Status [common-build does not exist]
        at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:492)
        at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:2062)
        at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1820)
        at org.eclipse.jdt.internal.core.JavaProject.getRawClasspath(JavaProject.java:1842)
        at org.apache.ivyde.eclipse.cpcontainer.IvyClasspathUtil.getIvyClasspathContainers(IvyClasspathUtil.java:122)
        at org.apache.ivyde.common.ivyfile.IvyFileResourceListener$IvyVisitor.resourceChanged(IvyFileResourceListener.java:70)
        at org.apache.ivyde.common.ivyfile.IvyFileResourceListener$IvyVisitor.visit(IvyFileResourceListener.java:52)
        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:68)
        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
        at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:48)
        at org.apache.ivyde.common.ivyfile.IvyFileResourceListener.resourceChanged(IvyFileResourceListener.java:89)
        at org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:291)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285)
        at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149)
        at org.eclipse.core.internal.resources.Workspace.broadcastBuildEvent(Workspace.java:297)
        at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:136)
        at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Even though I did have our "common-build" project open in the workspace.

After I removed the workspace-level ivy settings file and used a project-level ivy settings file, these stack traces seemed to go away.

These may be known issues with trunk, but I just thought I'd pass along my experience.

- Stephen

[Nicolas Lalevée]

Le 4 nov. 2009 à 20:44, Stephen Haberman a écrit :

>
>
>
> Craig Setera-3 wrote:
>>
>> So, I've no idea why this wouldn't work.  It certainly *seems* like it
>> should work.  Any other pointers would be greatly appreciated.
>>
>
> I just had some fun--so, I had a jar that wasn't having its source attached,
> couldn't figure it out. Checked out the IvyDE source, the
> IvyContainerClasspathMapper code looked very sensible. Of course, trunk is
> different than the release version I was running, so I decide to try trunk.
> Build the feature dev zip, installed it.
>
> Still didn't work. Using the IvyDE Eclipse project, I did Debug As Eclipse,
> open up my project in its workspace, and it works. Wtf. Technically I was
> using a PDK Eclipse install for the IvyDE project, and a plain Java Eclipse
> install for my project, but that shouldn't matter.
>
> After some adventures, I got it to work in my plain Java Eclipse install by
> just deleting and recreating my workspace. Then it worked the first time. No
> idea what cruft was in my old workspace keeping it from working. I
> downgraded to the release version and it is continuing to work just fine.

I happens to me some times, I find it really annoying too... I suspect some Ivy cache that are not managed correctly in IvyDE but I never been able to find a reproducible use case.

>
> Before getting it to work, I had cleared the resolution cache and
> re-downloaded the artifacts from the repo. That didn't fix it. Admittedly, I
> did not try the "clean cache > all" button, nor the individual "every
> repository" cache or "default-cache"--no real idea what those are anyway (an
> explanation would be nice).
>
> For what its worth, while running trunk, I ran into a few stacktraces.
>
> The first seemed to be because I was use a workspace-level ivy settings
> file:
>
> java.lang.NullPointerException
> at
> org.eclipse.core.internal.variables.StringSubstitutionEngine.substitute(StringSubstitutionEngine.java:137)
> at
> org.eclipse.core.internal.variables.StringSubstitutionEngine.performStringSubstitution(StringSubstitutionEngine.java:86)
> at
> org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:580)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvySettingsSetup.getResolvedIvySettingsPath(IvySettingsSetup.java:62)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerState.getIvy(IvyClasspathContainerState.java:212)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerState.doGetIvy(IvyClasspathContainerState.java:183)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerState.getIvy(IvyClasspathContainerState.java:135)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyResolveJob.run(IvyResolveJob.java:69)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
>
> The setting was originally an absolute file (since that is all the released
> version supports). I tried a workspace file and got this stack trace:
>
> Java Model Exception: Java Model Status [common-build does not exist]
> at
> org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:492)
> at
> org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:2062)
> at
> org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1820)
> at
> org.eclipse.jdt.internal.core.JavaProject.getRawClasspath(JavaProject.java:1842)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathUtil.getIvyClasspathContainers(IvyClasspathUtil.java:122)
> at
> org.apache.ivyde.common.ivyfile.IvyFileResourceListener$IvyVisitor.resourceChanged(IvyFileResourceListener.java:70)
> at
> org.apache.ivyde.common.ivyfile.IvyFileResourceListener$IvyVisitor.visit(IvyFileResourceListener.java:52)
> at
> org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:68)
> at
> org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
> at
> org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
> at
> org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
> at
> org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
> at
> org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
> at
> org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:48)
> at
> org.apache.ivyde.common.ivyfile.IvyFileResourceListener.resourceChanged(IvyFileResourceListener.java:89)
> at
> org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:291)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285)
> at
> org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149)
> at
> org.eclipse.core.internal.resources.Workspace.broadcastBuildEvent(Workspace.java:297)
> at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:136)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
>
> Even though I did have our "common-build" project open in the workspace.
>
> After I removed the workspace-level ivy settings file and used a
> project-level ivy settings file, these stack traces seemed to go away.
>
> These may be known issues with trunk, but I just thought I'd pass along my
> experience.

Thanks for sharing, you might have discover a bug in trunk regrading the eclipse variable handling I recently introduced.
Could you open a bug please ?

Nicolas

[Stephen Haberman]

Nicolas Lalevée wrote:

Thanks for sharing, you might have discover a bug in trunk regrading the eclipse variable handling I recently introduced.
Could you open a bug please ?

Done.

The workspace space actually seems to be working fine now, see the bug I opened then closed after I could not reproduce it.

Not having a project-level ivy settings was still causing an NPE, per IVYDE-220.

Thanks for the IvyDE work, the variable stuff in trunk looks great.

- Stephen