You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Craig Setera <cr...@mfoundry.com> on 2009/10/30 13:51:12 UTC
IvyDE Source Attachments?
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
Re: IvyDE Source Attachments?
Posted by Chris Marks <to...@gmail.com>.
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 <cr...@mfoundry.com> 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
>
>
Re: IvyDE Source Attachments?
Posted by Stephen Haberman <st...@exigencecorp.com>.
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
--
View this message in context: http://old.nabble.com/IvyDE-Source-Attachments--tp26129568p26362718.html
Sent from the ivy-user mailing list archive at Nabble.com.
Re: IvyDE Source Attachments?
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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
Re: IvyDE Source Attachments?
Posted by Stephen Haberman <st...@exigencecorp.com>.
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
--
View this message in context: http://old.nabble.com/IvyDE-Source-Attachments--tp26129568p26203374.html
Sent from the ivy-user mailing list archive at Nabble.com.
Re: IvyDE Source Attachments?
Posted by Craig Setera <cr...@mfoundry.com>.
> 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
Re: IvyDE Source Attachments?
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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