#2 is possible if we package the classloader ant task. However, in addition to being something the Ant dev team seems to recommend against, I think this becomes a point of failure downstream - I don't think we want to spend time debugging classloader issues when we could be adding functionality.
Another issue for end users is that with the excelant jars in the Ant classpath and the POI libraries in their local project directories, it's more likely that users will get out of sync between their excelant version and their POI version. With everything in the build file as a path declaration, it will be more readily apparent to users (hopefully) where the inconsistency is. If that isn't true, it's something we can check more easily if people are having issues and posting their build files. :) Unless anyone else has a suggestion on how to accomplish #2 by using existing ant functionality, I am inclined to leave things as they are. Jon ________________________________ From: Yegor Kozlov <[email protected]> To: POI Developers List <[email protected]> Sent: Tue, March 15, 2011 3:53:09 AM Subject: Re: FW: How to reference <path> elements in custom task I see the point about $ANT_HOME/lib and repeatability. Let me summarize the possible options: 1. all jar dependencies are in the Ant classpath. It "works", but potentially leads to problems. I agree that it is not the way to go. 2. poi-excelant.jar is in the Ant classpath and other POI jars are defined via a path element. The advantage is that user does not need to explicitly define the ExcelAnt tasks in build.xml because Ant loads all custom tasks from its classpath automatically. A user target in this case might look like this: <target name="mytest"> <excelant> <classpath refid="poi-3.8.classpath"/> .... </excelant> </target> where refid="poi-3.8.classpath" references a classpath with all POI dependencies. 3. User provides a path element with all the jar dependencies and explicitly registers the ExcelAnt tasks: <path id="excelant.classpath"> <pathelement location="poi-main.jar"/> <pathelement location="poi-ooxml.jar"/> <pathelement location="poi-excelant.jar"/> <pathelement location="my-udf-toolkit.jar"/> </path> <typedef resource="org/apache/poi/ss/excelant/antlib.xml" classpathref="excelant.classpath"/> We already support (1) and (3) and I'm not sure if (2) is worth the effort. When I asked about the <classpath> element support I was inspired by Ant's <junit> task. It is a core task but depends on external junit.jar and I thought ExcelAnt should follow the same rules and do one of: # Put all excelant.jar and POI jars in ANT_HOME/lib. # Do not put either in ANT_HOME/lib, and instead include their locations in your CLASSPATH environment variable. # Add both JARs to your classpath using -lib. # Specify the locations of both JARs using a <classpath> element in a <taskdef> in the build file. # Put excelant.jar in ANT_HOME/lib but include POI jars in the <classpath> passed to <excelant>. If the last item is hard to implement then it's not worth the effort. ExcelAnt does not claim to be a core Ant task, its niche is narrow and specific and defining all the dependencies in a path element is OK. Yegor On Mon, Mar 14, 2011 at 9:50 PM, Jon Svede <[email protected]> wrote: > Nick, Yegor - > > Regarding the excelant tasks and issue 50610: from the exchange below I don't >think it's going to be feasible to put only the excelant tasks in a jar file >in >$ANT_HOME/lib dir. Additionally, as the comment points out, this makes >repeatability more difficult for users (because people would have to drop in >the >excelant.jar in to the lib dir of Ant). Plus the solution to this requires >another optional jar which puts us further from a clean solution. > > I think the easiest thing to do for end users is to require users to define a >path element with all of the dependencies - the POI jars, the ExcelAnt jar, >any >jars containing FreeRefFunction implementations or other excelant related >classes. > > Do either of you have opinions about this? > > Thanks, > > Jon > > > > > > > > ----- Forwarded Message ---- > From: Peter Reilly <[email protected]> > To: Ant Users List <[email protected]> > Sent: Mon, March 14, 2011 12:27:25 PM > Subject: Re: How to reference <path> elements in custom task > > There is nothing in ant that would do that (it was > planned at one stage). > > In any case, it is not good practice to place > any extra jars into $ANT_HOME/lib, as this > makes reproducible builds difficult. > > The ant-classloader task > http://enitsys.sourceforge.net/ant-classloadertask/ (written by > Rainer Noack) will > solve your problem, but at the "cost" of an extra jar. > > Peter > > > On Mon, Mar 14, 2011 at 5:56 PM, Jon Svede <[email protected]> wrote: >> Wolfgang, >> >> Thanks for the reply. >> >> So originally I had my tasks working by defining a <path> entry that >> included >>my >> tasks and their dependencies. This worked fine without me having to do >anything >> other than define <taskdef> entries in my build file. >> >> Then I was asked to make it so that my tasks could be put into the >>$ANT_HOME/lib >> dir but be able to define the dependencies in the build.xml. This did not >>work. >> My tasks would be found, but the dependencies were not. I am guessing it's >> parentage thing: my classes are higher in the classloader parentage than it's >> dependencies. I then tested this by adding all the classes my tasks depend on >> to my jar file in the $ANT_HOME/lib - that worked too, but it failed when I >> added classes that implement my interfaces. In this case, I think it is >again >> some sort of parentage issue. >> >> My specific use case is as follows: >> >> I have a set of ant tasks that depend on Apache POI for spreadsheet testing. > I >> do not want to package the POI classes into my jar. Secondarily, my jar >> file >>of >> tasks defines an interface for users to implement; those implementations can >be >> given to my ant tasks for execution. >> >> I thought, perhaps incorrectly, that if my tasks could access the path element >> and then "inject" those references into the execution environment I'd be >> able >>to >> move forward. Am I mistaken? >> >> Most of what I found either didn't apply or I didn't understand. What I did >> find outside of that didn't seem to help. I found a reference to a >Classloader >> task written by Peter Reilly but this is again an external task. I have been >> under the assumption that I would be able to resolve my issue with the core >ant >> tasks rather than requiring additional non-core jars. >> >> Does that give you more insight into my problem? It's entirely possible that >> what I want to do isn't feasible but that is what I am basically asking: can I >> do this as I've described or is there another, more preferable way to >>accomplish >> this? >> >> Sincerely, >> >> Jon >> >> >> >> >> ________________________________ >> From: wolfgang haefelinger <[email protected]> >> To: Ant Users List <[email protected]> >> Sent: Mon, March 14, 2011 11:21:57 AM >> Subject: Re: How to reference <path> elements in custom task >> >> Jon, >> >>> <someCustomTask classpathref="some.path"/> >> >> This attribute of yours, "classpathref" is not a standard attribute: >> http://ant.apache.org/manual/Tasks/common.html >> >>> I've been searching for examples or forum posts related to this but >everything >>> I've found isn't working. >> >> How about sharing what you've found and what exactly is not working? >> >> // Wolfgang >> >> On Mon, Mar 14, 2011 at 5:50 PM, Jon Svede <[email protected]> wrote: >>> Hi, >>> >>> I have a set of custom tasks that need to be able to load dependencies from >>> <path> element. In my case my tasks may be defined in <taskdef> declarations >>>or >>> via adding the jar file to the $ANT_HOME/lib dir. >>> >>> This is what I want to have in the build.xml file: >>> >>> >>> <path name="some.path"> >>> <pathelement location="some/local/dir/my.jar"/> >>> </path> >>> >>> <target name="mytarget"> >>> <someCustomTask classpathref="some.path"/> >>> </target> >>> >>> >>> In this example the task someCustomTask needs to be able to have classes from >>> the path 'some.path' to be able to execute. >>> >>> I've been searching for examples or forum posts related to this but >everything >>> I've found isn't working. Does anyone have a good explanation of this is >> done >>> or are there some docs on this? >>> >>> Thanks in advance, >>> >>> Jon >>> >>> >>> >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
