You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Johan Sjöberg <jo...@avaintec.com> on 2002/09/29 12:46:19 UTC
Placement of external libs/programs
Hi!
What would be the best place for external tools in the Phoenix dir
structure? Now we have most of the stuff in directories under ./lib.
mx4j is in the root (./) directory and ./tools is almost empty.
I'm asking because I have been testing the Inno-setup tool that
Nicola-Ken suggested and I'm trying to get it working nicely with the
build system.
If this tool (or some other similar), or actually the setup compiler
would be included where should it be put? The same goes for the Wrapper
if that can be included at some point too.
//
Johan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Ulrich Mayring <ul...@denic.de>.
Peter Donald wrote:
> On Wed, 2 Oct 2002 21:42, Johan Sjöberg wrote:
>
>>Anyone using the wrapper on Linux or Solaris with Phoenix? Any good/bad
>>reasons why or why not to include this at the same time as Win32?
>
> I use it on RH (and derived) linuxen and it works great there.
We're using it on RH Linux (development) and Solaris (production). What
was the question again? :)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Placement of external libs/programs
Posted by Peter Donald <pe...@apache.org>.
On Wed, 2 Oct 2002 21:42, Johan Sjöberg wrote:
> Personally I would like
>
> bin/lib
> bin/lib/native/win32
> bin/lib/native/linux... (could be i386, PPC etc)
> bin/lib/native/solaris
works for me.
> and so on, for cases like this. That would be close to what Leif
> suggested but still not messing up the container's lib dir. And yes, it
> should be just some small conf changes to get it working. I'll try to
> fix myself some time to test this.
kool.
> Anyone using the wrapper on Linux or Solaris with Phoenix? Any good/bad
> reasons why or why not to include this at the same time as Win32?
I use it on RH (and derived) linuxen and it works great there.
--
Cheers,
Peter Donald
'Most men would rather die than think. Many do.'
Bertrand Russell
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Johan Sjöberg <jo...@avaintec.com>.
Peter Donald wrote:
>
>>OK, the wrapper is part of the server, but not needed by the rest of it.
>>All files are now in ./bin, but as Leif pointed out this is not so clean.
>
>
> We could probably move the jars into bin/lib, native files into
> bin/native/win32/ or bin/native/linux/ or whatever - I presume it is just
> modifying configuration files to get that going.
Personally I would like
bin/lib
bin/lib/native/win32
bin/lib/native/linux... (could be i386, PPC etc)
bin/lib/native/solaris
and so on, for cases like this. That would be close to what Leif
suggested but still not messing up the container's lib dir. And yes, it
should be just some small conf changes to get it working. I'll try to
fix myself some time to test this.
Anyone using the wrapper on Linux or Solaris with Phoenix? Any good/bad
reasons why or why not to include this at the same time as Win32?
//
J
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 17:18, Johan Sjöberg wrote:
> > Any reliable/stable jars/products should not be stored in CVS but are
> > downloaded from their download site. MX4J is already downloaded. We
> > should be downloading Wrapper and requiring it for our build but no ones
> > got around to that yet.
>
> No prob, just some simple ant tasks for the wrapper.
kool.
> > For things that are only used in building the product we should place
> > them in tools/ subdirectory.
>
> E.g. the setup compiler in this case. There is a small problem though.
> At least with inno-setup. It is distributed as a windows setup EXE so it
> can't be downloaded and extracted. I think that at least the
> command-line compiler, some DLLs and the english language files would
> have to be included in CVS for this to run really smoothly.
>
> OK, I know, if it is installed on _the_ windows build machine its dir
> could be included in ant.properties. BUT, that would make building a
> full dist even more cumbersome than now... this is probably the way to
> start though.
yep.
> > If the jars are part of the server then they should be
> > placed in the lib/container directory. If the jars are used by hosted
> > applications aswell as the container they should be put in lib/
> > directory.
>
> OK, the wrapper is part of the server, but not needed by the rest of it.
> All files are now in ./bin, but as Leif pointed out this is not so clean.
We could probably move the jars into bin/lib, native files into
bin/native/win32/ or bin/native/linux/ or whatever - I presume it is just
modifying configuration files to get that going.
--
Cheers,
Peter Donald
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Johan Sjöberg <jo...@avaintec.com>.
Peter Donald wrote:
>
>>I'm asking because I have been testing the Inno-setup tool that
>>Nicola-Ken suggested and I'm trying to get it working nicely with the
>>build system.
>
>
> kool.
It seems to work fairly well, but I have some minor issues with it
still... I'll get back when it is ready for testing, if at all possible.
I'm not rushing with this at all, as the whole point with it is to make
installing and maintaing Phoenix easier. Especially for new people.
>>If this tool (or some other similar), or actually the setup compiler
>>would be included where should it be put? The same goes for the Wrapper
>>if that can be included at some point too.
>
>
> The way I would like to see it laid out is as follows.
>
> Any reliable/stable jars/products should not be stored in CVS but are
> downloaded from their download site. MX4J is already downloaded. We should be
> downloading Wrapper and requiring it for our build but no ones got around to
> that yet.
No prob, just some simple ant tasks for the wrapper.
> For things that are only used in building the product we should place them in
> tools/ subdirectory.
E.g. the setup compiler in this case. There is a small problem though.
At least with inno-setup. It is distributed as a windows setup EXE so it
can't be downloaded and extracted. I think that at least the
command-line compiler, some DLLs and the english language files would
have to be included in CVS for this to run really smoothly.
OK, I know, if it is installed on _the_ windows build machine its dir
could be included in ant.properties. BUT, that would make building a
full dist even more cumbersome than now... this is probably the way to
start though.
> If the jars are part of the server then they should be
> placed in the lib/container directory. If the jars are used by hosted
> applications aswell as the container they should be put in lib/ directory.
OK, the wrapper is part of the server, but not needed by the rest of it.
All files are now in ./bin, but as Leif pointed out this is not so clean.
//
Johan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Peter Donald <pe...@apache.org>.
On Sun, 29 Sep 2002 20:46, Johan Sjöberg wrote:
> What would be the best place for external tools in the Phoenix dir
> structure? Now we have most of the stuff in directories under ./lib.
> mx4j is in the root (./) directory and ./tools is almost empty.
>
> I'm asking because I have been testing the Inno-setup tool that
> Nicola-Ken suggested and I'm trying to get it working nicely with the
> build system.
kool.
> If this tool (or some other similar), or actually the setup compiler
> would be included where should it be put? The same goes for the Wrapper
> if that can be included at some point too.
The way I would like to see it laid out is as follows.
Any reliable/stable jars/products should not be stored in CVS but are
downloaded from their download site. MX4J is already downloaded. We should be
downloading Wrapper and requiring it for our build but no ones got around to
that yet.
For things that are only used in building the product we should place them in
tools/ subdirectory. If the jars are part of the server then they should be
placed in the lib/container directory. If the jars are used by hosted
applications aswell as the container they should be put in lib/ directory.
XDoclet is in a separate directory altogether as it has been less stable than
anything else and we need a way to easily upgrade it (Though it looks like
QDox may be a candidate for replacing xdoclet).
--
Cheers,
Peter Donald
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ant.jar in distribution
Posted by Mauro Talevi <ma...@aquilonia.org>.
Peter Donald wrote:
>I would prefer to not add it in. However what i will try to do over next
>little bit is add in a warning if it is not on classpath. If you want to send
>a patch for the build file it will get done quicker ;)
>
>
I've tried to test for the availability of ant by say
<available property="ant.present" classname="org.apache.tools.ant.Task"/>
but - oddly - the property ant.present is comes out always set to true,
even when ant.jar is not in the classpath.
But if it's not the compilation fails. So maybe it's a question of how
the IDE deals internally with ant.
In any case, it's not a big issue. If there are reasons not to add
ant.jar to the libs, I'll simply copy ant.jar
to the lib dir and that solves it.
Cheers, Mauro
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ant.jar in distribution
Posted by Peter Donald <pe...@apache.org>.
On Sun, 27 Oct 2002 04:15, Mauro Talevi wrote:
> would it be possible to add the ant.jar to the lib directory in the src
> distribution?
> The reason being that - while it all works fine when building from
> command line
> (since ant.jar is automatically added to the local classpath in the ant
> script) -
> it fails to compile when using an IDE-embedded ant executor
> (specifically I use Netbeans
> but I suppose similar problems are encountered with other IDEs).
I would prefer to not add it in. However what i will try to do over next
little bit is add in a warning if it is not on classpath. If you want to send
a patch for the build file it will get done quicker ;)
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "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 *
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
ant.jar in distribution
Posted by Mauro Talevi <ma...@aquilonia.org>.
Hi,
would it be possible to add the ant.jar to the lib directory in the src
distribution?
The reason being that - while it all works fine when building from
command line
(since ant.jar is automatically added to the local classpath in the ant
script) -
it fails to compile when using an IDE-embedded ant executor
(specifically I use Netbeans
but I suppose similar problems are encountered with other IDEs).
One could argue that any class that is imported in the java code
(eg org.apache.tools.ant.BuildException in
org.apache.avalon.phoenix.tools.metagenerate.MetaGenerateTask)
should have the corresponding lib in the project lib dir and be included
in the classpath.
This problem only occurs when defining ant tasks but still it would be
very useful.
I've noticed that avalon-framework does have the ant.jar in lib while
excalibur does not
(and again one has problems when building, eg AltRMI).
BTW, phoenix-metagenerate.jar in Cornerstone/lib needs to be replaced
with the latest version
with the name changed to MetaGenerateTask.
Cheers, Mauro
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Oct 2002 17:45, Johan Sjöberg wrote:
> How about
>
> ../X for really large toolkits
>
> ./tools/X
> or
> ./download/X
+1 for ./download/X
--
Cheers,
Peter Donald
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Johan Sjöberg <jo...@avaintec.com>.
Peter Donald wrote:
>
>
> I don't think we have a "standard" for where things are downloaded to. We
> could download it to ./tools/X or ./X or even ../X - not sure. "../X" would
> be better if they are large toolkits.
Would you mind agreeing on a standard way then? Or a supposed std way?
I don't like ./X as mx4j is downloaded now. It makes the structure even
bigger than now. I see the point in ../X for large toolkits as you don't
have to download them again if you do a clean checkout. This also
results in new directories among your other projects, which I personally
dislike, but I can live that.
How about
../X for really large toolkits
./tools/X
or
./download/X
for smaller (normal) ones?
>><little off-topic>
>>You did a good job creating the wrapper. It works surprisingly well.
>></little off-topic>
>
>
> Yep it is great. At the time I found out about it it was leaps and bounds
> above everything else (and I had looked).
I know ;) I have hit my head against some of those _else_.
//
J
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Peter Donald <pe...@apache.org>.
On Sun, 29 Sep 2002 22:24, Johan Sjöberg wrote:
> If it can't be included in CVS for some reason (size?)
It probably could be but I would be very hesitent to do that. A lot of people
who run the infrastructure of Apache (both legal and physical) object to it
for fairly good reasons. That was the main reason MX4J was moved out of our
CVS.
> an ant download task could be
> added, but still the placement for tools like this is unclear to me. If
> it would be included in all distributions I guess ./lib and ./bin would
> be OK, but as this is not the case...
I don't think we have a "standard" for where things are downloaded to. We
could download it to ./tools/X or ./X or even ../X - not sure. "../X" would
be better if they are large toolkits.
> <little off-topic>
> You did a good job creating the wrapper. It works surprisingly well.
> </little off-topic>
Yep it is great. At the time I found out about it it was leaps and bounds
above everything else (and I had looked).
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Religion is what the common people see as true, the |
| wise people see as false, and the rulers see as |
| useful" --Seneca |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Johan Sjöberg wrote:
> This could be a good solution for the wrapper. It would be good to
> have version information somewhere too. Would committers remember to
> update a README file when updating the libraries? The filenames would
> be another solution. Btw. why aren't the latest wrapper versions
> released for solaris? Sorry if it is in the docs, I was lazy and
> didn't check.
I lost my access to a Solaris machine when switching jobs :-/ Have
tried getting the SF compile
farm set up to do builds, but it would require installing a 1.3 JDK on
their servers which I didn't
have much success at. If anyone out there would like to help out with
Solaris builds, I would be
happy add solaris releases again.
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Johan Sjöberg <jo...@avaintec.com>.
Hi!
Leif Mortenson wrote:
>
> We did this for an inhouse project by creating native subdirectories
> which were checked into cvs.
> lib/
> lib/native/
> lib/native/linix
> lib/native/solaris
> lib/native/win32
> Doing that made it possible to build all of the distributions on any
> platform without having to collect
> lots of files.
This could be a good solution for the wrapper. It would be good to have
version information somewhere too. Would committers remember to update a
README file when updating the libraries? The filenames would be another
solution. Btw. why aren't the latest wrapper versions released for
solaris? Sorry if it is in the docs, I was lazy and didn't check.
> It may be desirable to include Wrapper docs to help people with
> configuration? Pointing them to the wrapper.sourceforge.net URL
> would probably be good enough though.
Linking form the documentation would not create much extra work, I like.
The situation is a little bit different for the win-setup compiler I'm
testing. I put it under ./tools for now.
//
J
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Johan Sjöberg wrote:
> Leif Mortenson wrote:
>
>>
>> Currently, the location of Wrapper files in Phoenix is a little
>> strange. The wrapper.jar and Wrapper.DLL/libwrapper.so files are
>> currently located in the {phoenix.home}/bin directory along with the
>> binary files. This clutters things up a bit IMO.
>>
>> A better way, which is actually the default for a Wrapper install.
>> Would be to place the wrapper.jar and Wrapper.DLL/libwrapper.so files
>> into a {phoenix.home}/lib directory. That would make it easier to
>> get using running
>> with the Wrapper is it fits with the Wrapper docs.
>
>
> True, but before building the distribution the Wrapper files have to
> be somewhere so they can be copied to their right locations. Now we
> have wrapper.home set in ant.properties. If the wrapper would be
> included in the dist wrapper.home should to be somewhere under the cvs
> structure for simplicity. ./tools/wrapper, ./lib/wrapper or
> something. If it can't be included in CVS for some reason (size?) an
> ant download task could be added, but still the placement for tools
> like this is unclear to me. If it would be included in all
> distributions I guess ./lib and ./bin would be OK, but as this is not
> the case...
We did this for an inhouse project by creating native subdirectories
which were checked into cvs.
lib/
lib/native/
lib/native/linix
lib/native/solaris
lib/native/win32
Doing that made it possible to build all of the distributions on any
platform without having to collect
lots of files.
Each one is actually quite small. 12xkb for Win32 and 8xkb for unix
versions and the whole distribution is
not required. The wrapper.jar file is also the same across all
versions. It may be desirable to include
Wrapper docs to help people with configuration? Pointing them to the
wrapper.sourceforge.net URL
would probably be good enough though.
> <little off-topic>
> You did a good job creating the wrapper. It works surprisingly well.
> </little off-topic>
Thanks, appreciate that.
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Johan Sjöberg <jo...@avaintec.com>.
Leif Mortenson wrote:
>
> Currently, the location of Wrapper files in Phoenix is a little strange.
> The wrapper.jar and Wrapper.DLL/libwrapper.so files are currently
> located in the {phoenix.home}/bin directory along with the binary files.
> This clutters things up a bit IMO.
>
> A better way, which is actually the default for a Wrapper install. Would
> be to place the wrapper.jar and Wrapper.DLL/libwrapper.so files into a
> {phoenix.home}/lib directory. That would make it easier to get using
> running
> with the Wrapper is it fits with the Wrapper docs.
True, but before building the distribution the Wrapper files have to be
somewhere so they can be copied to their right locations. Now we have
wrapper.home set in ant.properties. If the wrapper would be included in
the dist wrapper.home should to be somewhere under the cvs structure for
simplicity. ./tools/wrapper, ./lib/wrapper or something. If it can't be
included in CVS for some reason (size?) an ant download task could be
added, but still the placement for tools like this is unclear to me. If
it would be included in all distributions I guess ./lib and ./bin would
be OK, but as this is not the case...
You're right about the libs in ./bin. This can be fixed at the same time.
<little off-topic>
You did a good job creating the wrapper. It works surprisingly well.
</little off-topic>
Sunday cheers,
//
Johan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Placement of external libs/programs
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Johan Sjöberg wrote:
> Hi!
>
> What would be the best place for external tools in the Phoenix dir
> structure? Now we have most of the stuff in directories under ./lib.
> mx4j is in the root (./) directory and ./tools is almost empty.
>
> I'm asking because I have been testing the Inno-setup tool that
> Nicola-Ken suggested and I'm trying to get it working nicely with the
> build system.
>
> If this tool (or some other similar), or actually the setup compiler
> would be included where should it be put? The same goes for the
> Wrapper if that can be included at some point too.
Currently, the location of Wrapper files in Phoenix is a little strange.
The wrapper.jar and Wrapper.DLL/libwrapper.so files are currently
located in the {phoenix.home}/bin directory along with the binary files.
This clutters things up a bit IMO.
A better way, which is actually the default for a Wrapper install.
Would be to place the wrapper.jar and Wrapper.DLL/libwrapper.so files
into a {phoenix.home}/lib directory. That would make it easier to get
using running
with the Wrapper is it fits with the Wrapper docs.
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>