You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by di...@apache.org on 2003/01/02 14:57:55 UTC
cvs commit: jakarta-commons-sandbox/graph2 build.xml
dion 2003/01/02 05:57:55
Modified: graph2 build.xml
Log:
regenned
Revision Changes Path
1.3 +174 -193 jakarta-commons-sandbox/graph2/build.xml
Index: build.xml
===================================================================
RCS file: /home/cvs/jakarta-commons-sandbox/graph2/build.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build.xml 26 Jul 2002 12:36:04 -0000 1.2
+++ build.xml 2 Jan 2003 13:57:55 -0000 1.3
@@ -1,205 +1,186 @@
-<?xml version="1.0"?>
+<?xml version="1.0" encoding="UTF-8"?>
-<project name="maven" default="maven:jar" basedir=".">
-
- <!-- Give user a chance to override without editing this file
- (and without typing -D each time they invoke a target) -->
-
- <!-- Allow any user specific values to override the defaults -->
- <property file="${user.home}/build.properties" />
- <!-- Allow user defaults for this project -->
- <property file="build.properties" />
- <!-- Set default values for the build -->
- <property file="project.properties" />
+<project default="jar" name="commons-graph" basedir=".">
+
+ <property name="defaulttargetdir" value="target"></property>
+ <property name="classesdir" value="target/classes"></property>
+ <property name="testclassesdir" value="target/test-classes"></property>
+ <property name="testreportdir" value="target/test-reports"></property>
+
+
+
+
+
+
+
+
+
+
+ <property name="resourcedir" value="."></property>
+
+ <property name="distdir" value="dist"></property>
+ <property name="javadocdir" value="target/docs/apidocs"></property>
+ <property name="final.name" value="commons-graph-0.8.1"></property>
+
+ <target name="init" description="o Initializes some properties">
+ <mkdir dir="lib"></mkdir>
+ <condition property="noget">
+ <equals arg2="only" arg1="${build.sysclasspath}"></equals>
+ </condition>
+ </target>
+
+ <target name="compile" description="o Compile the code" depends="get-deps">
+
+ <mkdir dir="${classesdir}"></mkdir>
+
+ <javac destdir="${classesdir}" deprecation="true" debug="true" optimize="false" excludes="**/package.html">
+ <src>
+ <pathelement location="src/java"></pathelement>
+ </src>
+ <classpath>
+ <fileset dir="lib">
+ <include name="*.jar"></include>
+ </fileset>
+ </classpath>
+ </javac>
+
+
+
+
+
+
+ </target>
+
+ <target name="jar" description="o Create the jar" depends="compile,test">
+ <jar jarfile="target/${final.name}.jar" excludes="**/package.html" basedir="${classesdir}"></jar>
- <!-- maven:start -->
+ </target>
- <!-- ================================================================== -->
- <!-- D E L E G A T O R S -->
- <!-- ================================================================== -->
+ <target name="clean" description="o Clean up the generated directories">
+ <delete dir="${defaulttargetdir}"></delete>
+ <delete dir="${distdir}"></delete>
+ </target>
+
+ <target name="dist" description="o Create a distribution" depends="jar, javadoc">
+ <mkdir dir="dist"></mkdir>
+ <copy todir="dist">
+ <fileset dir="${defaulttargetdir}"></fileset>
+ </copy>
+ </target>
+
+ <target name="test" description="o Run the test cases" if="test.failure" depends="internal-test">
+ <fail message="There were test failures."></fail>
+ </target>
+ <target name="internal-test" depends="compile-tests">
+
+ <mkdir dir="${testreportdir}"></mkdir>
+ <junit dir="./" failureproperty="test.failure" printSummary="yes" fork="true" haltonerror="true">
+ <sysproperty key="basedir" value="."></sysproperty>
+ <formatter type="xml"></formatter>
+ <formatter usefile="true" type="plain"></formatter>
+ <classpath>
+ <fileset dir="lib">
+ <include name="*.jar"></include>
+ </fileset>
+ <pathelement path="${testclassesdir}"></pathelement>
+ <pathelement path="${classesdir}"></pathelement>
+ </classpath>
+ <batchtest todir="${testreportdir}">
+ <fileset dir="src/test">
+
+ <include name="**/*Test.java"></include>
+
+
+
+
+
+ </fileset>
+ </batchtest>
+ </junit>
+
+ </target>
+
+ <target name="compile-tests" depends="compile">
+
+ <mkdir dir="${testclassesdir}"></mkdir>
+ <javac destdir="${testclassesdir}" deprecation="true" debug="true" optimize="false" excludes="**/package.html">
+ <src>
+ <pathelement location="src/test"></pathelement>
+ </src>
+ <classpath>
+ <fileset dir="lib">
+ <include name="*.jar"></include>
+ </fileset>
+ <pathelement path="${classesdir}"></pathelement>
+ </classpath>
+ </javac>
+
+
+
+
+
+ </target>
+
+ <target name="javadoc" description="o Generate javadoc" depends="jar">
+
+
+ <mkdir dir="${javadocdir}"></mkdir>
+
+
+ <tstamp>
+ <format pattern="2001-yyyy" property="year"></format>
+ </tstamp>
+
+ <property name="copyright" value="Copyright &copy; Apache Software Foundation. All Rights Reserved."></property>
+
+ <property name="title" value="Graph 0.8.1 API"></property>
+
+ <javadoc use="true" private="true" destdir="${javadocdir}" author="true" version="true" sourcepath="src/java" packagenames="org.apache.commons.graph.*">
+ <classpath>
+ <fileset dir="lib">
+ <include name="*.jar"></include>
+ </fileset>
+ <pathelement location="target/${final.name}.jar"></pathelement>
+ </classpath>
+ </javadoc>
+
+ </target>
- <target name="maven:site">
- <ant antfile="${maven.home}/plugins/docs/build.xml" target="site"/>
- </target>
-
-
- <target name="maven:dist">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="dist"/>
- </target>
-
-
- <target name="maven:env">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="env"/>
- </target>
-
-
- <target name="maven:test">
- <ant antfile="${maven.home}/plugins/test/build.xml" target="test"/>
- </target>
-
-
- <target name="maven:announce">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="announce"/>
- </target>
-
-
- <target name="maven:activity-log">
- <ant antfile="${maven.home}/plugins/docs/build.xml" target="activity-log"/>
- </target>
-
-
- <target name="maven:compile">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="compile"/>
- </target>
-
-
- <target name="maven:validate-war">
- <ant antfile="${maven.home}/plugins/j2ee/build.xml" target="validate-war"/>
- </target>
-
-
- <target name="maven:pdf">
- <ant antfile="${maven.home}/plugins/docs/build.xml" target="pdf"/>
- </target>
-
-
- <target name="maven:iutest">
- <ant antfile="${maven.home}/plugins/iutest/build.xml" target="iutest"/>
- </target>
-
-
- <target name="maven:deploy-site">
- <ant antfile="${maven.home}/plugins/docs/build.xml" target="deploy-site"/>
- </target>
-
-
- <target name="maven:deploy-dist">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="deploy-dist"/>
- </target>
-
-
- <target name="maven:war">
- <ant antfile="${maven.home}/plugins/j2ee/build.xml" target="war"/>
- </target>
-
-
- <target name="maven:verify-project">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="verify-project"/>
- </target>
-
-
- <target name="maven:cvs-change-log">
- <ant antfile="${maven.home}/plugins/docs/build.xml" target="cvs-change-log"/>
- </target>
-
-
- <target name="maven:ear">
- <ant antfile="${maven.home}/plugins/j2ee/build.xml" target="ear"/>
- </target>
-
-
- <target name="maven:cross-ref">
- <ant antfile="${maven.home}/plugins/docs/build.xml" target="cross-ref"/>
- </target>
-
-
- <target name="maven:update-jars">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="update-jars"/>
- </target>
-
-
- <target name="maven:validate-pom">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="validate-pom"/>
- </target>
-
-
- <target name="maven:install-jar">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="install-jar"/>
- </target>
-
-
- <target name="maven:fo">
- <ant antfile="${maven.home}/plugins/docs/build.xml" target="fo"/>
- </target>
-
-
- <target name="maven:javadocs">
- <ant antfile="${maven.home}/plugins/docs/build.xml" target="javadocs"/>
- </target>
-
-
- <target name="maven:validate-struts-war">
- <ant antfile="${maven.home}/plugins/struts/build.xml" target="validate-struts-war"/>
- </target>
-
-
- <target name="maven:task-list">
- <ant antfile="${maven.home}/plugins/docs/build.xml" target="task-list"/>
- </target>
-
-
- <target name="maven:ejb">
- <ant antfile="${maven.home}/plugins/j2ee/build.xml" target="ejb"/>
- </target>
-
-
- <target name="maven:docs">
- <ant antfile="${maven.home}/plugins/docs/build.xml" target="docs"/>
- </target>
-
-
- <target name="maven:clean">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="clean"/>
- </target>
-
-
- <target name="maven:dist-build">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="dist-build"/>
- </target>
-
-
- <target name="maven:metrics">
- <ant antfile="${maven.home}/plugins/metrics/build.xml" target="metrics"/>
- </target>
-
-
- <target name="maven:docs-quick">
- <ant antfile="${maven.home}/plugins/docs/build.xml" target="docs-quick"/>
- </target>
-
-
- <target name="maven:run-singletest">
- <ant antfile="${maven.home}/plugins/test/build.xml" target="run-singletest"/>
- </target>
-
-
- <target name="maven:check-source">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="check-source"/>
- </target>
-
-
- <target name="maven:generate-reactor">
- <ant antfile="${maven.home}/plugins/reactor/build.xml" target="generate-reactor"/>
- </target>
-
-
- <target name="maven:jar">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="jar"/>
- </target>
-
-
- <target name="maven:maven-update">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="maven-update"/>
- </target>
+ <target name="get-deps" unless="noget" depends="init">
+
+
+ <get dest="lib/log4j-1.1.3.jar" usetimestamp="true" ignoreerrors="true" src="http://www.ibiblio.org/maven/log4j/jars/log4j-1.1.3.jar"></get>
+ <get dest="lib/jdepend-2.2.jar" usetimestamp="true" ignoreerrors="true" src="http://www.ibiblio.org/maven/jdepend/jars/jdepend-2.2.jar"></get>
+ <get dest="lib/nsuml-0.4.20.jar" usetimestamp="true" ignoreerrors="true" src="http://www.ibiblio.org/maven/nsuml/jars/nsuml-0.4.20.jar"></get>
+ <get dest="lib/commons-collections-2.1.jar" usetimestamp="true" ignoreerrors="true" src="http://www.ibiblio.org/maven/commons-collections/jars/commons-collections-2.1.jar"></get>
+ <get dest="lib/junit-3.8.1.jar" usetimestamp="true" ignoreerrors="true" src="http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar"></get>
+ <get dest="lib/xml-apis-1.0.b2.jar" usetimestamp="true" ignoreerrors="true" src="http://www.ibiblio.org/maven/xml-apis/jars/xml-apis-1.0.b2.jar"></get>
+
+ <get dest="lib/junit-3.8.1.jar" usetimestamp="true" ignoreerrors="true" src="http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar"></get>
+ <get dest="lib/ant-1.5.jar" usetimestamp="true" ignoreerrors="true" src="http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar"></get>
+ <get dest="lib/ant-optional-1.5.jar" usetimestamp="true" ignoreerrors="true" src="http://www.ibiblio.org/maven/ant/jars/ant-optional-1.5.jar"></get>
+ </target>
+
+
+
+
+
+
+
+
- <target name="maven:gump-descriptor">
- <ant antfile="${maven.home}/plugins/core/build.xml" target="gump-descriptor"/>
- </target>
+ <target name="install-maven">
+
- <!-- maven:end -->
+ <get dest="${user.home}/maven-install-latest.jar" usetimestamp="true" src="${maven.repo.remote}/maven/maven-install-latest.jar"></get>
+
+ <unjar dest="${maven.home}" src="${user.home}/maven-install-latest.jar"></unjar>
+
+ </target>
</project>
+
\ No newline at end of file
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by Sam Ruby <ru...@apache.org>.
Jason van Zyl wrote:
>
>>Someday, somebody may find a bug that they can not fix because the
>>source is no longer available/maintained. Perhaps an incompatibility
>>between this code and an upcoming version of a JDK...
>
> That is valid, so how about ensuring that that source is archived in
> places like ibiblio? They won't be going anywhere and will ensure access
> to sources at any time.
Megabytes of sources to abandonwhere that nobody knows how to maintain
is not the answer. Depending only on things that have an active
community, and working together with these communities is. The magic
that is Apache is not so much that we publish our sources, but that
there is a healthy and vibrant community that goes along with it.
Communities like maven.
>>Someday, somebody may want to use the commons graph component and some
>>other component, both of which depend on specific and incompatible
>>versions of nsuml. To put it politely, they would be screwed.
>
> They would not, not any more. This is why Bob made forehead and now
> classworlds. We were tired of these issues (primarily issues with
> Freebxml and Sun's SOAP libraries) so we now have a classloading
> mechanism that provides an arbitrarily constrained graph. What we are
> trying to make in Plexus is a container that adheres to Doug Schmidt's
> Component Configurator patter where the server cannot go down,
> dependencies may come in any form from anywhere and you need to be able
> to deal with clashes during runtime. These clashes will be unforseen but
> have to be dealt with easily and transparently. In summary the use
> aspectj and it's dynamic aspect loading capabilities (as of the 1.1
> compiler) and classworld will make this a reality.
Color me skeptical. My experience with such things is that 90% of the
time they make your life easy. The other 10% of the time they not only
make life more difficult, they make it impossible to debug.
Remember when Craig was trying to debug shipping Crimson with Tomcat 4
and allowing webapps to override this?
And I would shudder to think what would happen if half of your
application used one version of log4j, and another used a different version.
>>However, if you can have unit tests that check such things nightly, and
>>people take a moment to do things like proper deprecation, then these
>>efforts can be largely parallelized across the development community and
>>nearly made painless. If you see a gump failure on a project that
>>succeeded yesterday, then it usually is fairly easy to track down what
>>the culprit is as most people (ok, so you are a notable exception, but
>>bear with me) check in changes in a granular fashion. This means that
>>by selectively rolling back changes one can isolate the failing
>>component quickly.
>
> I'm am with you 100% in spirit.
That's all I can ask.
> Though you are well aware I'm not with
> 100% in implemenation.
I'm rooting for you. I'd love to see the implementation of Gump replaced.
- Sam Ruby
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by Jason van Zyl <ja...@zenplex.com>.
On Thu, 2003-01-02 at 10:46, Sam Ruby wrote:
> Jason van Zyl wrote:
> >
> > The graph code which is used in Maven works well. If graph2 was never
> > changed from this date forward it would still continue to work with
> > Maven. The nsuml may be considered obselete but the obselete package
> > serves its purpose in the graph2 and provides the required functionity,
> > why must we continually upgrade? Why must we continually incur costs of
> > maintenance to use the latest released version of things when it's not
> > required by the application code?
> >
> > I would be fine with a release of graph2 but what is really wrong with
> > it the way it is?
>
> Someday, somebody may find a bug that they can not fix because the
> source is no longer available/maintained. Perhaps an incompatibility
> between this code and an upcoming version of a JDK...
That is valid, so how about ensuring that that source is archived in
places like ibiblio? They won't be going anywhere and will ensure access
to sources at any time.
> Someday, somebody may want to use the commons graph component and some
> other component, both of which depend on specific and incompatible
> versions of nsuml. To put it politely, they would be screwed.
They would not, not any more. This is why Bob made forehead and now
classworlds. We were tired of these issues (primarily issues with
Freebxml and Sun's SOAP libraries) so we now have a classloading
mechanism that provides an arbitrarily constrained graph. What we are
trying to make in Plexus is a container that adheres to Doug Schmidt's
Component Configurator patter where the server cannot go down,
dependencies may come in any form from anywhere and you need to be able
to deal with clashes during runtime. These clashes will be unforseen but
have to be dealt with easily and transparently. In summary the use
aspectj and it's dynamic aspect loading capabilities (as of the 1.1
compiler) and classworld will make this a reality.
> This may seem like a hypothetical example, but...
>
> > What if a Jakarta project finds version 1.4.4 of xerces works just great
> > for them and things are peachy. Why do they have to expend time and
> > energy upgrading all the time? If it makes sense and there are new
> > features great but otherwise what is the benefit?
>
> ... this is a prime example. Many components depend on the additional
> functions or features of xerces 2, and one can't easily mix xerces 1 and
> xerces 2 in one's classpath.
You can with classworlds. I have not tried different xerces versions but
I have tried it with Ant and Grant. Blocking the AntClassLoader and
allowing the Grant substitute to replace it.
> > I understand that a release of graph2 is in order but all this hunting
> > around to get rid of what is considered obsolete doesn't seem to make
> > much sense to me.
>
> Just so it is clear... I am very much in awe of the individuals that can
> pull off the near-herculean efforts it takes to pull together a
> coherent, complete, and integrated release of a large system like
> turbine, avalon, or cocoon.
>
> However, if you can have unit tests that check such things nightly, and
> people take a moment to do things like proper deprecation, then these
> efforts can be largely parallelized across the development community and
> nearly made painless. If you see a gump failure on a project that
> succeeded yesterday, then it usually is fairly easy to track down what
> the culprit is as most people (ok, so you are a notable exception, but
> bear with me) check in changes in a granular fashion. This means that
> by selectively rolling back changes one can isolate the failing
> component quickly.
>
> This is in contrast to a length end-of-release system integration phase.
> Been there done that.
>
> Remember when stepping up to new releases of Ant was always an
> adventure? That's now largely a thing of the past. It still is true
> for the herculean projects I mentioned above. That's what I would like
> to see addressed. If not for yourselves, but for the people who depend
> on you.
I'm am with you 100% in spirit. Though you are well aware I'm not with
100% in implemenation. I'm in full agreement with the sentiment and a
good portion of all my efforts go toward achieving clarity in the
project in order to achieve coherence on a cross project level.
> Finally, I would like to point out that I am not proposing that
> everybody continuously upgrade the versions of dependencies that they
> are actively working with... maven's ability to download jars is cool.
> It is just that people should be aware of changes to components that
> they depend on that might affect them down the road.
Certainly. I agree.
> In other words, you should build with stable released versions. I will
> build with the latest. If you simply watch for and respond to gump
> failures in ways that allow a range of dependent versions to be used,
> then people who integrate with your software will have a wider range of
> choices available to them, and might actually be able to find a
> combination that works.
>
> - Sam Ruby
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by Sam Ruby <ru...@apache.org>.
Jason van Zyl wrote:
>
> The graph code which is used in Maven works well. If graph2 was never
> changed from this date forward it would still continue to work with
> Maven. The nsuml may be considered obselete but the obselete package
> serves its purpose in the graph2 and provides the required functionity,
> why must we continually upgrade? Why must we continually incur costs of
> maintenance to use the latest released version of things when it's not
> required by the application code?
>
> I would be fine with a release of graph2 but what is really wrong with
> it the way it is?
Someday, somebody may find a bug that they can not fix because the
source is no longer available/maintained. Perhaps an incompatibility
between this code and an upcoming version of a JDK...
Someday, somebody may want to use the commons graph component and some
other component, both of which depend on specific and incompatible
versions of nsuml. To put it politely, they would be screwed.
This may seem like a hypothetical example, but...
> What if a Jakarta project finds version 1.4.4 of xerces works just great
> for them and things are peachy. Why do they have to expend time and
> energy upgrading all the time? If it makes sense and there are new
> features great but otherwise what is the benefit?
... this is a prime example. Many components depend on the additional
functions or features of xerces 2, and one can't easily mix xerces 1 and
xerces 2 in one's classpath.
> I understand that a release of graph2 is in order but all this hunting
> around to get rid of what is considered obsolete doesn't seem to make
> much sense to me.
Just so it is clear... I am very much in awe of the individuals that can
pull off the near-herculean efforts it takes to pull together a
coherent, complete, and integrated release of a large system like
turbine, avalon, or cocoon.
However, if you can have unit tests that check such things nightly, and
people take a moment to do things like proper deprecation, then these
efforts can be largely parallelized across the development community and
nearly made painless. If you see a gump failure on a project that
succeeded yesterday, then it usually is fairly easy to track down what
the culprit is as most people (ok, so you are a notable exception, but
bear with me) check in changes in a granular fashion. This means that
by selectively rolling back changes one can isolate the failing
component quickly.
This is in contrast to a length end-of-release system integration phase.
Been there done that.
Remember when stepping up to new releases of Ant was always an
adventure? That's now largely a thing of the past. It still is true
for the herculean projects I mentioned above. That's what I would like
to see addressed. If not for yourselves, but for the people who depend
on you.
Finally, I would like to point out that I am not proposing that
everybody continuously upgrade the versions of dependencies that they
are actively working with... maven's ability to download jars is cool.
It is just that people should be aware of changes to components that
they depend on that might affect them down the road.
In other words, you should build with stable released versions. I will
build with the latest. If you simply watch for and respond to gump
failures in ways that allow a range of dependent versions to be used,
then people who integrate with your software will have a wider range of
choices available to them, and might actually be able to find a
combination that works.
- Sam Ruby
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by Jason van Zyl <ja...@zenplex.com>.
On Thu, 2003-01-02 at 09:34, Sam Ruby wrote:
> dion@apache.org wrote:
> > dion 2003/01/02 05:57:55
> >
> > Modified: graph2 build.xml
> > Log:
> > regenned
>
> Thanks!
>
> Now we get onto real compile errors. It appears that graph2 is based on
> nsuml 0.4.20, which is clearly described as obsolete on
> http://nsuml.sourceforge.net/
>
> To recap: maven's DependencyResolver depends on an unreleased sandbox
> component named graph2 which, in turn depends on an obsolete LGPL library.
>
> IMHO, as maven moves towards a release, either maven should consider
> severing its dependency on graph2, or graph2 should be upgraded,
> released, and maintained.
The graph code which is used in Maven works well. If graph2 was never
changed from this date forward it would still continue to work with
Maven. The nsuml may be considered obselete but the obselete package
serves its purpose in the graph2 and provides the required functionity,
why must we continually upgrade? Why must we continually incur costs of
maintenance to use the latest released version of things when it's not
required by the application code?
I would be fine with a release of graph2 but what is really wrong with
it the way it is?
A project may continue to evolve, it's application logic may change but
it could decide never to upgrade any of its dependencies. The project
would still thrive. I'm sure many commerical endeavours have done this
and done just fine.
What if a Jakarta project finds version 1.4.4 of xerces works just great
for them and things are peachy. Why do they have to expend time and
energy upgrading all the time? If it makes sense and there are new
features great but otherwise what is the benefit?
I understand that a release of graph2 is in order but all this hunting
around to get rid of what is considered obsolete doesn't seem to make
much sense to me.
> - Sam Ruby
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by di...@multitask.com.au.
Sam Ruby <ru...@intertwingly.net> wrote on 03/01/2003 10:02:23 AM:
> dion@multitask.com.au wrote:
> >><depend project="jakarta-ant" property="maven.jar.ant" id="ant"/>
> >
> > And.
> > <property name="maven.jar.ant" value="${gump's location of ant jar
file
> > - ${jarDir}/jakarta-ant/ant.jar???}" />
>
> That should not be required. Note the "property=" on the depend
> element. There even is an "id" which identifies which ant jar, to
> handle those cases where projects rename jars.
Cool. Ya learn something new every day.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by di...@multitask.com.au.
Sam Ruby <ru...@intertwingly.net> wrote on 03/01/2003 10:02:23 AM:
> dion@multitask.com.au wrote:
> >><depend project="jakarta-ant" property="maven.jar.ant" id="ant"/>
> >
> > And.
> > <property name="maven.jar.ant" value="${gump's location of ant jar
file
> > - ${jarDir}/jakarta-ant/ant.jar???}" />
>
> That should not be required. Note the "property=" on the depend
> element. There even is an "id" which identifies which ant jar, to
> handle those cases where projects rename jars.
Cool. Ya learn something new every day.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by Sam Ruby <ru...@intertwingly.net>.
dion@multitask.com.au wrote:
>><depend project="jakarta-ant" property="maven.jar.ant" id="ant"/>
>
> And.
> <property name="maven.jar.ant" value="${gump's location of ant jar file
> - ${jarDir}/jakarta-ant/ant.jar???}" />
That should not be required. Note the "property=" on the depend
element. There even is an "id" which identifies which ant jar, to
handle those cases where projects rename jars.
- Sam Ruby
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by Sam Ruby <ru...@intertwingly.net>.
dion@multitask.com.au wrote:
>><depend project="jakarta-ant" property="maven.jar.ant" id="ant"/>
>
> And.
> <property name="maven.jar.ant" value="${gump's location of ant jar file
> - ${jarDir}/jakarta-ant/ant.jar???}" />
That should not be required. Note the "property=" on the depend
element. There even is an "id" which identifies which ant jar, to
handle those cases where projects rename jars.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by di...@multitask.com.au.
Sam Ruby <ru...@intertwingly.net> wrote on 03/01/2003 04:52:40 AM:
> > The bootstrap build file is build-bootstrap.xml in the base directory
of
> > maven.
>
> <ant buildfile="build-gump.xml">
This one should be:
<ant buildfile="build-bootstrap.xml">
> > We'll need to pass the build file some properties:
> > #offline mode
> > maven.bootstrap.online=-o
>
> <property name="version" value="-o"/>
<property name="maven.bootstrap.online" value="-o"/>
> > maven.get.jars.baseUrl = http://www.ibiblio.org/maven
>
> Why?
We probably don't need it, as we're telling Maven we're offline, I just
wasn't sure.
[snip other goodies]
> > maven.jar.override=true
> > and then maven.jar.xxx for each of mavens dependencies:
> >
> > dom4j, ant, ant-optional, commons-beanutils, commons-betwixt,
commons-cli,
> > commons-collections, commons-digester, commons-grant, commons-graph,
> > commons-io, commons-jelly, commons-jexl, commons-lang,
commons-logging,
> > commons-util, forehead, jdepend, logkit, log4j, piccolo, velocity,
werkz,
> > which, xml-apis, xerces.
>
> <depend project="dom4j" property="maven.jar.dom4j">
> <depend project="jakarta-ant" property="maven.jar.ant" id="ant"/>
And.
<property name="maven.jar.override" value="true" />
<property name="maven.jar.ant" value="${gump's location of ant jar file
- ${jarDir}/jakarta-ant/ant.jar???}" />
otherwise Maven will try to download the ant jar from ibiblio.
> I can take this one. Can you see what you can do to get jelly built?
Yep, I think Morgan is doing a test on a single taglib to see if he can
get it going. I'll help.
Thanks,
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by di...@multitask.com.au.
Sam Ruby <ru...@intertwingly.net> wrote on 03/01/2003 04:52:40 AM:
> > The bootstrap build file is build-bootstrap.xml in the base directory
of
> > maven.
>
> <ant buildfile="build-gump.xml">
This one should be:
<ant buildfile="build-bootstrap.xml">
> > We'll need to pass the build file some properties:
> > #offline mode
> > maven.bootstrap.online=-o
>
> <property name="version" value="-o"/>
<property name="maven.bootstrap.online" value="-o"/>
> > maven.get.jars.baseUrl = http://www.ibiblio.org/maven
>
> Why?
We probably don't need it, as we're telling Maven we're offline, I just
wasn't sure.
[snip other goodies]
> > maven.jar.override=true
> > and then maven.jar.xxx for each of mavens dependencies:
> >
> > dom4j, ant, ant-optional, commons-beanutils, commons-betwixt,
commons-cli,
> > commons-collections, commons-digester, commons-grant, commons-graph,
> > commons-io, commons-jelly, commons-jexl, commons-lang,
commons-logging,
> > commons-util, forehead, jdepend, logkit, log4j, piccolo, velocity,
werkz,
> > which, xml-apis, xerces.
>
> <depend project="dom4j" property="maven.jar.dom4j">
> <depend project="jakarta-ant" property="maven.jar.ant" id="ant"/>
And.
<property name="maven.jar.override" value="true" />
<property name="maven.jar.ant" value="${gump's location of ant jar file
- ${jarDir}/jakarta-ant/ant.jar???}" />
otherwise Maven will try to download the ant jar from ibiblio.
> I can take this one. Can you see what you can do to get jelly built?
Yep, I think Morgan is doing a test on a single taglib to see if he can
get it going. I'll help.
Thanks,
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by Sam Ruby <ru...@intertwingly.net>.
dion@multitask.com.au wrote:
>>parallel is good. How can I help?
>
> We'll need a descriptor for maven-bootstrap that depends on ant (and jaxp
> under < jdk14).
Easy enough:
<project name="maven-bootstrap">
<depend project="jakarta-ant" inherit="runtime"/>
<depend project="xml-xerces"/>
</project
> The bootstrap build file is build-bootstrap.xml in the base directory of
> maven.
<ant buildfile="build-gump.xml">
> We'll need to pass the build file some properties:
> #offline mode
> maven.bootstrap.online=-o
<property name="version" value="-o"/>
> maven.get.jars.baseUrl = http://www.ibiblio.org/maven
Why?
> maven.bootstrap.dir = ${basedir}/bootstrap
> maven.bootstrap.classes = ${maven.bootstrap.dir}/bootstrap-classes
> maven.bootstrap.phase1.classes = ${maven.bootstrap.dir}/phase1-classes
> maven.bootstrap.install.dir = ${maven.bootstrap.dir}/install-phase1
> maven.home=${maven.bootstrap.dir}/maven.home
> maven.local.repo=${maven.bootstrap.dir}/maven.local.repo
<property name="maven.bootstrap.dir" path="bootstrap"/>
(etc.)
> maven.jar.override=true
> and then maven.jar.xxx for each of mavens dependencies:
>
> dom4j, ant, ant-optional, commons-beanutils, commons-betwixt, commons-cli,
> commons-collections, commons-digester, commons-grant, commons-graph,
> commons-io, commons-jelly, commons-jexl, commons-lang, commons-logging,
> commons-util, forehead, jdepend, logkit, log4j, piccolo, velocity, werkz,
> which, xml-apis, xerces.
<depend project="dom4j" property="maven.jar.dom4j">
<depend project="jakarta-ant" property="maven.jar.ant" id="ant"/>
(etc.)
> Some of these are *not* compile time deps, but run-time deps.
>
> That should build maven into the ${maven.home} directory using whatever
> jars we give it, I think :)
I can take this one. Can you see what you can do to get jelly built?
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by Sam Ruby <ru...@intertwingly.net>.
dion@multitask.com.au wrote:
>>parallel is good. How can I help?
>
> We'll need a descriptor for maven-bootstrap that depends on ant (and jaxp
> under < jdk14).
Easy enough:
<project name="maven-bootstrap">
<depend project="jakarta-ant" inherit="runtime"/>
<depend project="xml-xerces"/>
</project
> The bootstrap build file is build-bootstrap.xml in the base directory of
> maven.
<ant buildfile="build-gump.xml">
> We'll need to pass the build file some properties:
> #offline mode
> maven.bootstrap.online=-o
<property name="version" value="-o"/>
> maven.get.jars.baseUrl = http://www.ibiblio.org/maven
Why?
> maven.bootstrap.dir = ${basedir}/bootstrap
> maven.bootstrap.classes = ${maven.bootstrap.dir}/bootstrap-classes
> maven.bootstrap.phase1.classes = ${maven.bootstrap.dir}/phase1-classes
> maven.bootstrap.install.dir = ${maven.bootstrap.dir}/install-phase1
> maven.home=${maven.bootstrap.dir}/maven.home
> maven.local.repo=${maven.bootstrap.dir}/maven.local.repo
<property name="maven.bootstrap.dir" path="bootstrap"/>
(etc.)
> maven.jar.override=true
> and then maven.jar.xxx for each of mavens dependencies:
>
> dom4j, ant, ant-optional, commons-beanutils, commons-betwixt, commons-cli,
> commons-collections, commons-digester, commons-grant, commons-graph,
> commons-io, commons-jelly, commons-jexl, commons-lang, commons-logging,
> commons-util, forehead, jdepend, logkit, log4j, piccolo, velocity, werkz,
> which, xml-apis, xerces.
<depend project="dom4j" property="maven.jar.dom4j">
<depend project="jakarta-ant" property="maven.jar.ant" id="ant"/>
(etc.)
> Some of these are *not* compile time deps, but run-time deps.
>
> That should build maven into the ${maven.home} directory using whatever
> jars we give it, I think :)
I can take this one. Can you see what you can do to get jelly built?
- Sam Ruby
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by di...@multitask.com.au.
news <ne...@main.gmane.org> wrote on 03/01/2003 02:49:59 AM:
> dion@multitask.com.au wrote:
> >
> > I was hoping to get to this before you, but given I'm still running
the
> > 'update all' from gump\work (and have for the last 10-11 hrs), it'll
have
> > to wait :)
>
> You should be able to reproduce this without gump.
I could, but I'm trying to learn how to use Gump.
> > I could also hack about the bootstrap task in maven so that we can
> > override the location of the jars for the classpath, or will gump (by
> > specifying build.sysclasspath=only) override any classpath
> > references/elements in the build file?
>
> the classpath elements will be overriden.
Cool.
> > If that's the case, rather than trying to build all of maven, lets get
a
> > parallel stream running where we can bootstrap it too.
>
> parallel is good. How can I help?
We'll need a descriptor for maven-bootstrap that depends on ant (and jaxp
under < jdk14).
The bootstrap build file is build-bootstrap.xml in the base directory of
maven.
We'll need to pass the build file some properties:
#offline mode
maven.bootstrap.online=-o
maven.get.jars.baseUrl = http://www.ibiblio.org/maven
maven.bootstrap.dir = ${basedir}/bootstrap
maven.bootstrap.classes = ${maven.bootstrap.dir}/bootstrap-classes
maven.bootstrap.phase1.classes = ${maven.bootstrap.dir}/phase1-classes
maven.bootstrap.install.dir = ${maven.bootstrap.dir}/install-phase1
maven.home=${maven.bootstrap.dir}/maven.home
maven.local.repo=${maven.bootstrap.dir}/maven.local.repo
maven.jar.override=true
and then maven.jar.xxx for each of mavens dependencies:
dom4j, ant, ant-optional, commons-beanutils, commons-betwixt, commons-cli,
commons-collections, commons-digester, commons-grant, commons-graph,
commons-io, commons-jelly, commons-jexl, commons-lang, commons-logging,
commons-util, forehead, jdepend, logkit, log4j, piccolo, velocity, werkz,
which, xml-apis, xerces.
Some of these are *not* compile time deps, but run-time deps.
That should build maven into the ${maven.home} directory using whatever
jars we give it, I think :)
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by di...@multitask.com.au.
news <ne...@main.gmane.org> wrote on 03/01/2003 02:49:59 AM:
> dion@multitask.com.au wrote:
> >
> > I was hoping to get to this before you, but given I'm still running
the
> > 'update all' from gump\work (and have for the last 10-11 hrs), it'll
have
> > to wait :)
>
> You should be able to reproduce this without gump.
I could, but I'm trying to learn how to use Gump.
> > I could also hack about the bootstrap task in maven so that we can
> > override the location of the jars for the classpath, or will gump (by
> > specifying build.sysclasspath=only) override any classpath
> > references/elements in the build file?
>
> the classpath elements will be overriden.
Cool.
> > If that's the case, rather than trying to build all of maven, lets get
a
> > parallel stream running where we can bootstrap it too.
>
> parallel is good. How can I help?
We'll need a descriptor for maven-bootstrap that depends on ant (and jaxp
under < jdk14).
The bootstrap build file is build-bootstrap.xml in the base directory of
maven.
We'll need to pass the build file some properties:
#offline mode
maven.bootstrap.online=-o
maven.get.jars.baseUrl = http://www.ibiblio.org/maven
maven.bootstrap.dir = ${basedir}/bootstrap
maven.bootstrap.classes = ${maven.bootstrap.dir}/bootstrap-classes
maven.bootstrap.phase1.classes = ${maven.bootstrap.dir}/phase1-classes
maven.bootstrap.install.dir = ${maven.bootstrap.dir}/install-phase1
maven.home=${maven.bootstrap.dir}/maven.home
maven.local.repo=${maven.bootstrap.dir}/maven.local.repo
maven.jar.override=true
and then maven.jar.xxx for each of mavens dependencies:
dom4j, ant, ant-optional, commons-beanutils, commons-betwixt, commons-cli,
commons-collections, commons-digester, commons-grant, commons-graph,
commons-io, commons-jelly, commons-jexl, commons-lang, commons-logging,
commons-util, forehead, jdepend, logkit, log4j, piccolo, velocity, werkz,
which, xml-apis, xerces.
Some of these are *not* compile time deps, but run-time deps.
That should build maven into the ${maven.home} directory using whatever
jars we give it, I think :)
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by Sam Ruby <ru...@apache.org>.
dion@multitask.com.au wrote:
>
> I was hoping to get to this before you, but given I'm still running the
> 'update all' from gump\work (and have for the last 10-11 hrs), it'll have
> to wait :)
You should be able to reproduce this without gump.
> I could also hack about the bootstrap task in maven so that we can
> override the location of the jars for the classpath, or will gump (by
> specifying build.sysclasspath=only) override any classpath
> references/elements in the build file?
the classpath elements will be overriden.
> If that's the case, rather than trying to build all of maven, lets get a
> parallel stream running where we can bootstrap it too.
parallel is good. How can I help?
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by di...@multitask.com.au.
news <ne...@main.gmane.org> wrote on 03/01/2003 01:34:17 AM:
> dion@apache.org wrote:
> > dion 2003/01/02 05:57:55
> >
> > Modified: graph2 build.xml
> > Log:
> > regenned
>
> Thanks!
>
> Now we get onto real compile errors. It appears that graph2 is based on
> nsuml 0.4.20, which is clearly described as obsolete on
> http://nsuml.sourceforge.net/
>
> To recap: maven's DependencyResolver depends on an unreleased sandbox
> component named graph2 which, in turn depends on an obsolete LGPL
library.
>
> IMHO, as maven moves towards a release, either maven should consider
> severing its dependency on graph2, or graph2 should be upgraded,
> released, and maintained.
Unless it's a big deal moving from 0.4.2 to 1_4, I'll see if I can help
the move along.
I'd rather upgrade graph2 at this point.
I was hoping to get to this before you, but given I'm still running the
'update all' from gump\work (and have for the last 10-11 hrs), it'll have
to wait :)
Now about bootstrapping Maven.
The bootstrap task in Maven currently downloads it's dependencies if it's
in 'online' mode.
I could also hack about the bootstrap task in maven so that we can
override the location of the jars for the classpath, or will gump (by
specifying build.sysclasspath=only) override any classpath
references/elements in the build file?
If that's the case, rather than trying to build all of maven, lets get a
parallel stream running where we can bootstrap it too.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by Sam Ruby <ru...@apache.org>.
dion@apache.org wrote:
> dion 2003/01/02 05:57:55
>
> Modified: graph2 build.xml
> Log:
> regenned
Thanks!
Now we get onto real compile errors. It appears that graph2 is based on
nsuml 0.4.20, which is clearly described as obsolete on
http://nsuml.sourceforge.net/
To recap: maven's DependencyResolver depends on an unreleased sandbox
component named graph2 which, in turn depends on an obsolete LGPL library.
IMHO, as maven moves towards a release, either maven should consider
severing its dependency on graph2, or graph2 should be upgraded,
released, and maintained.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-commons-sandbox/graph2 build.xml
Posted by Sam Ruby <ru...@apache.org>.
dion@apache.org wrote:
> dion 2003/01/02 05:57:55
>
> Modified: graph2 build.xml
> Log:
> regenned
Thanks!
Now we get onto real compile errors. It appears that graph2 is based on
nsuml 0.4.20, which is clearly described as obsolete on
http://nsuml.sourceforge.net/
To recap: maven's DependencyResolver depends on an unreleased sandbox
component named graph2 which, in turn depends on an obsolete LGPL library.
IMHO, as maven moves towards a release, either maven should consider
severing its dependency on graph2, or graph2 should be upgraded,
released, and maintained.
- Sam Ruby