You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Seth Landsman <se...@boondock.cs.brandeis.edu> on 2001/03/25 17:56:51 UTC
Composite tasks and symlinks?
Greets,
So for the past month or so I've been slowly moving the build system
of my research framework from a gross set of make, perl, sed, awk and shell
into ant. Right now, all new functionality is going in as ant, being
called from the master Makefile.
The requirements of the build system are pretty extensive, as
I'm unable to assume any sort of similarity across systems. Required jar
files might be missing, might not be installed in the same locations,
etc. Unfortunately, it isn't an option to distribute the jar files with
the system, and I don't want to overwrite existing jar files.
So, I wrote this task to (a) search for existing jar files, (b)
download them if they don't exist, (c) set up a symlink farm pointing to
all the various jars and (d) set a property to point to the jar.
The problem is that this is four distinct tasks. I could do this
via a set of tasks and do parameters via properties, but that seems like a hack
(and I'm trying to de-hack-ify my existing build system at this point).
In the ant-dev mail archives, I see a short discussion about
an <aliasdef> tag or composite <taskdef> tags, but no apparent resolution.
Has this feature been implemented? Given the ongoing Ant 2.0 discussion,
would a patch like this be interesting?
Also, an aside question. Is there a decent way to make a unix symlink
via ant? I wonder if there is a demand for a set of unix-ish tasks? They
won't be cross platform (meaning unix -> windows), but some people might not
care.
-Seth
Re: Composite tasks and symlinks?
Posted by David Rees <d....@usa.net>.
On Mon, 26 Mar 2001 10:35:58 -0500, Seth Landsman wrote:
>On Mon, Mar 26, 2001 at 11:51:54PM +1000, Peter Donald wrote:
>> At 08:07 26/3/01 -0500, Seth Landsman wrote:
>> >> > (BTW, I've been thinking about a CJAN-like system for a while. I'd
>> >> >be interested in working on such a system.)
>> >>
>> >> excellent - it sounds like you are volunteering ? ;)
>> >
>> > Definitely. It sounds like an interesting project. Is this still
>> >blue-sky-ish, or has actual work / discussion happened (and where)?
>>
>> discussion has happened. Unfortunately it is distributed across a number of
>> projects (Commons, Ant and probably Alexandria). It was originally
>> suggested by Jon Stevens in december or so - which should be in the
>> archives (Sorry can't be more specific). No actual work has occured as I
>> think everyone has been waiting on ant2 (or at least I know I have).
>
> D'oh. I'll look through the archives. Is there a reason it isn't
>an actual project off of apache.org (or jakarta.apache.org) yet?
>
>> The technical aspects should be doable - the only limitation that as yet no
>> one has mentioned is the legal constraints. Under CJAN it would presumably
>> required that a master list and perhaps a complete directory of products be
>> stored. Some products may not be copyright apache, some may be GPL etc. The
>> problem is one of control and bandwidth. Someone could publish "unsafe"
>> code in cjan (ie crypto or decss type code) and we have to be able to shut
>> behaviour like that as soon as possible. However we also don't want to be
>> trying to police cjan too much. In the end it will be up to the PMC (or
>> perhaps Apache members/board) whether they are willing to take this risk
>> and provide the bandwidth or if it needs to be hosted elsewhere.
>
> I see two easy, non-ideal options.
>
>1. A package (unless it has an exception) needs to sit in the incoming
> queue for n (n = 24?) hours before it gets listed publically.
> Therefore, the queue managers can step in before it gets published.
>
> Known good authors could be given an exception. This
> exception happens by signing the upload package with a GPG
> key.
>
>2. A package needs to be moved by a queue manager out of the incoming
> directory.
>
>(1), I think, is the best deal.
>
What about a "trust" system? Then bad links can be happily sitting
there for those who trust that submitter, but are ignored by those who
are more particular? Perhaps with an auto-trust for the original
submitter/owner of a particular library once someone has chosen to use
that library?
d
Regarding Junit fork
Posted by balaSubramanian <ba...@lucid.co.in>.
Hi
iam trying to use the optional task of ant named "junit"
I want to run the junit task in separate vm ,so i gave
fork="yes" .But iam getting error as follows
Error Message
------------------
[Image]
Snippet code
--------------
<target name="test" depends="dist">
<junit printsummary="yes" fork="yes" >
<classpath>
<pathelement location="${jarfile}"/>
<pathelement path="${java.class.path}"/>
</classpath>
<formatter type="plain"/>
<test name="com.myproject.server.UDPListenerTestSuite"
outfile="${results}"
/>
</junit>
</target>
Expecting reply from u in this regard
Thx
Bala
CJAN (was Re: Composite tasks and symlinks?)
Posted by Ringo De Smet <ri...@yahoo.co.uk>.
--- Seth Landsman <se...@boondock.cs.brandeis.edu> wrote:
> On Mon, Mar 26, 2001 at 11:51:54PM +1000, Peter Donald wrote:
> > The technical aspects should be doable - the only limitation
> that as yet no
> > one has mentioned is the legal constraints. Under CJAN it
> would presumably
> > required that a master list and perhaps a complete directory
> of products be
> > stored. Some products may not be copyright apache, some may
> be GPL etc. The
> > problem is one of control and bandwidth. Someone could
> publish "unsafe"
> > code in cjan (ie crypto or decss type code) and we have to
> be able to shut
> > behaviour like that as soon as possible. However we also
> don't want to be
> > trying to police cjan too much. In the end it will be up to
> the PMC (or
> > perhaps Apache members/board) whether they are willing to
> take this risk
> > and provide the bandwidth or if it needs to be hosted
> elsewhere.
>
> I see two easy, non-ideal options.
>
> 1. A package (unless it has an exception) needs to sit in the
> incoming
> queue for n (n = 24?) hours before it gets listed publically.
> Therefore, the queue managers can step in before it gets
> published.
>
> Known good authors could be given an exception. This
> exception happens by signing the upload package with a GPG
> key.
Maybe a good starting point for defining a package system or
CJAN as well as a maintainers policy is to look at the Debian
package and Debian developer guides. I know that Debian depends
a lot on Perl, but functionality wise, this is what I would like
to have in Java. Together with the alternatives system in
Debian, I can have many versions of a package on my system
without any trouble. The Debian dpkg ant apt tools have always
worked for me, while RedHat's RPM has fucked up my Linux system
more than one time. However, I stopped working with Redhat about
two years ago, so these quircks could have been resolved
already.
Ringo
=====
Ringo De Smet
Email @ home: Ringo.DeSmet@bigfoot.com
Email @ work: Ringo.DeSmet.atwork@bigfoot.com
____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
Re: Composite tasks and symlinks?
Posted by Seth Landsman <se...@boondock.cs.brandeis.edu>.
On Mon, Mar 26, 2001 at 11:51:54PM +1000, Peter Donald wrote:
> At 08:07 26/3/01 -0500, Seth Landsman wrote:
> >> > (BTW, I've been thinking about a CJAN-like system for a while. I'd
> >> >be interested in working on such a system.)
> >>
> >> excellent - it sounds like you are volunteering ? ;)
> >
> > Definitely. It sounds like an interesting project. Is this still
> >blue-sky-ish, or has actual work / discussion happened (and where)?
>
> discussion has happened. Unfortunately it is distributed across a number of
> projects (Commons, Ant and probably Alexandria). It was originally
> suggested by Jon Stevens in december or so - which should be in the
> archives (Sorry can't be more specific). No actual work has occured as I
> think everyone has been waiting on ant2 (or at least I know I have).
D'oh. I'll look through the archives. Is there a reason it isn't
an actual project off of apache.org (or jakarta.apache.org) yet?
> The technical aspects should be doable - the only limitation that as yet no
> one has mentioned is the legal constraints. Under CJAN it would presumably
> required that a master list and perhaps a complete directory of products be
> stored. Some products may not be copyright apache, some may be GPL etc. The
> problem is one of control and bandwidth. Someone could publish "unsafe"
> code in cjan (ie crypto or decss type code) and we have to be able to shut
> behaviour like that as soon as possible. However we also don't want to be
> trying to police cjan too much. In the end it will be up to the PMC (or
> perhaps Apache members/board) whether they are willing to take this risk
> and provide the bandwidth or if it needs to be hosted elsewhere.
I see two easy, non-ideal options.
1. A package (unless it has an exception) needs to sit in the incoming
queue for n (n = 24?) hours before it gets listed publically.
Therefore, the queue managers can step in before it gets published.
Known good authors could be given an exception. This
exception happens by signing the upload package with a GPG
key.
2. A package needs to be moved by a queue manager out of the incoming
directory.
(1), I think, is the best deal.
> > An http header should have a last-editted header, or something
> >like that, right? Ideally, you should be able to determine whether or
> >not you need to redownload without actually downloading the jar file.
> >The <GET> task supports this via usetimestamp.
> > Looking forward to CJAN, there needs to be information that can
> >be gathered without downloading the whole jar (especially if the jar is big).
> >Perhaps an XML document that is associated with the jar can be downloaded
> >and inspected first.
>
> A nice XML product descriptor would be good that listed things like
> dependencies, description, version, authout, source etc. I looked at a few
> things (RPMs/elisp packages being main focus) and there is a rough
> conformity in what each describes. We would just have to
> amalgamate/collect/think of a good way to describe it all ;)
Right.
> >> > I wonder if there should be a seperate package for unix-specific
> >> >tasks? org.apache.ant.task.unix.symlink, for example.
> >>
> >> in ant2 - yep - however now to keep backwards compatability we are lumping
> >> them altogether ;)
> >
> > Okay. This one just needs some commenting and a license thrown on.
> >I'll send a patch to bugzilla for this (in the task., not task.unix package).
Ideally, ant1 tasks should work with ant2, regardless of what ant2
looks like. Has that been discussed / dismissed?
-Seth
Re: Composite tasks and symlinks?
Posted by Peter Donald <do...@apache.org>.
At 08:07 26/3/01 -0500, Seth Landsman wrote:
>> > (BTW, I've been thinking about a CJAN-like system for a while. I'd
>> >be interested in working on such a system.)
>>
>> excellent - it sounds like you are volunteering ? ;)
>
> Definitely. It sounds like an interesting project. Is this still
>blue-sky-ish, or has actual work / discussion happened (and where)?
discussion has happened. Unfortunately it is distributed across a number of
projects (Commons, Ant and probably Alexandria). It was originally
suggested by Jon Stevens in december or so - which should be in the
archives (Sorry can't be more specific). No actual work has occured as I
think everyone has been waiting on ant2 (or at least I know I have).
The technical aspects should be doable - the only limitation that as yet no
one has mentioned is the legal constraints. Under CJAN it would presumably
required that a master list and perhaps a complete directory of products be
stored. Some products may not be copyright apache, some may be GPL etc. The
problem is one of control and bandwidth. Someone could publish "unsafe"
code in cjan (ie crypto or decss type code) and we have to be able to shut
behaviour like that as soon as possible. However we also don't want to be
trying to police cjan too much. In the end it will be up to the PMC (or
perhaps Apache members/board) whether they are willing to take this risk
and provide the bandwidth or if it needs to be hosted elsewhere.
> An http header should have a last-editted header, or something
>like that, right? Ideally, you should be able to determine whether or
>not you need to redownload without actually downloading the jar file.
>The <GET> task supports this via usetimestamp.
> Looking forward to CJAN, there needs to be information that can
>be gathered without downloading the whole jar (especially if the jar is big).
>Perhaps an XML document that is associated with the jar can be downloaded
>and inspected first.
A nice XML product descriptor would be good that listed things like
dependencies, description, version, authout, source etc. I looked at a few
things (RPMs/elisp packages being main focus) and there is a rough
conformity in what each describes. We would just have to
amalgamate/collect/think of a good way to describe it all ;)
>> > I wonder if there should be a seperate package for unix-specific
>> >tasks? org.apache.ant.task.unix.symlink, for example.
>>
>> in ant2 - yep - however now to keep backwards compatability we are lumping
>> them altogether ;)
>
> Okay. This one just needs some commenting and a license thrown on.
>I'll send a patch to bugzilla for this (in the task., not task.unix package).
kewl ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Composite tasks and symlinks?
Posted by Seth Landsman <se...@boondock.cs.brandeis.edu>.
> > (BTW, I've been thinking about a CJAN-like system for a while. I'd
> >be interested in working on such a system.)
>
> excellent - it sounds like you are volunteering ? ;)
Definitely. It sounds like an interesting project. Is this still
blue-sky-ish, or has actual work / discussion happened (and where)?
> > project-wide and workspace-wide looks useful to me. My framework
> >could be considered a workspace, with the user inheriting some specific
> >settings based on the fact that they are using the framework.
>
> yep - thats what I would like to see. Hopefully we can wait till ant2.0 is
> a little closer to reality we will see if ant supports that better ;)
Okay. I need to follow the dev list more closely to see what is
happening with 2.0.
>
> > Right. I need to figure out how to do an up-to-date check for
> >downloading my jars.
>
> I was thinking about doing it in one of two ways. With a specific naming
> pattern. ie
>
> name-version.jar (where version included major, minor and patchlevel).
> ant-1.2.1.jar
>
> or alternatively by looking at manifest entries of jar files.
An http header should have a last-editted header, or something
like that, right? Ideally, you should be able to determine whether or
not you need to redownload without actually downloading the jar file.
The <GET> task supports this via usetimestamp.
Looking forward to CJAN, there needs to be information that can
be gathered without downloading the whole jar (especially if the jar is big).
Perhaps an XML document that is associated with the jar can be downloaded
and inspected first.
> > I'll give it a shot. What types of core changes are going into
> >ant2? I haven't seen a document specifying that. Or is that still under
> >discussion?
>
> Still under discussion - it will largely be a complete rewrite so anything
> and everything is possible ;)
Okay. I need to pay more attention in -dev and probably get involved
a little more once a tasklist is decided upon.
> > I wonder if there should be a seperate package for unix-specific
> >tasks? org.apache.ant.task.unix.symlink, for example.
>
> in ant2 - yep - however now to keep backwards compatability we are lumping
> them altogether ;)
Okay. This one just needs some commenting and a license thrown on.
I'll send a patch to bugzilla for this (in the task., not task.unix package).
-Seth
Re: Composite tasks and symlinks?
Posted by Peter Donald <do...@apache.org>.
At 12:27 25/3/01 -0500, Seth Landsman wrote:
> Well, in an ideal setting I wouldn't have to. However, I still
>need to integrate with my existing build system. Also, the symlink farm
>lets me point to specific versions, without having the user need to worry
>about it.
ahh okay.
> (BTW, I've been thinking about a CJAN-like system for a while. I'd
>be interested in working on such a system.)
excellent - it sounds like you are volunteering ? ;)
> project-wide and workspace-wide looks useful to me. My framework
>could be considered a workspace, with the user inheriting some specific
>settings based on the fact that they are using the framework.
yep - thats what I would like to see. Hopefully we can wait till ant2.0 is
a little closer to reality we will see if ant supports that better ;)
> Right. I need to figure out how to do an up-to-date check for
>downloading my jars.
I was thinking about doing it in one of two ways. With a specific naming
pattern. ie
name-version.jar (where version included major, minor and patchlevel).
ant-1.2.1.jar
or alternatively by looking at manifest entries of jar files.
> Okay. I need to give it some clean up, but I'll post the file later
>on.
kewl ;)
> I'll give it a shot. What types of core changes are going into
>ant2? I haven't seen a document specifying that. Or is that still under
>discussion?
Still under discussion - it will largely be a complete rewrite so anything
and everything is possible ;)
> I wonder if there should be a seperate package for unix-specific
>tasks? org.apache.ant.task.unix.symlink, for example.
in ant2 - yep - however now to keep backwards compatability we are lumping
them altogether ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Composite tasks and symlinks?
Posted by Seth Landsman <se...@boondock.cs.brandeis.edu>.
On Mon, Mar 26, 2001 at 02:36:53AM +1000, Peter Donald wrote:
> At 10:56 25/3/01 -0500, Seth Landsman wrote:
> > So, I wrote this task to (a) search for existing jar files, (b)
> >download them if they don't exist, (c) set up a symlink farm pointing to
> >all the various jars and (d) set a property to point to the jar.
>
> Sounds kewl - very similar to some tasks that were talked about for CJAN
> (Complete Java Archive Network). One question though - why do you need
> stage (c) when you have (4).
Well, in an ideal setting I wouldn't have to. However, I still
need to integrate with my existing build system. Also, the symlink farm
lets me point to specific versions, without having the user need to worry
about it.
(BTW, I've been thinking about a CJAN-like system for a while. I'd
be interested in working on such a system.)
> The cjan task I was thinking about was essentially
>
> <cjan-get library="mycategory/mylib" version="1.2.3"/>
> <cjan-locate library="mycategory/mylib" property="mylib.jar" />
>
> So this would check current jar for mylib and make sure it was of correct
> version etc. The search for the jar would go
>
> * system-wide jar repository
> * user-wide jar repository
> * workspace-wide jar repository
> * project-wide jar repository
>
> The system-wide and user-wide repositories would usually be system specific
> (ie /usr/local/java on debian/linux, /WinNT/jars on winNT etc). Workspace
> is something I was kicking around ideas for but couldn't come up with a
> good answer while project-wide is self explanatory ;)
project-wide and workspace-wide looks useful to me. My framework
could be considered a workspace, with the user inheriting some specific
settings based on the fact that they are using the framework.
> If the check failed (ie wasn't up to date or was missing) a new jar would
> be downloaded and placed in project-wide repository (or alternatively
> another if indicated my task attribute).
Right. I need to figure out how to do an up-to-date check for
downloading my jars.
> The lookup and download of components could have been
> centralized/decentralized depending on how we decide to implement CJAN.
>
> Eventually I would like to see something like
>
> <javac ....>
> ...
> <library name="mycategory/mylib" version="1.2.3"/>
> ...
> </javac>
>
> However I think that is some time away ;)
This makes sense to me.
> I would like to have a look at your task as it is. It would definetly fill
> needs I have seen ;)
Okay. I need to give it some clean up, but I'll post the file later
on.
> > In the ant-dev mail archives, I see a short discussion about
> >an <aliasdef> tag or composite <taskdef> tags, but no apparent resolution.
> >Has this feature been implemented? Given the ongoing Ant 2.0 discussion,
> >would a patch like this be interesting?
>
> It hasn't been implemented and we aren't really sure how we are going to
> implement it. We don't really want to change too much of the 1.1 semantics
> at the moment in case the changes do not survive in ant2.x. However if it
> was done in an good way ... ;)
I'll give it a shot. What types of core changes are going into
ant2? I haven't seen a document specifying that. Or is that still under
discussion?
> > Also, an aside question. Is there a decent way to make a unix symlink
> >via ant? I wonder if there is a demand for a set of unix-ish tasks? They
> >won't be cross platform (meaning unix -> windows), but some people might not
> >care.
>
> we already have chmod/chgrp tasks so another symlink won't hurt. Until then
> though it may be useful to instead use <exec />
I wonder if there should be a seperate package for unix-specific
tasks? org.apache.ant.task.unix.symlink, for example.
I think a symlink task makes more sense than using <exec>, it'll
allow us to specify arguments and better deal with failures.
-Seth
Re: Composite tasks and symlinks?
Posted by Peter Donald <do...@apache.org>.
At 10:56 25/3/01 -0500, Seth Landsman wrote:
> So, I wrote this task to (a) search for existing jar files, (b)
>download them if they don't exist, (c) set up a symlink farm pointing to
>all the various jars and (d) set a property to point to the jar.
Sounds kewl - very similar to some tasks that were talked about for CJAN
(Complete Java Archive Network). One question though - why do you need
stage (c) when you have (4).
The cjan task I was thinking about was essentially
<cjan-get library="mycategory/mylib" version="1.2.3"/>
<cjan-locate library="mycategory/mylib" property="mylib.jar" />
So this would check current jar for mylib and make sure it was of correct
version etc. The search for the jar would go
* system-wide jar repository
* user-wide jar repository
* workspace-wide jar repository
* project-wide jar repository
The system-wide and user-wide repositories would usually be system specific
(ie /usr/local/java on debian/linux, /WinNT/jars on winNT etc). Workspace
is something I was kicking around ideas for but couldn't come up with a
good answer while project-wide is self explanatory ;)
If the check failed (ie wasn't up to date or was missing) a new jar would
be downloaded and placed in project-wide repository (or alternatively
another if indicated my task attribute).
The lookup and download of components could have been
centralized/decentralized depending on how we decide to implement CJAN.
Eventually I would like to see something like
<javac ....>
...
<library name="mycategory/mylib" version="1.2.3"/>
...
</javac>
However I think that is some time away ;)
I would like to have a look at your task as it is. It would definetly fill
needs I have seen ;)
> In the ant-dev mail archives, I see a short discussion about
>an <aliasdef> tag or composite <taskdef> tags, but no apparent resolution.
>Has this feature been implemented? Given the ongoing Ant 2.0 discussion,
>would a patch like this be interesting?
It hasn't been implemented and we aren't really sure how we are going to
implement it. We don't really want to change too much of the 1.1 semantics
at the moment in case the changes do not survive in ant2.x. However if it
was done in an good way ... ;)
> Also, an aside question. Is there a decent way to make a unix symlink
>via ant? I wonder if there is a demand for a set of unix-ish tasks? They
>won't be cross platform (meaning unix -> windows), but some people might not
>care.
we already have chmod/chgrp tasks so another symlink won't hurt. Until then
though it may be useful to instead use <exec />
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*