[jira] Created: (IVY-671) Ivy version information doesn't fit on 1 line

2007-12-17 Thread Maarten Coene (JIRA)
Ivy version information doesn't fit on 1 line
-

 Key: IVY-671
 URL: https://issues.apache.org/jira/browse/IVY-671
 Project: Ivy
  Issue Type: Improvement
  Components: Ant
Affects Versions: 2.0.0-beta-1
Reporter: Maarten Coene


When Ivy is loaded, the version is printed on the console.
For 2.0.0-beta1, this information doesn't fit on a single line (cfr the blank 
line after ivy:info):

{code}
init-classpaths-with-ivy:
 [ivy:info] :: Ivy 2.0.0-beta1 - 20071206070608 :: http://ant.apache.org/ivy/ ::

:: loading settings :: file = C:\working\repository\commons\lcm\ant_build\config
\ivy\ivysettings.xml
{code}

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



[jira] Created: (IVY-672) No error message is logged when a circular dependency is detected

2007-12-17 Thread Maarten Coene (JIRA)
No error message is logged when a circular dependency is detected
-

 Key: IVY-672
 URL: https://issues.apache.org/jira/browse/IVY-672
 Project: Ivy
  Issue Type: Bug
Affects Versions: 2.0.0-beta-1
Reporter: Maarten Coene


When I have a circular dependency, the resolve fails, but no error message is 
logged during the build:

{code}
Buildfile: build.xml

init:

prepare:

detect-classpath-init:

init-classpaths-with-ivy:
 [ivy:info] :: Ivy 2.0.0-beta1 - 20071206070608 :: http://ant.apache.org/ivy/ ::

:: loading settings :: file = C:\working\repository\commons\lcm\ant_build\config
\ivy\ivysettings.xml
DEPRECATED: 'conf' is deprecated, use 'settings' instead (file:/C:/working/repos
itory/commons/lcm/ant_build/config/ivy/ivysettings.xml)
[ivy:resolve] :: resolving dependencies :: LCMB#fao;[EMAIL PROTECTED]
[ivy:resolve]   confs: [default, client, impl, testapi, compile, client-compile,
 test, runtest]
[ivy:resolve]   [2.8.4] LCMT#commons;2.+
[ivy:resolve]   [1.3.1] LCMT#daohelper;1.+
[ivy:resolve]   [3.2.1] LCMT#parametermanager;3.+
[ivy:resolve]   [1.0.3] LCMB#sparadmwebservice;1.+
[ivy:resolve]   [1.2.0] LCMT#commons-webservice;1.+
[ivy:resolve]   [2.0.10] LCMT#openutm;2.+
[ivy:resolve]   [1.1.0] LCMT#profilemanager;1.+
[ivy:resolve]   [4.4.0] LCMT#logmanager;4.+
[ivy:resolve]   [3.4.0] LCMT#openutm;3.+
[ivy:resolve]   [4.3.1] LCMT#papyrus;4.+
[ivy:resolve]   [10.1.3.3] J2EE#ejb30;10.1.3.+
[ivy:resolve]   [10.1.3.3] J2EE#persistence;10.1.3.+
[ivy:resolve]   [10.1.3.3] J2EE#mail;10.1.3.+
[ivy:resolve]   [2.1.0] OTHER#commons-lang;2.+
[ivy:resolve]   [2.0.0] LCMT#commons-test;2.+
[ivy:resolve]   [10.1.3.3] J2EE#toplink-essentials;10.1.3.+
[ivy:resolve]   [10.1.3.3] J2EE#ejb;10.1.3.+
[ivy:resolve]   [10.1.3.3] J2EE#jta;10.1.3.+
[ivy:resolve]   [10.1.3.3] J2EE#jaxrpc-api;10.1.3.+

