You are viewing a plain text version of this content. The canonical link for it is here.
Posted to alexandria-dev@jakarta.apache.org by Sam Ruby <ru...@us.ibm.com> on 2000/12/30 15:10:02 UTC

Re: build.classpath and tinderbox builds

Jeff Martin wrote:
>
> There's actually quite a significant overlap in functionality
> between Sam's code and the work that I've added to Alexandria
> which now supports the reporting of build and JUnit testing.
> In fact I've suffered from the very same classpath issues,
> but I've just been forking of java tasks to do the builds of
> other projects. I suspect that they working in very similar
> ways (XSLT).

Alexandria would seem to be a good home for this function.

I can't seem to checkout Alexandria at the moment.  For details on the
error, take a look at
http://oss.software.ibm.com/developerworks/opensource/jakarta/proto/cvs_alexandria.html.

 I've reported this on the alexandria-dev mailing list on the 20th of
December, but have yet to hear a reply.  Furthermore, when I click on the
"Use Alexandria" link, I get an Object not found at
http://java.apache.org/alexandria/.

Even if the code (yes, it is 100% XSLT) I wrote proves to be of little
value, I suspect that the workspace definition will be reusable in some
form.  One thing I am pleased with in my implementation that I would like
to see live on is the ordering of the individual project builds based on
their declared dependencies.  I've also used that dependency information to
produce a cross reference of projects.

With a little change I recently made to Ant, the classpath issues are all
resolved to my satisfaction.

> For those that are interested I'm just working on updated
> documentation for the web site. Hopefully I'll have it
> done in a week or so.

Let's explore further the possibility of combining our efforts at that time
on the alexandria-dev mailing list.

- Sam Ruby


Re: build.classpath and tinderbox builds

Posted by Jeff Martin <jm...@silacom.com>.
>
> I can't seem to checkout Alexandria at the moment.  For details on the
> error, take a look at
>
http://oss.software.ibm.com/developerworks/opensource/jakarta/proto/cvs_alex
andria.html.
>
Think I've sussed it. Are you running thing in a Windows box. I got the same
problem trying to checking things out on a Win98 box. It's because of the
name of the directory cvs which on an win box gets confused with the CVS
directory which causes cvs to throw a wobbly.

Anyway I've removed the files in those directories as there autogenerated
during the build so I don't think they should really be in cvs anyway.

>  I've reported this on the alexandria-dev mailing list on the 20th of
> December, but have yet to hear a reply.  Furthermore, when I click on the
> "Use Alexandria" link, I get an Object not found at
> http://java.apache.org/alexandria/.
>

Not sure what the score is with this one. I think it's Kevins box. It's
running quite an old version of Alexandria. What I'd really like is
something setup to do a nightly Alexandria run at least on the Alexandria
source code.

> Even if the code (yes, it is 100% XSLT) I wrote proves to be of little
> value, I suspect that the workspace definition will be reusable in some
> form.  One thing I am pleased with in my implementation that I would like
> to see live on is the ordering of the individual project builds based on
> their declared dependencies.  I've also used that dependency information
to
> produce a cross reference of projects.
>

Think this is going to be one of the problems with XSL, poor reusability.
Can't really reused code apart from cutting and pasting sections. I like the
idea of the dependacies, it is something that has crossed my mind before but
i could think of a way to do it (at least not a nice way)

> With a little change I recently made to Ant, the classpath issues are all
> resolved to my satisfaction.
>

Cool, looks like I'll have to start using the dev version of Ant again.

>
> > For those that are interested I'm just working on updated
> > documentation for the web site. Hopefully I'll have it
> > done in a week or so.
>
> Let's explore further the possibility of combining our efforts at that
time
> on the alexandria-dev mailing list.
>
> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: alexandria-dev-unsubscribe@java.apache.org
> For additional commands, e-mail: alexandria-dev-help@java.apache.org
>