ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Dilley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (IVYDE-200) The gui wizard crash when adding a IvyDE Managed Dependencies library to a .launch file's classpath
Date Tue, 15 Sep 2009 16:05:57 GMT

    [ https://issues.apache.org/jira/browse/IVYDE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755546#action_12755546
] 

Jason Dilley commented on IVYDE-200:
------------------------------------

Yes, when I mentioned that I had done an install from the trunk I was using the Hudson builds
as referenced on the IvyDE download page (It refers us to use http://hudson.zones.apache.org/hudson/view/Ant/job/IvyDE-updatesite/lastSuccessfulBuild/artifact/trunk/build)

I hadn't paid attention to the build date in the Hudson builds. I did a manual build from
the svn trunk source just now, and the gui now displays properly when adding the Ivy library
to a launch classpath. 

One issue, though, regarding the Resolve issue you were mentioning.  You had previously said
that a launch wasn't tied to a project, so we'd need to provide an explicit file path.  We
never did, as it appeared that the launches were properly tied to a project.  I assumed that
at least for JUnit's where you have to specify a project and a class that would always be
the case.  Whatever the reason, all of our JUnit launches did properly find and use the right
ivy.xml without providing anything on the path other than 'ivy.xml'.

With the latest trunk changes, though, it's now requiring an explicit file path.  This would
seem to not be desired, as an explicit path includes evidence of my OS and the location of
my workspace i.e. c:/appWorkspaces/workspace1/project1/ivy.xml whereas another developer's
path for the same file may be /home/developer1/workspaceA/project1/ivy.xml (We often pull
the same code into multiple workspaces for parallel development efforts).  In these cases,
developers can't share .launches, which is a significant issue as we have dozens of JUnit's
with corresponding launches, all checked into CVS to allow reuse.

Is it possible to either change it back to recognize the project as it was before, or if we
need to supply a path to the ivy file have that path be relative to the workspace root, and
not the file system root?  For my example above, this would be: '/project1/ivy.xml'

> The gui wizard crash when adding a IvyDE Managed Dependencies library to a .launch file's
classpath
> ---------------------------------------------------------------------------------------------------
>
>                 Key: IVYDE-200
>                 URL: https://issues.apache.org/jira/browse/IVYDE-200
>             Project: IvyDE
>          Issue Type: Bug
>    Affects Versions: 2.0.0.final
>         Environment: Windows XP sp3, Springsource Tool Suite 2.1 (Eclipse 3.5), IvyDE
2.0.0 Final, Ivy 2.1 RC1
>            Reporter: Jason Dilley
>            Assignee: Nicolas Lalevée
>             Fix For: 2.1.0
>
>
> When adding an IvyDE library to the build path for a Java project, everything goes fine.
 I receive the gui wizard which locates the ivy.xml file and let's me pick which confs I want
to use.
> However, when I try to do the same thing for a .launch file (i.e. setting up the launch
for a JUnit Test case), once I choose Add Library and select IvyDE Managed Dependencies and
hit Next, the wizard should proceed to the next screen, but instead it stays on the 'Select
library type to add' screen.  It acts as if it's proceeding though the flow, however.  It
does pop up a error "balloon" which says 'Ivy file not found' even though it's still on the
'Select library screen'.  The ivy.xml is in the correct place, as I can add an Ivy library
to the project's build path just fine.  I can then click the Next button again, which takes
me to a screen which says "Choose ivy file and its configurations", but the screen is completely
blank (no labels, form fields, etc.) and I still have the error "balloon" mentioned earlier.
 From here I can click Finish, and the library is added to the .launch's classpath, but something
about it causes the JUnit to not load any dependencies contained in the ivy.xml file.
> In my particular case it was obvious as I would get  the exception below when running
the JUnit:
> java.lang.NoClassDefFoundError: org/junit/runner/notification/RunListener
> Here's the classpath entry which was added from the above steps.
> <listEntry value="&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;&#13;&#10;&lt;runtimeClasspathEntry
containerPath=&quot;org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/?ivyXmlPath=ivy.xml&amp;amp;confs=*&quot;
path=&quot;3&quot; type=&quot;4&quot;/&gt;&#13;&#10;"/>
> Instead of adding the library individually like outline above, if I choose to add the
project to the .launch's classpath accepting all of it's exported entries and required projects,
I get the entry below.  Note the difference - confs=default instead of confs=* from the first
entry.
> <listEntry value="&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;&#13;&#10;&lt;runtimeClasspathEntry
containerPath=&quot;org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/?ivyXmlPath=ivy.xml&amp;amp;confs=default&quot;
path=&quot;3&quot; type=&quot;4&quot;/&gt;&#13;&#10;"/>
> If I change the first entry to match the second in regards to confs=default, then the
dependencies contained in the ivy.xml are loaded properly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message