[ivy:resolve] :: problems summary ::
[ivy:resolve]  ERRORS
[ivy:resolve]   LCMT#commons;2.8.4-LCMB#sparadmwebservice;1.0.3-LCMT#parameter
manager;3.2.1-...
[ivy:resolve]
[ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS

BUILD FAILED
C:\working\repository\commons\lcm\ant_build\targets\common-targets-1.0.0.xml:390
: impossible to resolve dependencies:
org.apache.ivy.plugins.circular.CircularDependencyException: LCMT#common
s;2.8.4-LCMB#sparadmwebservice;1.0.3-LCMT#parametermanager;3.2.1-...
{code}

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



[jira] Commented: (IVY-672) No error message is logged when a circular dependency is detected

2007-12-17 Thread Maarten Coene (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552449
 ] 

Maarten Coene commented on IVY-672:
---

Yes, that would be better.
I also think it would be better if you replace the ... in the graph by the 
actual node. 

Btw, are you sure the ... points to the first node? My graph is like this:

{code}
LCMT#commons;2.8.4-LCMB#sparadmwebservice;1.0.3-LCMT#parametermanager;3.2.1-LCMB#sparadmwebservice;1.0.3
{code}

Maarten

 No error message is logged when a circular dependency is detected
 -

 Key: IVY-672
 URL: https://issues.apache.org/jira/browse/IVY-672
 Project: Ivy
  Issue Type: Bug
Affects Versions: 2.0.0-beta-1
Reporter: Maarten Coene

 When I have a circular dependency, the resolve fails, but no nice error 
 message is logged during the build, only a partial graph is logged:
 {code}
 Buildfile: build.xml
 init:
 prepare:
 detect-classpath-init:
 init-classpaths-with-ivy:
  [ivy:info] :: Ivy 2.0.0-beta1 - 20071206070608 :: http://ant.apache.org/ivy/ 
 ::
 :: loading settings :: file = 
 C:\working\repository\commons\lcm\ant_build\config
 \ivy\ivysettings.xml
 DEPRECATED: 'conf' is deprecated, use 'settings' instead 
 (file:/C:/working/repos
 itory/commons/lcm/ant_build/config/ivy/ivysettings.xml)
 [ivy:resolve] :: resolving dependencies :: LCMB#fao;[EMAIL PROTECTED]
 [ivy:resolve]   confs: [default, client, impl, testapi, compile, 
 client-compile,
  test, runtest]
 [ivy:resolve]   [2.8.4] LCMT#commons;2.+
 [ivy:resolve]   [1.3.1] LCMT#daohelper;1.+
 [ivy:resolve]   [3.2.1] LCMT#parametermanager;3.+
 [ivy:resolve]   [1.0.3] LCMB#sparadmwebservice;1.+
 [ivy:resolve]   [1.2.0] LCMT#commons-webservice;1.+
 [ivy:resolve]   [2.0.10] LCMT#openutm;2.+
 [ivy:resolve]   [1.1.0] LCMT#profilemanager;1.+
 [ivy:resolve]   [4.4.0] LCMT#logmanager;4.+
 [ivy:resolve]   [3.4.0] LCMT#openutm;3.+
 [ivy:resolve]   [4.3.1] LCMT#papyrus;4.+
 [ivy:resolve]   [10.1.3.3] J2EE#ejb30;10.1.3.+
 [ivy:resolve]   [10.1.3.3] J2EE#persistence;10.1.3.+
 [ivy:resolve]   [10.1.3.3] J2EE#mail;10.1.3.+
 [ivy:resolve]   [2.1.0] OTHER#commons-lang;2.+
 [ivy:resolve]   [2.0.0] LCMT#commons-test;2.+
 [ivy:resolve]   [10.1.3.3] J2EE#toplink-essentials;10.1.3.+
 [ivy:resolve]   [10.1.3.3] J2EE#ejb;10.1.3.+
 [ivy:resolve]   [10.1.3.3] J2EE#jta;10.1.3.+
 [ivy:resolve]   [10.1.3.3] J2EE#jaxrpc-api;10.1.3.+
 [ivy:resolve] :: problems summary ::
 [ivy:resolve]  ERRORS
 [ivy:resolve]   
 LCMT#commons;2.8.4-LCMB#sparadmwebservice;1.0.3-LCMT#parameter
 manager;3.2.1-...
 [ivy:resolve]
 [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
 BUILD FAILED
 C:\working\repository\commons\lcm\ant_build\targets\common-targets-1.0.0.xml:390
 : impossible to resolve dependencies:
 org.apache.ivy.plugins.circular.CircularDependencyException: 
 LCMT#common
 s;2.8.4-LCMB#sparadmwebservice;1.0.3-LCMT#parametermanager;3.2.1-...
 {code}

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



[jira] Resolved: (IVY-674) Ivy is resolving private dependencies as well

2007-12-17 Thread Maarten Coene (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maarten Coene resolved IVY-674.
---

Resolution: Invalid
  Assignee: Maarten Coene

I've found what caused this problem, it is something completely different so 
I'll create a new JIRA issue for it...

 Ivy is resolving private dependencies as well
 -

 Key: IVY-674
 URL: https://issues.apache.org/jira/browse/IVY-674
 Project: Ivy
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-beta-1
Reporter: Maarten Coene
Assignee: Maarten Coene
Priority: Critical

 I don't know exactly what the problem is, but it seems that Ivy is resolving 
 the dependencies from private configurations as well.
 I have the following output on my console when resolving my project.
 {code}
 [ivy:resolve] :: resolving dependencies :: LCMB#fao;[EMAIL PROTECTED]
 [ivy:resolve]   confs: [default, client, impl, testapi, compile, 
 client-compile,
  test, runtest]
 [ivy:resolve]   [2.8.4] LCMT#commons;2.+
 [ivy:resolve]   [1.3.1] LCMT#daohelper;1.+
 [ivy:resolve]   [3.2.1] LCMT#parametermanager;3.+
 [ivy:resolve]   [1.0.3] LCMB#sparadmwebservice;1.+
 [ivy:resolve]   [1.2.0] LCMT#commons-webservice;1.+
 [ivy:resolve]   [2.0.10] LCMT#openutm;2.+
 [ivy:resolve]   [1.1.0] LCMT#profilemanager;1.+
 [ivy:resolve]   [4.4.0] LCMT#logmanager;4.+
 [ivy:resolve]   [3.4.0] LCMT#openutm;3.+
 [ivy:resolve]   [4.3.1] LCMT#papyrus;4.+
 [ivy:resolve]   [10.1.3.3] J2EE#ejb30;10.1.3.+
 [ivy:resolve]   [10.1.3.3] J2EE#persistence;10.1.3.+
 [ivy:resolve]   [10.1.3.3] J2EE#mail;10.1.3.+
 [ivy:resolve]   [2.1.0] OTHER#commons-lang;2.+
 [ivy:resolve]   [2.0.0] LCMT#commons-test;2.+
 [ivy:resolve]   [10.1.3.3] J2EE#toplink-essentials;10.1.3.+
 [ivy:resolve]   [10.1.3.3] J2EE#ejb;10.1.3.+
 [ivy:resolve]   [10.1.3.3] J2EE#jta;10.1.3.+
 [ivy:resolve]   [10.1.3.3] J2EE#jaxrpc-api;10.1.3.+
 {code}
 As you can see, the openutm dependency is resolved twice: once for the 2.x 
 branch, and another time for the 3.x branch.
 However, the only place where I have defined a dependency on the openutm 2.x 
 branch is in the commons dependency. And as you can see, this is defined in a 
 private configuration!!
 {code}
 ivy-module version=1.0
 info organisation=LCMT module=commons revision=2.8.4 
 status=release publication=20070313105450/
 configurations
 conf name=default description=For default usage./
   conf name=j2ee extends=default description=For usage 
 inside an application server./
   conf name=standalone extends=default description=For 
 usage in a standalone application (e.g. batch)./
   conf name=compile extends=*(public) visibility=private 
 transitive=false/
   conf name=test visibility=private transitive=false/
   conf name=runtest extends=test,compile 
 visibility=private/
 conf name=minimal extends=default description=For minimal 
 usage, e.g. in the client API of a system./
 /configurations
 dependencies 
 defaultconfmapping=runtest-standalone(default);default,compile,test-default;standalone-[org=LCMB]client(default),[org!=LCMB]standalone(default);%-#(default);
  confmappingoverride=true
 !-- J2EE dependencies --
 dependency org=J2EE name=ejb rev= conf=compile/
 dependency org=J2EE name=jms rev= conf=standalone/
 dependency org=J2EE name=jta rev= conf=test/
 !-- technical dependencies --
 dependency org=LCMT name=daohelper rev=1.+ 
 conf=j2ee;standalone/
 dependency org=LCMT name=openutm rev=2.+ conf=compile/
 dependency org=LCMT name=parametermanager rev=3.+ conf=j2ee/
 dependency org=OTHER name=commons-beanutils rev=1.7.0 
 conf=compile/
 dependency org=OTHER name=commons-discovery rev=0.2 
 conf=j2ee;standalone/
 dependency org=OTHER name=commons-logging rev=1.0.3 
 conf=default/
 dependency org=OTHER name=commons-lang rev=2.0.0 
 conf=default/
 dependency org=OTHER name=commons-validator rev=1.1.4 
 conf=j2ee;standalone/
 dependency org=OTHER name=jakarta-regexp rev=1.4 
 conf=default/
 !-- Test dependencies --
 dependency org=LCMT name=commons-test rev=1.+ conf=test
 exclude module=commons/
 /dependency
 dependency org=OTHER name=junit rev=3.8.1 conf=test/
 dependency org=OTHER name=mockejb rev=0.5 conf=test/
 dependency org=OTHER name=mockobjects rev=0.09 conf=test/
 dependency org=OTHER name=dbunit rev=2.1.0 conf=test/
 dependency org=OTHER name=ojdbc rev=9.2.0.5 conf=test/
 /dependencies
 /ivy-module
 {code}
 It seems to me that for some reason, Ivy forgets the exact configuration for 
 the openutm dependency, because the resolve report contains this:
 {code}

[EMAIL PROTECTED]: Project dotnet-antlib-test (in module ant-antlibs) failed

2007-12-17 Thread Gump Integration Build
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project dotnet-antlib-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 8 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- dotnet-antlib-test :  Task and Type Libraries for Apache Ant


Full details are available at:

http://vmgump.apache.org/gump/public/ant-antlibs/dotnet-antlib-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump.apache.org/gump/public/ant-antlibs/dotnet-antlib-test/gump_work/build_ant-antlibs_dotnet-antlib-test.html
Work Name: build_ant-antlibs_dotnet-antlib-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 41 secs
Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dant-testutil.jar=/srv/gump/public/workspace/ant/build/lib/ant-testutil.jar 
test 
[Working Directory: /srv/gump/public/workspace/ant-antlibs/dotnet]
CLASSPATH: 
/usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant-antlibs/dotnet/build/test-classes:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant-antlibs/antunit/build/ant-antunit-17122007.jar:/srv/gump/public/workspace/ant-antlibs/dotnet/build/ant-dotnet-17122007.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar
-
[au:antunit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.023 sec
[au:antunit] Target: test-passing took 0.008 sec
[au:antunit] Build File: 
/srv/gump/public/workspace/ant-antlibs/dotnet/src/tests/antunit/dir with 
spaces/wsdl-test.xml
[au:antunit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.481 sec
[au:antunit] Target: testWSDL took 1.454 sec
[au:antunit] Build File: 
/srv/gump/public/workspace/ant-antlibs/dotnet/src/tests/antunit/dotnetexec-test.xml
[au:antunit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.85 sec
[au:antunit] Target: testCSC took 0.739 sec
[au:antunit] Build File: 
/srv/gump/public/workspace/ant-antlibs/dotnet/src/tests/antunit/nunit/nunit-test.xml
[au:antunit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.34 sec
[au:antunit] Target: test-passing took 0.009 sec
[au:antunit] Target: test-failing took 0.006 sec
[au:antunit] Target: test-failing-errorproperty took 0.178 sec
[au:antunit] Target: test-failing-with-fail took 0.005 sec
[au:antunit] Target: test-no-assembly took 0.007 sec
[au:antunit] Build File: 
/srv/gump/public/workspace/ant-antlibs/dotnet/src/tests/antunit/old-core-test.xml
[au:antunit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 9.025 sec
[au:antunit] Target: testCSCintrinsicFileset took 1.962 sec
[au:antunit] Target: testCSCresponseFile took 0.757 sec
[au:antunit] Target: testILASM took 0.843 sec
[au:antunit] Target: testCSCdll took 0.648 sec
[au:antunit] Target: testILDASM took 0.655 sec
[au:antunit] Target: testILDASM_empty took 0.046 sec
[au:antunit] Target: testJsharp took 0.042 sec
[au:antunit] Target: testCSCResources took 1.525 sec
[au:antunit] Target: testCSC took 0.777 sec
[au:antunit] Build File: 
/srv/gump/public/workspace/ant-antlibs/dotnet/src/tests/antunit/wsdl2dotnet-test.xml
[au:antunit] Tests run: 15, Failures: 0, Errors: 0, Time elapsed: 14.866 sec
[au:antunit] Target: testSchemaMustBeSet took 0.034 sec
[au:antunit] Target: testLocalWsdlVB took 0.024 sec
[au:antunit] Target: testInvalidExtraOps took 0.008 sec
[au:antunit] Target: testSrcIsMissing took 0.018 sec
[au:antunit] Target: testNoParams took 0.019 sec
[au:antunit] Target: testBothSrc took 0.009 sec
[au:antunit] Target: testSchemaFileMustHaveOneOptionOnly took 0.014 sec
[au:antunit] Target: testLocalWsdl took 1.464 sec
[au:antunit] Target: testSrcIsDir took 0.093 sec
[au:antunit] Target: testLocalWsdlServerVB took 0.008 sec
[au:antunit] Target: testLocalWsdlServer took 12.71 sec
[au:antunit] Target: testNoSrc took 0.044 sec
[au:antunit] Target: 

svn commit: r605039 - /ant/ivy/core/trunk/ivy.xml

2007-12-17 Thread maartenc
Author: maartenc
Date: Mon Dec 17 15:16:31 2007
New Revision: 605039

URL: http://svn.apache.org/viewvc?rev=605039view=rev
Log:
Fixed a NPE when running the junit tests with JDK 1.4.

Modified:
ant/ivy/core/trunk/ivy.xml

Modified: ant/ivy/core/trunk/ivy.xml
URL: 
http://svn.apache.org/viewvc/ant/ivy/core/trunk/ivy.xml?rev=605039r1=605038r2=605039view=diff
==
--- ant/ivy/core/trunk/ivy.xml (original)
+++ ant/ivy/core/trunk/ivy.xml Mon Dec 17 15:16:31 2007
@@ -52,6 +52,7 @@

!-- This dependency is necessary for having validation in 
junit tests when running with JDK1.4 --
dependency org=xerces name=xercesImpl rev=2.6.2 
conf=test-default /
+   dependency org=xerces name=xmlParserAPIs rev=2.6.2 
conf=test-default /

!-- Global exclude for junit --
exclude org=junit module=junit conf=core,default /




DO NOT REPLY [Bug 43794] - Message about JAVA_HOME is confusing

2007-12-17 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=43794.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43794





--- Additional Comments From [EMAIL PROTECTED]  2007-12-17 23:36 ---
The error message in question is produced in
org.apache.tools.ant.taskdefs.compilers.CompilerAdapterFactory.getCompiler(String
compilerType, Task task) after Javac.execute() calls compile() which calls it.

The search in getCompiler(..) is compiler type specific, but it looks like you
are running java-6 on linux or unix, so you get the common case where it calls
doesModernCompilerExist() and if this returns false, it throws the error.
Interestingly, this method doesn't appear to use either java.home or JAVA_HOME
directly. Instead it tries to load it in two ways, returning false if both fail
 - Class.forName(MODERN_COMPILER); 
 - CompilerAdapterFactory.class.getClassLoader().loadClass(MODERN_COMPILER)
where MODERN_COMPILER = com.sun.tools.javac.Main

I would think those two are usually equivalent, so the question is how
CompilerAdapterFactory.class (and presumably Javac.class) could get loaded in a
classloader that doesn't have tools.jar on it's classpath.

The message should just say something like Can't find com.sun.tools.javac.Main
on the classpath that loaded the javac task. Make sure tools.jar from the JDK is
on the classpath. It seems like the bootclasspath and classpath task attributes
could also be used to supplement the search.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.