From: "Mark R. Diggory" <[EMAIL PROTECTED]>
> Ohhh, I got it, I was trying to run ant and not maven. I thought maven
> was getting started by ant. The build.xml script in the jelly directory
> seems to have problems. If ant is no longer used to build Jelly,
> wouldn't it be good to get rid of the build.xml file?
>
> thanks for tolerating my absent mindedness,

Typically Maven is used to build Jelly, though there is a build.xml file
that gets autogenerated by Maven which allows Jelly to be built using Ant.
What the Ant build does is download all the required jars into the ./lib
directory. However I don't think the Ant build correctly spots new jars
available. So often you need to delete the contents of the lib directory.

If you build Jelly with Maven it should all just work.

James
-------
http://radio.weblogs.com/0112098/


> Mark
>
>
> Mark R. Diggory wrote:
> > It doesn't appear that the beanutils is gotten by maven, its gotten in
> > the ant build.xml script in the jelly directory.
> >
> >
> > [root@osprey jelly]# ant
> > Buildfile: build.xml
> >
> > init:
> >
> > get-deps:
> >       [get] Getting: http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar
> >       [get] Getting:
> > http://www.ibiblio.org/maven/ant/jars/ant-optional-1.5.jar
> >       [get] Getting:
> >
http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.4-de
v.jar
> >
> >       [get] Getting:
> >
http://www.ibiblio.org/maven/commons-collections/jars/commons-collections-2.
1.jar
> >
> >
> > ...
> >
> > http://www.ibiblio.org/maven/xmlunit/jars/xmlunit-0.8.jar
> >       [get] Getting:
> > http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
> >       [get] Getting: http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar
> >       [get] Not modified - so not downloaded
> >       [get] Getting:
> > http://www.ibiblio.org/maven/ant/jars/ant-optional-1.5.jar
> >       [get] Not modified - so not downloaded
> >
> > compile:
> >     [javac] Compiling 341 source files to
> > /root/CVS_ROOT/jakarta-commons-sandbox/jelly/target/classes
> >     [javac]
> >
/root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jel
ly/tags/core/NewTag.java:67:
> > cannot resolve symbol
> >     [javac] symbol  : class ConstructorUtils
> >     [javac] location: package beanutils
> >     [javac] import org.apache.commons.beanutils.ConstructorUtils;
> >     [javac]                                     ^
> >     [javac]
> >
/root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jel
ly/tags/core/NewTag.java:127:
> > cannot resolve symbol
> >     [javac] symbol  : variable ConstructorUtils
> >     [javac] location: class org.apache.commons.jelly.tags.core.NewTag
> >     [javac]             object =
> > ConstructorUtils.invokeConstructor(theClass,values,types);
> >     [javac]                      ^
> >     [javac] 2 errors
> >
> > BUILD FAILED
> > file:/root/CVS_ROOT/jakarta-commons-sandbox/jelly/build.xml:34: Compile
> > failed; see the compiler error output for details.
> >
> > Total time: 52 seconds
> > [root@osprey jelly]#
> >
> >
> > James Strachan wrote:
> >
> >> From: "Mark R. Diggory" <[EMAIL PROTECTED]>
> >>
> >>> James Strachan wrote:
> >>>
> >>>> From: "Mark R. Diggory" <[EMAIL PROTECTED]>
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> I'm curious what is currently the most stable release of Jelly? I
> >>>>> checked out the cvs tree and tries to build it, but it seems to
> >>>>> break on
> >>>>> certain dependencies.
> >>>>
> >>>>
> >>>>
> >>>> It shouldn't do. Are you using Maven to build it? What problems did
you
> >>>> find - it should all just work.
> >>>>
> >>>
> >>>
> >>>     [javac]
> >>>
> >>
> >>
/root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jel
> >>
> >> ly/tags/core/NewTag.java:67:
> >>
> >>> cannot resolve symbol
> >>>     [javac] symbol  : class ConstructorUtils
> >>>     [javac] location: package beanutils
> >>>     [javac] import org.apache.commons.beanutils.ConstructorUtils;
> >>>     [javac]                                     ^
> >>>     [javac]
> >>>
> >>
> >>
/root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jel
> >>
> >> ly/tags/core/NewTag.java:127:
> >>
> >>> cannot resolve symbol
> >>>     [javac] symbol  : variable ConstructorUtils
> >>>     [javac] location: class org.apache.commons.jelly.tags.core.NewTag
> >>>     [javac]             object =
> >>> ConstructorUtils.invokeConstructor(theClass,values,types);
> >>>     [javac]                      ^
> >>>     [javac] 2 errors
> >>>
> >>> BUILD FAILED
> >>> file:/root/CVS_ROOT/jakarta-commons-sandbox/jelly/build.xml:34:
Compile
> >>> failed; see the compiler error output for details.
> >>
> >>
> >>
> >> This looks like you've got an old version of commons-beanutils. Wierd,
> >> Maven
> >> should have automatically reloaded this for you
> >>
> >> If you delete the jars in
$MAVEN_HOME/repository/commmons-beanutils/jars
> >>
> >> and do another build it should work fine I think
> >>
> >> BTW which Maven version is this?
> >>
> >>
> >>>>> I'd like to begin experimenting with Jelly as a
> >>>>> Mathematical Simulation tool, not neccessarily as a developer, so
I'd
> >>>>> like a pretty stable release thats going to not be too buggy.
> >>>>
> >>>>
> >>>>
> >>>> Its pretty stable - its been used in various projects such as Maven
for
> >>>> quite some time. Though we do really need to get a release out soon
so
> >>>
> >>>
> >> folks
> >>
> >>>> can depend on a formal release. Until now you could depend on a
> >>>> snapshot
> >>>> build from here...
> >>>>
> >>>> http://www.ibiblio.org/maven/commons-jelly/jars/
> >>>>
> >>>
> >>>
> >>> This is helpfull, but there are a great number of versions (nightly
> >>> builds?, beta N's, dev branchs) which is the best to use?
> >>
> >>
> >>
> >> The latest :-)
> >>
> >>
> >>
> >>> For my experience working with other jakarta commons projects, its
often
> >>> hard to judge what the best release (formal or informal) to use is.
> >>
> >>
> >>
> >> Totally agree and understand.
> >>
> >>
> >>> I definitly agree with the release thread going on now. For Jelly to
be
> >>> of use to the common user, there needs to be stable release points
they
> >>> can reley on. If their own work is based on the bleeding edge of the
> >>> development branch it will create much suffering for them. This is
> >>> because the HEAD branch cycles between states of stablity/unstability
as
> >>> development progresses. Depending on when they checkout the cvs, they
> >>> could be grabbing from anywhere in cycle.
> >>
> >>
> >>
> >> Agreed.
> >>
> >>
> >>
> >>> Another question, do you have a current timeline for releasing 1.0?
> >>
> >>
> >>
> >> Not right now no. If its any help, I don't expect much in the way of
code
> >> changes between now and 1.0 and certainly the API should remain pretty
> >> consistent -  I think its mostly gonna be documentation & packaging
> >> issues.
> >>
> >> James
> >> -------
> >> http://radio.weblogs.com/0112098/
> >>
> >> __________________________________________________
> >> Do You Yahoo!?
> >> Everything you'll ever need on one web page
> >> from News and Sport to Email and Music Charts
> >> http://uk.my.yahoo.com
> >>
> >> --
> >> To unsubscribe, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >> For additional commands, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >>
> >
> >
>
>
> --
> _________________________________
> Mark Diggory
> Project Manager/Software Developer
> Harvard-MIT Data Center
> 617-496-7246
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to