You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Colm McCartan <co...@owl.co.uk> on 2002/01/08 15:46:02 UTC
Building jakarta-turbine-2
Hello all,
Can't quite figure this out from archives or docs in CVS. Given that I'm
getting nowhere fast with postgres and the fact that I will have to
trace problems down into the torque/peers source I am trying to build
the tdk jar from CVS. Questions:
- Is 2.2 the right thing to do or am I better sticking to trying to
build 2.1, given that I'm deploying to postgres on linux (I'm getting
lots of little build problems with this. I would also like to be able to
contribute any fixes I can find and I assume it is best to this to 2.2?
- How is this built? Using the build.xml in the base directory from CVS
there are problems caused by the lack of the servlet.jar in lib. Also, I
notice that while checks are made for optional packages like Castor this
does appear to be done for webmacro - even with the webmacro jar in
place I am getting screeds of compile errors. Should I be using dist.sh?
The build.xml under build? Is the source totally independent of 2.1?
I would really appreciate any responses as I have been bashing my head
against postgres since before Xmas.
colm
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Building jakarta-turbine-2 (& postgres issues)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Colm McCartan <co...@owl.co.uk> writes:
> Daniel Rall wrote:
>
>> http://nagoya.apache.org/
>
> Zarroo bugs found for turbine... (how nice to have no bugs, eh?)
<http://nagoya.apache.org/bugzilla/buglist.cgi?email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=turbine&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Building jakarta-turbine-2 (& postgres issues)
Posted by Colm McCartan <co...@owl.co.uk>.
Daniel Rall wrote:
> Colm McCartan <co...@owl.co.uk> writes:
>>I am interested in being able to drop debug code into the source, step
>>through it at debug time etc. Is the standalone torque, as it
>>suggests, totally seperate from turbine?
>
> Yes, completely (!).
I think I'll have to wait until 2.2 then. I'd spend more time trying to
get it to work with the TDK than I would debugging my webapp I suspect...
> If you end up working with the stand-alone repositories for Torque
> and/or Fulcrum, you may find my lib.repo useful. Hunting down all the
> necessary JARs can be time-consuming.
>
> http://finemaltcoding.com/~dlr/lib.repo.tar.gz
Cheers for that...
>>Again I'd like to help - I have ended up manually generating the db. I
>>wasn't even sure if this was a known issue. Is there a public bug db
>>for turbine anywhere?
>>
>
> http://nagoya.apache.org/
Zarroo bugs found for turbine... (how nice to have no bugs, eh?)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Building jakarta-turbine-2 (& postgres issues)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Colm McCartan <co...@owl.co.uk> writes:
> I am interested in being able to drop debug code into the source, step
> through it at debug time etc. Is the standalone torque, as it
> suggests, totally seperate from turbine?
Yes, completely (!).
> I'd be delighted to submit patches if I can get anywhere near it
> working.. It may be, of course, that I have confused the build process
> somewhere.
If you end up working with the stand-alone repositories for Torque
and/or Fulcrum, you may find my lib.repo useful. Hunting down all the
necessary JARs can be time-consuming.
http://finemaltcoding.com/~dlr/lib.repo.tar.gz
> Again I'd like to help - I have ended up manually generating the db. I
> wasn't even sure if this was a known issue. Is there a public bug db
> for turbine anywhere?
http://nagoya.apache.org/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Building jakarta-turbine-2 (& postgres issues)
Posted by Colm McCartan <co...@owl.co.uk>.
John McNally wrote:
> Colm McCartan wrote:
>
>>John McNally wrote:
>>
>>
>>>I would recommend the head of 2.x tree over 2.1, but better yet try
>>>using the code in the standalone torque repo. And there is no need to
>>>have webmacro for torque, are you using it for your application screens?
>>>
>>The standalone torque repo - excuse my ignorance but does this include a
>>full version of turbine? How does it differ from the turbine-2 repo?
>>
>>I am not using webmacro at all - I went through and binned a lot of the
>>webmacro-related files in places like turbine/modules/actions. Also
>>python stuff etc. Perhaps I messed up the inital build which I know
>>should detect which optional jars are present - but am I right in
>>thinking that it doesn't do this test for webmacro?
>>
>
> How about trying the unofficial tdk distribution that Martin just
> posted. I do not use the tdk, so I cannot be much help with its
> processes.
I am interested in being able to drop debug code into the source, step
through it at debug time etc. Is the standalone torque, as it suggests,
totally seperate from turbine?
Does anyone else have positive experiences from using postgres with 2.x?
> I do not have postgresql working, but I thought jason (and likely
> others) test the tdk against it, so I do not understand how they would
> not work. But patches are welcome.
I'd be delighted to submit patches if I can get anywhere near it
working.. It may be, of course, that I have confused the build process
somewhere.
>>In a previous post I also mentioned the bad foreign key references that
>>are generated when an alias to the turbine_user table is specified in
>>the torque schema.
>
> i have not had time to fix this and i keep hoping to come up with
> something better than the current not very impressive hack. If you have
> a fix, please share it.
Again I'd like to help - I have ended up manually generating the db. I
wasn't even sure if this was a known issue. Is there a public bug db for
turbine anywhere?
Thanks a lot for the response,
colm
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Building jakarta-turbine-2 (& postgres issues)
Posted by John McNally <jm...@collab.net>.
Colm McCartan wrote:
>
> John McNally wrote:
>
> > I would recommend the head of 2.x tree over 2.1, but better yet try
> > using the code in the standalone torque repo. And there is no need to
> > have webmacro for torque, are you using it for your application screens?
>
> The standalone torque repo - excuse my ignorance but does this include a
> full version of turbine? How does it differ from the turbine-2 repo?
>
> I am not using webmacro at all - I went through and binned a lot of the
> webmacro-related files in places like turbine/modules/actions. Also
> python stuff etc. Perhaps I messed up the inital build which I know
> should detect which optional jars are present - but am I right in
> thinking that it doesn't do this test for webmacro?
How about trying the unofficial tdk distribution that Martin just
posted. I do not use the tdk, so I cannot be much help with its
processes.
>
> Also John - did you happen to notice my mail about postgres stuff
> yesterday? I seem to be running up against a lot of small build errors
> for postgres. For instance, as well as the missing torque templates,
> the unix.vm template is not properly populated with a user parameter
> when calling createdb and dropdb.
I do not have postgresql working, but I thought jason (and likely
others) test the tdk against it, so I do not understand how they would
not work. But patches are welcome.
>
> In a previous post I also mentioned the bad foreign key references that
> are generated when an alias to the turbine_user table is specified in
> the torque schema.
>
i have not had time to fix this and i keep hoping to come up with
something better than the current not very impressive hack. If you have
a fix, please share it.
> In connection with a previous poster mistakenly capitalising idbroker in
> their torque schema, it is worth noting that it is shown capitalised in
> the example at the top of:
>
> http://jakarta.apache.org/turbine/turbine-2/howto/torque-schema-ref.html
>
fixed in cvs, so whenever the docs get regenerated it will show up.
thanks.
john mcnally
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Building jakarta-turbine-2 (& postgres issues)
Posted by Colm McCartan <co...@owl.co.uk>.
John McNally wrote:
> I would recommend the head of 2.x tree over 2.1, but better yet try
> using the code in the standalone torque repo. And there is no need to
> have webmacro for torque, are you using it for your application screens?
The standalone torque repo - excuse my ignorance but does this include a
full version of turbine? How does it differ from the turbine-2 repo?
I am not using webmacro at all - I went through and binned a lot of the
webmacro-related files in places like turbine/modules/actions. Also
python stuff etc. Perhaps I messed up the inital build which I know
should detect which optional jars are present - but am I right in
thinking that it doesn't do this test for webmacro?
Also John - did you happen to notice my mail about postgres stuff
yesterday? I seem to be running up against a lot of small build errors
for postgres. For instance, as well as the missing torque templates,
the unix.vm template is not properly populated with a user parameter
when calling createdb and dropdb.
In a previous post I also mentioned the bad foreign key references that
are generated when an alias to the turbine_user table is specified in
the torque schema.
In connection with a previous poster mistakenly capitalising idbroker in
their torque schema, it is worth noting that it is shown capitalised in
the example at the top of:
http://jakarta.apache.org/turbine/turbine-2/howto/torque-schema-ref.html
Cheers,
colm
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Building jakarta-turbine-2
Posted by John McNally <jm...@collab.net>.
I would recommend the head of 2.x tree over 2.1, but better yet try
using the code in the standalone torque repo. And there is no need to
have webmacro for torque, are you using it for your application screens?
john mcnally
Colm McCartan wrote:
>
> Hello all,
>
> Can't quite figure this out from archives or docs in CVS. Given that I'm
> getting nowhere fast with postgres and the fact that I will have to
> trace problems down into the torque/peers source I am trying to build
> the tdk jar from CVS. Questions:
>
> - Is 2.2 the right thing to do or am I better sticking to trying to
> build 2.1, given that I'm deploying to postgres on linux (I'm getting
> lots of little build problems with this. I would also like to be able to
> contribute any fixes I can find and I assume it is best to this to 2.2?
>
> - How is this built? Using the build.xml in the base directory from CVS
> there are problems caused by the lack of the servlet.jar in lib. Also, I
> notice that while checks are made for optional packages like Castor this
> does appear to be done for webmacro - even with the webmacro jar in
> place I am getting screeds of compile errors. Should I be using dist.sh?
> The build.xml under build? Is the source totally independent of 2.1?
>
> I would really appreciate any responses as I have been bashing my head
> against postgres since before Xmas.
>
> colm
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>