You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <pa...@yahoo.com> on 2001/05/13 19:33:00 UTC
jakarta-avalon-phoenix-bin.jar self-installable
A bit late now for additional functionaility?
If jakarta-avalon-phoenix-bin.jar (which does not yet exist) were executable, it could
1a) extract itself to jakarta-avalon-phoenix-bin (in the current) dir
1b) extract itself to a -d specified parameter
2) if -f (force) were specified, could overwrite the contents of that dir instead of issue an
error
I know this only saves one use of "jar -xf jakarta-avalon-phoenix-bin.jar" after a mkdir, but it
would be quite neat. Especially when re-used by projects that are Avalon dependant, to ship
avalon/phoenix with one or more sar files pre-installed. Yes, I know the idea is to drop sars
into the apps dir of a pre-installed Avalon, but until Avalon gets the recognition that say Ant
and Tomcat have, it's going to be a hard time convincing people that they need to download two
things to test a fancy product (as well as a convoluted instruction list).
To take it one stage further.. the installer (after installation) could invoke engine.Main to
kickoff Avalon-phoenix. To goal being that the jar would be double click installable/runnable for
the armchair heros of this world.
Anyway, I have half written it (a clone of Main), but figure it may be unpopular, so am seeking
opinion.
Thoughts?
Regards,
- Paul H
____________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: build status and documentation
Posted by Peter Donald <do...@apache.org>.
At 11:33 14/5/01 +0200, Stephen McConnell wrote:
>
>Now that the build files are updated (thanks Pete for taking care of
>the updates). It is now possible to build any Avalon distribution
>from another ant build file using something like the following:
>
> <ant dir="${avalon.path}" target="dist"/>
>
>or, for phoenix:
>
> <ant dir="${phoenix.path}" target="dist"/>
>
>etc.
>
>While this is a dramatic improvement over the usual open-source
>build processes - there is still room for improvement with respect
>to the generated documentation. Under the current build processes
>here are several documentation inconsistencies on the source of
>local versus remote URL - some pages are local while others
>link to http://jakarta.apache.org/avalon/...
>
>After looking through the src/xdocs sources, the problem appears to be
>linked to the fact that the docs contain cross package references
>whereas the build process is package independent. This creates further
>complications when looking at the generated javadoc - for example, the
>javadoc for Phoenix does not integrate references to Avalon.
>
>What I would like to suggest is that we modify the javadoc targets such
>they builds differently depending on the available "dist" packages.
>For example, if an Avalon "dist" is available, the Phoenix javadoc should
>link to a relative local Avalon doc location.
>
>Thoughts ?
+1
A while ago I had this going though I am not sure what happenend to it - I
think it was with the other commits I lost ;( Anyways in build files we
usually have something like
<filter token="AVALON_BASE" value="http://jakarta.apache.org/avalon"/>
<filter token="FRAMEWORK_BASE"
value="http://jakarta.apache.org/avalon/framework"/>
<filter token="PHOENIX_BASE"
value="http://jakarta.apache.org/avalon/phoenix"/>
<filter token="CORNERSTONE_BASE"
value="http://jakarta.apache.org/avalon/cornerstone"/>
<filter token="LOGKIT_BASE" value="http://jakarta.apache.org/avalon/logkit"/>
<filter token="TESTLET_BASE"
value="http://jakarta.apache.org/avalon/testlet"/>
We could change this to
<property name="avalon.base" value="http://jakarta.apache.org/avalon"/>
<property name="framework.base"
value="http://jakarta.apache.org/avalon/framework"/>
...
<filter token="AVALON_BASE" value="${avalon.base}"/>
<filter token="FRAMEWORK_BASE" value="${framework.base}"/>
...
Then we could simply change values of properties to make base go from
"http://jakarta.apache.org/avalon/framework" to "framework"
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 |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: jakarta-avalon-phoenix-bin.jar self-installable
Posted by Peter Donald <do...@apache.org>.
At 06:33 13/5/01 +0100, Paul Hammant wrote:
>A bit late now for additional functionaility?
nope - especially because we haven't even added releases for
phoenix/cornerstone ;)
>If jakarta-avalon-phoenix-bin.jar (which does not yet exist) were
executable, it could
>
>1a) extract itself to jakarta-avalon-phoenix-bin (in the current) dir
>1b) extract itself to a -d specified parameter
>2) if -f (force) were specified, could overwrite the contents of that dir
instead of issue an
>error
...snip...
This would be useful but I would like to stick to a standard if at all
possible. Over at commons there is discussion surrounding CJAN/JJAN/JNLP to
do this sort of thing. Whether it gets done is another thing altogether ;)
I would like to see how it pans out though.
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 |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: build status and documentation
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
Stephen McConnell wrote:
>
> Now that the build files are updated (thanks Pete for taking care of
> the updates). It is now possible to build any Avalon distribution
> from another ant build file using something like the following:
>
> <ant dir="${avalon.path}" target="dist"/>
>
> or, for phoenix:
>
> <ant dir="${phoenix.path}" target="dist"/>
>
> etc.
>
> While this is a dramatic improvement over the usual open-source
> build processes - there is still room for improvement with respect
> to the generated documentation. Under the current build processes
> here are several documentation inconsistencies on the source of
> local versus remote URL - some pages are local while others
> link to http://jakarta.apache.org/avalon/...
>
> After looking through the src/xdocs sources, the problem appears to be
> linked to the fact that the docs contain cross package references
> whereas the build process is package independent. This creates further
> complications when looking at the generated javadoc - for example, the
> javadoc for Phoenix does not integrate references to Avalon.
>
> What I would like to suggest is that we modify the javadoc targets such
> they builds differently depending on the available "dist" packages.
> For example, if an Avalon "dist" is available, the Phoenix javadoc should
> link to a relative local Avalon doc location.
Its not exactly what you mention, but the projectdocs buildfile builds a
single set of javadocs for all projects, if you have all 5 cvses checked
out in parallel.
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
build status and documentation
Posted by Stephen McConnell <mc...@osm.net>.
Now that the build files are updated (thanks Pete for taking care of
the updates). It is now possible to build any Avalon distribution
from another ant build file using something like the following:
<ant dir="${avalon.path}" target="dist"/>
or, for phoenix:
<ant dir="${phoenix.path}" target="dist"/>
etc.
While this is a dramatic improvement over the usual open-source
build processes - there is still room for improvement with respect
to the generated documentation. Under the current build processes
here are several documentation inconsistencies on the source of
local versus remote URL - some pages are local while others
link to http://jakarta.apache.org/avalon/...
After looking through the src/xdocs sources, the problem appears to be
linked to the fact that the docs contain cross package references
whereas the build process is package independent. This creates further
complications when looking at the generated javadoc - for example, the
javadoc for Phoenix does not integrate references to Avalon.
What I would like to suggest is that we modify the javadoc targets such
they builds differently depending on the available "dist" packages.
For example, if an Avalon "dist" is available, the Phoenix javadoc should
link to a relative local Avalon doc location.
Thoughts ?
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jakarta-avalon-phoenix-bin.jar self-installable
Posted by Paul Hammant <pa...@yahoo.com>.
> > may be unpopular, so am seeking
> > opinion.
>
> I have doubts about this proposal; the only advantages sees to
> be a 30sec or so speed gain for people that need to install an
> app based on phoenix but who do not have phoenix on their
> system yet. That's not enough for me to start mixing concerns.
No problem, deleted already :-)
=====
Regards - Paul H
====
CVS -1, Perforce +1
____________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: jakarta-avalon-phoenix-bin.jar self-installable
Posted by Leo Simons <ma...@leosimons.com>.
> A bit late now for additional functionaility?
nah...phoenix hasn't entered beta yet...
> If jakarta-avalon-phoenix-bin.jar (which does not yet exist) were
> executable, it could
>
> 1a) extract itself to jakarta-avalon-phoenix-bin (in the current) dir
> 1b) extract itself to a -d specified parameter
> 2) if -f (force) were specified, could overwrite the contents of
> that dir instead of issue an
> error
>
> I know this only saves one use of "jar -xf
> jakarta-avalon-phoenix-bin.jar" after a mkdir, but it
> would be quite neat. Especially when re-used by projects that
> are Avalon dependant, to ship
> avalon/phoenix with one or more sar files pre-installed. Yes, I
> know the idea is to drop sars
> into the apps dir of a pre-installed Avalon, but until Avalon
> gets the recognition that say Ant
> and Tomcat have, it's going to be a hard time convincing people
> that they need to download two
> things to test a fancy product (as well as a convoluted instruction list).
While this approach is possible, I'm not quite sure what
the advantages are. As I see it, apps built on phoenix
should provide two versions, where one contains .jar files
for the ./lib dir and .sar files for in the ./bin dir of
a pre-installed phoenix, and the other one is a snapshot
of phoenix with the correct files already in the lib and
build dirs.
When you talk about source distros, you could do this by
having a dist, a dist-complete (including phoenix), a
dist-src and a dist-src-complete (including binary
phoenix).
Upgrading here is the responsibility of the sysadmin, who
can drop in updated Avalon jars into the phoenix installation
as indicated in your documentation.
In other words, I do not think that it is a good idea to
mix roles here - exactly how other apps include avalon
in their distros is not in the avalon problem space.
> To take it one stage further.. the installer (after installation)
> could invoke engine.Main to
> kickoff Avalon-phoenix. To goal being that the jar would be
> double click installable/runnable for
> the armchair heros of this world.
>
> Anyway, I have half written it (a clone of Main), but figure it
that isn't correct behaviour anymore. The class you're talking
about should implement org.apache.avalon.framework.atlantis.Embeddor,
and possibly extend the provided PhoenixEmbeddor.
> may be unpopular, so am seeking
> opinion.
I have doubts about this proposal; the only advantages sees to
be a 30sec or so speed gain for people that need to install an
app based on phoenix but who do not have phoenix on their
system yet. That's not enough for me to start mixing concerns.
cheers!
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org