You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2001/06/15 13:15:15 UTC
Tools, Tools, Tools...
Christoph Reck just sent me a set of cool tools. Also, a client of mine
wants to contribute a fancy reporting tool, but are working out the
'details'.
Where do we want to do this?
I would like to get this started in the jakarta commons sandbox as a
webapp/servlet tools project, although there was some mention by Jon of
Turbine as a place as well, so I figured I would float the question
here.
Either way, I think that we should make every effort to make these tools
( with exceptions allowed of course where it can't be avoided )
independant of Velocity to maximise the sharing potential. Of course I
believe that everyone should use Velocity, but if we can knock out a
dependency, we should, if for no other reason than style points :)
In Christophs case, the tools are very well suited for Velocity, much
more than JSP, but I think our wayward bretheren (:->) in the WebMacro
community could benefit as well.
I will start working it into the jakarta commons sandbox this weekend if
I no one has a problem... Anyone who wants to be involved, come on over
- I think we can work out the charter for what we want the project to
be, get things cleaned up an consistant, make nice docs, and propose to
the Commons community to make it a 'regular' commons component.
Christoph proposed the package name org.apache.commons.tools, but I
think that will be rejected as too generic. Thoughts?
o.a.c.webapptools?
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: Tools, Tools, Tools...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ok - this morning I checked in a small project into the Jakarta Commons
sandbox that I hope will be the nucleus of the servlet-based webapp
toolset we have been talking about.
There has been much talk on where to put it, and there are some
excellent arguments for keeping it here in Velocity-land, as well as
pushing up to Turbine-land.
My rationale for putting into Commons is that I think that we might be
better able to attract a diverse community from all walks of
webapp-development life : certainly from here, but also from other
templating tools like WebMacro, as well as getting contributions from
Turbine, Struts and other frameworks. (Maverick?) Having it in Commons
means that the community can grow and develop freely from Velocity. Of
course, we here in Velocity will play a huge role I hope, but having it
in 'neutral ground' so to speak means that with care, we can produce a
set of tools beneficial to all.
If things don't work out over there, we can always pull things back into
here.
And if someone doesn't agree it should be over thre, we can pull it back
here also.
So far, there are contributions from Christoph and Nathan, and they have
been added to the STATUS file as initial committers. If there are any
others who which to participate - speak up. Also, if anyone has any
tools to contribute...
There are two things that will immediately strike you as odd :
1) The name of the component (they are called components in Commons) is
'Rupert'. I chose this as a meta-name, knowing that it would be a long
discussion (naming discussions usually are...) and didn't want it to
hold things up. So yes, we'll have to change the package names
eventually....
2) Structure of org.apache.commons.rupert package. Right now, I just
dumped, after a little bit of tweaking for package names, licensing and
such, the orignal contributions from Christoph and Nathan into two
separate directories named (strangely enough, christoph and nathan).
The reason is that each submitted a MathTool.java. So what I expect is
that we'll sort out how to merge the functionality, and then choose a
real package structure to organize things. Being in the sandbox means
we can do whatever we want, and dump all the CVS directory baggage when
its moved to commons proper if accepted.
As far as the package structure goes - who knows... it will probably
depend upon the functionality and dependencies of the tools. I hope we
can drive out of the tools as much template-engine-specific
functionality as possible. For example, ParameterParser.java has a
dependency on Velocity's Runtime class, only for one use to get a single
property value. We could easily refactor this out, making it an arg to
the CTOR, an arg to the call if static (i don't remember), or make it
deal with a Configuration or Properties class if it grows to need more
input properties.
However, I would imagine that we could support velocity-specific tools
in a *.velocity directory and so forth.
Anyhow, the thing should be complete - all you need to do is download
the tree :
$cvs checkout jakarta-commons-sandbox/rupert
should do the trick, modulo server/access permissions (is accessable via
anon CVS - see http://jakarta.apache.org/site/cvsindex.html )
You must install ant. (http://jakarta.apache.org/ant/)
Then, you need to get the dependencies listed in the STATUS.html file.
You can just drop them into the lib directory, or make a
build.properties file to localize. If you stare at build.xml and the
build.properties.sample, you should get the idea...
I will do a short announcement on the commons list, and assuming all are
happy here, we should take the conversation over there.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: Tools, Tools, Tools...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Nathan Bubna wrote:
>
> [snip]
>
> > MathTool - this is probably obsolete with the simple arithmetic provided
> > by velocity:
> > public static int sum(int, int);
> > public static int sub(int, int);
> > public static int max(int, int);
> > public static int min(int, int);
> > public static boolean gt(int, int);
> > public static boolean lt(int, int);
> >
>
> as far as tools for velocity are concerned, i think a MathTool that allows
> for floating point arithmetic is quite useful. I could be wrong, but last i
> checked, velocity doesn't handle math with double or float.
You are right - thats intentional, noting that people can and will use
tools.
> I wrote a quick and dirty tool for this a while back that I will contribute
> if there's interest.
There's interest...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: Tools, Tools, Tools...
Posted by Nathan Bubna <na...@esha.com>.
[snip]
> MathTool - this is probably obsolete with the simple arithmetic provided
> by velocity:
> public static int sum(int, int);
> public static int sub(int, int);
> public static int max(int, int);
> public static int min(int, int);
> public static boolean gt(int, int);
> public static boolean lt(int, int);
>
as far as tools for velocity are concerned, i think a MathTool that allows
for floating point arithmetic is quite useful. I could be wrong, but last i
checked, velocity doesn't handle math with double or float.
I wrote a quick and dirty tool for this a while back that I will contribute
if there's interest.
-nathan
Re: Tools, Tools, Tools...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
John Menke wrote:
>
> Where are the tools located? (In which CVS?)
>
I'll dump them into jakarta-commons-sandbox today. Sorry about the
delay.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
RE: Tools, Tools, Tools...
Posted by John Menke <jo...@murphyfutures.com>.
Where are the tools located? (In which CVS?)
> -----Original Message-----
> From: Christoph.Reck@dlr.de [mailto:Christoph.Reck@dlr.de]
> Sent: Monday, June 18, 2001 9:26 AM
> To: velocity-user@jakarta.apache.org
> Subject: Re: Tools, Tools, Tools...
>
>
> There seems to be a big community waiting for a CPAN type of tools
> to be used in Java applications. Jakarta seems to come somehow into
> place here, but the granularity of the different sub-projects vary
> a lot.
>
> The inter-dependacies are growing and are not very transparent.
> A graph of the project dependencies and granularities (categories:
> tools, framework, library) would be great and help new people find
> what they need:
> * ORO/regexp, log4j and commons/* seem to be at the lowest level
> (=libraries). Peers, Criteria and Intake could also be made
> available at this level (these are from Turbine).
> * Ant, James, and Watchdog are general tools. Torque, Anakia, Texen,
> etc. would pop in here.
> * Struts, Turbine and Avalon are frameworks. Jetspeed seems to be
> an extension to Turbine.
> * Tomcat (Server) and Alexandria (Client) are applications.
>
>
> The tools I sent to Geir fulfill different contracts, so they should
> be split and merged with other contributions when entering the
> commons. My set of tools is too small to live by itself. This initial
> contribution should start and prepare the place for others to follow.
>
>
> I know that Turbine has several good candidates, as my current
> extracts: ParameterParser.java DynamicURI.java show. The original
> form of these where interlinked with Turbine to be used standalone,
> but they can be easily streamlined to follow a clear contract.
>
>
> To avoid more inter-dependancies between Jakarta projects I recommend
> leaving anything velocity, turbine, etc. dependant in those packages.
> When something is clearly externalizable and makes sense outside of
> the originating package, it can promote into the commons.
>
>
> The next method-dumps should illustrate the functionality provided
> by my initial contribution. Consult the apidocs for more.
>
> ClassTool - Provides utilities for instantiating classes out of scripts
> and templates (I use these for my initialization templates):
> public static Class classForName(String)
> public static Object newInstance(String)
> public static Object newInstance(String, Object[])
> /** considers superclasses and primitives **/
> public static reflect.Constructor getConstructor(Class, Object[])
> /** this is the introspection code that drives velocity **/
> public static reflect.Method getMethod(Class, String, Object[])
>
> ContextTool - should be stripped and merged to different classes to
> fulfill explicit contracts.
> /** should be deprecated by a #context directive in velocity **/
> public org.apache.velocity.context.Context getContext();
> /** wrapper to java.net.URLEncoder.encode() for
> scripts/templates usage **/
> public static String URLEncode(String);
> public static String encodeMarkup(String);
> public static String formEncode(String) throws Exception;
> public static String formDecode(String) throws Exception;
> public static boolean isAlphaNumeric(char);
> /** removes unwanted characters to create JavaScript window
> or file names **/
> public static String encodeToName(String);
> /** I guess these may come convenient to some templaters..., should be
> ** move to be beside ClassTool (maybe InstanceTool?) **/
> public static Vector newVector(int);
> public static Hashtable newHashtable(int);
> public static Object newArray(int);
> /** workaround the dreaded Object[] introspection-dead-end **/
> public static Object getElement(int, Object[]);
> public static Object getElement(int, Object[], Object);
> /** ever wanted to get the #foreach contents sorted? **/
> public static Object sort(Object[])[];
> /** simple string splitter, move to StringUtils **/
> public static Vector tokenize(String, String);
>
> The ParameterParser and DynamicURI classes are taken from Turbine,
> The PP has been stripped from the file upload (multipart-mime) and the
> propietary date handling parts (these features could be implemented
> by either subclasses or by plug-ins defined vi interfaces).
> DURI adds a convenient clone() method.
>
> FileTool$FilenameFilter
> FileTool - I've implemented a VTL scripted controller that uses
> the following
> public static String dirname(String); // will also need
> drive char. handling...
> public static String filename(String); // with extension
> public static String basename(String); // last extension stripped
> public static String basename(String, String); // specific
> extension stripped
> public static String extension(String);
> /** wrapper to the corresponding java property **/
> public static String fileNameSeparator(String);
> public static boolean fileExists(String);
> /** similar to #set( $foo = "#include('any.txt')" ) **/
> public static String fileRead(String) throws Exception;
> public static void fileWrite(String, String) throws Exception;
> public static void fileDelete(String);
> /** used to poll for a lock or wait for a file-clreation to
> propagate over NFS */
> public static boolean waitFor(String, int);
> public static java.io.File getFile(String);
> /** allows directory listings be loaded and formatted via velocity **/
> public static Vector dirRead(String, String);
>
> IsoDateTool - a user friendly interface to DateFormatter using
> the ISO8601
> date format as the default.
> public static String getDate();
> public static String format(Date);
> public static Date fromString(String); // with ISO tolerant
> abbreviations
>
> InvokeInThread - I managed to spawn a VTL controller task to run in
> a background thread and display its status and intermediate results from
> the presentation template.
> InvokeInThread(String,Object,reflect.Method,Object[]);
> public void run();
> public void setData(Object);
> public Object getData();
>
> MathTool - this is probably obsolete with the simple arithmetic provided
> by velocity:
> public static int sum(int, int);
> public static int sub(int, int);
> public static int max(int, int);
> public static int min(int, int);
> public static boolean gt(int, int);
> public static boolean lt(int, int);
>
> ScriptTool - *very* useful enhancement to the poor exec-support of Java:
> public static final int IDLE;
> public static final int RUNNING;
> public static final int START_FAILED;
> public ProcessControl exec(String);
> /** returns STATUS, STDERR, STDOUT in a hash **/
> public Hashtable call(String);
> ScriptTool$StreamReader
> public String getOutput(boolean);
> public void run();
> ScriptTool$ProcessControl
> public void terminate();
> public boolean isRunning();
> public boolean sendCommand(String);
> public String getStdout(boolean);
> public String getStderr(boolean);
> public int getStatus();
> public void waitForCompletion();
> public void finalize() throws Throwable;
>
> UserTool - simple XML-based user-group-role-permission implementation.
> This could be enhanced by defining access via interfaces and embedding
> the turbine classes and DB-interfaces:
> public boolean loadUserRoles(String filename);
> public boolean hasRole(String, String);
> public boolean hasRole(String, String, String);
> public Object getRoles(String)[];
> public boolean hasPermission(String, String);
> public boolean hasPermission(String, String, String);
> public Object getPermissions(String)[];
>
> XmlTool - handy interface and enahncements to JDOM. Note that JDOM is
> planning to integrate xpath support.
> public static org.jdom.Element load(String);
> public static org.jdom.Element fromString(String);
> public static String format(org.jdom.Document, String, int);
> public static String format(org.jdom.Element, String, int);
> public static ArrayList getAttributeList(org.jdom.Element, String);
> public static ArrayList getTextList(org.jdom.Element, String);
> public static List applyXPath(org.jdom.Document, String);
> public static List applyXPath(org.jdom.Element, String);
> public static List applyXPath(List, String);
>
>
> > > > > #1 org.apache.commons.beantools
> > > > > #2 org.apache.commons.toolbeans
> > > > > I think I like #2 better.
> > > > +1 on #2
> >
> > > Well, they aren't all beans, either. I don't think we should
> make that
> > > a requirement.
> >
> > Hmmm... Good point.
> >
> > org.apache.commons.tools
> > org.apache.commons.toolbox
> > org.apache.commons.widgets
> > org.apache.commons.doodads
> > org.apache.commons.gizmos
> > org.apache.commons.gadgets
> >
> > sorry...couldn't resist, it's Friday. ;-)
> > TLC
>
> It should be
> org.apache.commons.tools
> and
> org.apache.commons.beans
> and
> org.apache.commons.peers
> and
> org.apache.commons.acl
> etc.
>
> Note that it is clear that each of these are not sufficient to
> justify an own library. Maybe the union of peers and acl with
> some additional code (e.g. a velocity based administration
> webapp) could then compose a new jakarta sub-project.
>
>
> Any feedback is welcome,
> Christoph Reck
Re: Tools, Tools, Tools...
Posted by Christoph Reck <Ch...@dlr.de>.
There seems to be a big community waiting for a CPAN type of tools
to be used in Java applications. Jakarta seems to come somehow into
place here, but the granularity of the different sub-projects vary
a lot.
The inter-dependacies are growing and are not very transparent.
A graph of the project dependencies and granularities (categories:
tools, framework, library) would be great and help new people find
what they need:
* ORO/regexp, log4j and commons/* seem to be at the lowest level
(=libraries). Peers, Criteria and Intake could also be made
available at this level (these are from Turbine).
* Ant, James, and Watchdog are general tools. Torque, Anakia, Texen,
etc. would pop in here.
* Struts, Turbine and Avalon are frameworks. Jetspeed seems to be
an extension to Turbine.
* Tomcat (Server) and Alexandria (Client) are applications.
The tools I sent to Geir fulfill different contracts, so they should
be split and merged with other contributions when entering the
commons. My set of tools is too small to live by itself. This initial
contribution should start and prepare the place for others to follow.
I know that Turbine has several good candidates, as my current
extracts: ParameterParser.java DynamicURI.java show. The original
form of these where interlinked with Turbine to be used standalone,
but they can be easily streamlined to follow a clear contract.
To avoid more inter-dependancies between Jakarta projects I recommend
leaving anything velocity, turbine, etc. dependant in those packages.
When something is clearly externalizable and makes sense outside of
the originating package, it can promote into the commons.
The next method-dumps should illustrate the functionality provided
by my initial contribution. Consult the apidocs for more.
ClassTool - Provides utilities for instantiating classes out of scripts
and templates (I use these for my initialization templates):
public static Class classForName(String)
public static Object newInstance(String)
public static Object newInstance(String, Object[])
/** considers superclasses and primitives **/
public static reflect.Constructor getConstructor(Class, Object[])
/** this is the introspection code that drives velocity **/
public static reflect.Method getMethod(Class, String, Object[])
ContextTool - should be stripped and merged to different classes to
fulfill explicit contracts.
/** should be deprecated by a #context directive in velocity **/
public org.apache.velocity.context.Context getContext();
/** wrapper to java.net.URLEncoder.encode() for scripts/templates usage **/
public static String URLEncode(String);
public static String encodeMarkup(String);
public static String formEncode(String) throws Exception;
public static String formDecode(String) throws Exception;
public static boolean isAlphaNumeric(char);
/** removes unwanted characters to create JavaScript window or file names **/
public static String encodeToName(String);
/** I guess these may come convenient to some templaters..., should be
** move to be beside ClassTool (maybe InstanceTool?) **/
public static Vector newVector(int);
public static Hashtable newHashtable(int);
public static Object newArray(int);
/** workaround the dreaded Object[] introspection-dead-end **/
public static Object getElement(int, Object[]);
public static Object getElement(int, Object[], Object);
/** ever wanted to get the #foreach contents sorted? **/
public static Object sort(Object[])[];
/** simple string splitter, move to StringUtils **/
public static Vector tokenize(String, String);
The ParameterParser and DynamicURI classes are taken from Turbine,
The PP has been stripped from the file upload (multipart-mime) and the
propietary date handling parts (these features could be implemented
by either subclasses or by plug-ins defined vi interfaces).
DURI adds a convenient clone() method.
FileTool$FilenameFilter
FileTool - I've implemented a VTL scripted controller that uses the following
public static String dirname(String); // will also need drive char. handling...
public static String filename(String); // with extension
public static String basename(String); // last extension stripped
public static String basename(String, String); // specific extension stripped
public static String extension(String);
/** wrapper to the corresponding java property **/
public static String fileNameSeparator(String);
public static boolean fileExists(String);
/** similar to #set( $foo = "#include('any.txt')" ) **/
public static String fileRead(String) throws Exception;
public static void fileWrite(String, String) throws Exception;
public static void fileDelete(String);
/** used to poll for a lock or wait for a file-clreation to propagate over NFS */
public static boolean waitFor(String, int);
public static java.io.File getFile(String);
/** allows directory listings be loaded and formatted via velocity **/
public static Vector dirRead(String, String);
IsoDateTool - a user friendly interface to DateFormatter using the ISO8601
date format as the default.
public static String getDate();
public static String format(Date);
public static Date fromString(String); // with ISO tolerant abbreviations
InvokeInThread - I managed to spawn a VTL controller task to run in
a background thread and display its status and intermediate results from
the presentation template.
InvokeInThread(String,Object,reflect.Method,Object[]);
public void run();
public void setData(Object);
public Object getData();
MathTool - this is probably obsolete with the simple arithmetic provided
by velocity:
public static int sum(int, int);
public static int sub(int, int);
public static int max(int, int);
public static int min(int, int);
public static boolean gt(int, int);
public static boolean lt(int, int);
ScriptTool - *very* useful enhancement to the poor exec-support of Java:
public static final int IDLE;
public static final int RUNNING;
public static final int START_FAILED;
public ProcessControl exec(String);
/** returns STATUS, STDERR, STDOUT in a hash **/
public Hashtable call(String);
ScriptTool$StreamReader
public String getOutput(boolean);
public void run();
ScriptTool$ProcessControl
public void terminate();
public boolean isRunning();
public boolean sendCommand(String);
public String getStdout(boolean);
public String getStderr(boolean);
public int getStatus();
public void waitForCompletion();
public void finalize() throws Throwable;
UserTool - simple XML-based user-group-role-permission implementation.
This could be enhanced by defining access via interfaces and embedding
the turbine classes and DB-interfaces:
public boolean loadUserRoles(String filename);
public boolean hasRole(String, String);
public boolean hasRole(String, String, String);
public Object getRoles(String)[];
public boolean hasPermission(String, String);
public boolean hasPermission(String, String, String);
public Object getPermissions(String)[];
XmlTool - handy interface and enahncements to JDOM. Note that JDOM is
planning to integrate xpath support.
public static org.jdom.Element load(String);
public static org.jdom.Element fromString(String);
public static String format(org.jdom.Document, String, int);
public static String format(org.jdom.Element, String, int);
public static ArrayList getAttributeList(org.jdom.Element, String);
public static ArrayList getTextList(org.jdom.Element, String);
public static List applyXPath(org.jdom.Document, String);
public static List applyXPath(org.jdom.Element, String);
public static List applyXPath(List, String);
> > > > #1 org.apache.commons.beantools
> > > > #2 org.apache.commons.toolbeans
> > > > I think I like #2 better.
> > > +1 on #2
>
> > Well, they aren't all beans, either. I don't think we should make that
> > a requirement.
>
> Hmmm... Good point.
>
> org.apache.commons.tools
> org.apache.commons.toolbox
> org.apache.commons.widgets
> org.apache.commons.doodads
> org.apache.commons.gizmos
> org.apache.commons.gadgets
>
> sorry...couldn't resist, it's Friday. ;-)
> TLC
It should be
org.apache.commons.tools
and
org.apache.commons.beans
and
org.apache.commons.peers
and
org.apache.commons.acl
etc.
Note that it is clear that each of these are not sufficient to
justify an own library. Maybe the union of peers and acl with
some additional code (e.g. a velocity based administration
webapp) could then compose a new jakarta sub-project.
Any feedback is welcome,
Christoph Reck
Re: Tools, Tools, Tools...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Simon Christian wrote:
>
> "Geir Magnusson Jr." wrote:
>
> >
> > That's my feeling as well - get the thing going in commons, and stand
> > back :)
> >
> > The tools are :
> >
> > ClassTool.java FileTool.java MathTool.java
> > UserTool.java
> > ContextTool.java InvokeInThread.java ParameterParser.java
> > XmlTool.java
> > DynamicURI.java IsoDateTool.java ScriptTool.java
> >
> > and you can guess what they do... assuming all in agreement (especially
> > Christoph :), will have over in commons this weekend.
> >
>
> Looking forward to it!
>
> Whilst developers will probably use these tools mostly with Velocity
> (?), is it correct that Velocity-specific tools go into a commons
> package? I'm thinking of ContextTool.java here.
Yes - ContextTool really doesn't do much Vel related except give a
method to return the context.
That is a good question, but we might have
org.apache.commons.<name_we_choose>.velocity
package for the vel specific tools.
I will get into the sandbox asap tomorrow.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: Tools, Tools, Tools...
Posted by Simon Christian <si...@cpd.co.uk>.
"Geir Magnusson Jr." wrote:
>
> That's my feeling as well - get the thing going in commons, and stand
> back :)
>
> The tools are :
>
> ClassTool.java FileTool.java MathTool.java
> UserTool.java
> ContextTool.java InvokeInThread.java ParameterParser.java
> XmlTool.java
> DynamicURI.java IsoDateTool.java ScriptTool.java
>
> and you can guess what they do... assuming all in agreement (especially
> Christoph :), will have over in commons this weekend.
>
Looking forward to it!
Whilst developers will probably use these tools mostly with Velocity
(?), is it correct that Velocity-specific tools go into a commons
package? I'm thinking of ContextTool.java here.
- simon
Re: Tools, Tools, Tools...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Simon Christian wrote:
>
> Any hints as to what these tools actually are?
>
> I'd ideally like to see the tools in a seperate package as you are
> proposing - both because wrapping it up in a larger project (e.g.
> Turbine) may make it more cumbersome and slow down release schedules,
> and also because I feel more people are likely to contribute when they
> can get in 'on the ground floor'.
>
> 2p
>
That's my feeling as well - get the thing going in commons, and stand
back :)
The tools are :
ClassTool.java FileTool.java MathTool.java
UserTool.java
ContextTool.java InvokeInThread.java ParameterParser.java
XmlTool.java
DynamicURI.java IsoDateTool.java ScriptTool.java
and you can guess what they do... assuming all in agreement (especially
Christoph :), will have over in commons this weekend.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: Tools, Tools, Tools...
Posted by Simon Christian <si...@cpd.co.uk>.
Any hints as to what these tools actually are?
I'd ideally like to see the tools in a seperate package as you are
proposing - both because wrapping it up in a larger project (e.g.
Turbine) may make it more cumbersome and slow down release schedules,
and also because I feel more people are likely to contribute when they
can get in 'on the ground floor'.
2p
- simon
"Geir Magnusson Jr." wrote:
>
> Christoph Reck just sent me a set of cool tools. Also, a client of mine
> wants to contribute a fancy reporting tool, but are working out the
> 'details'.
>
> Where do we want to do this?
>
> I would like to get this started in the jakarta commons sandbox as a
> webapp/servlet tools project, although there was some mention by Jon of
> Turbine as a place as well, so I figured I would float the question
> here.
>
> Either way, I think that we should make every effort to make these tools
> ( with exceptions allowed of course where it can't be avoided )
> independant of Velocity to maximise the sharing potential. Of course I
> believe that everyone should use Velocity, but if we can knock out a
> dependency, we should, if for no other reason than style points :)
>
> In Christophs case, the tools are very well suited for Velocity, much
> more than JSP, but I think our wayward bretheren (:->) in the WebMacro
> community could benefit as well.
>
> I will start working it into the jakarta commons sandbox this weekend if
> I no one has a problem... Anyone who wants to be involved, come on over
> - I think we can work out the charter for what we want the project to
> be, get things cleaned up an consistant, make nice docs, and propose to
> the Commons community to make it a 'regular' commons component.
>
> Christoph proposed the package name org.apache.commons.tools, but I
> think that will be rejected as too generic. Thoughts?
> o.a.c.webapptools?
>
> geir
>
Re: Tools, Tools, Tools...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Tim Colson wrote:
>
> > > > #1 org.apache.commons.beantools
> > > > #2 org.apache.commons.toolbeans
> > > > I think I like #2 better.
> > > +1 on #2
>
> > Well, they aren't all beans, either. I don't think we should make that
> > a requirement.
>
> Hmmm... Good point.
>
> org.apache.commons.tools
> org.apache.commons.toolbox
> org.apache.commons.widgets
> org.apache.commons.doodads
> org.apache.commons.gizmos
> org.apache.commons.gadgets
>
I think we can make a package tree :
org.apache.commons.rupert.velocity : velocity specific
org.apache.commons.rupert.general :
org.apache.commons.rupert.beans
note that 'rupert' is a joke from the original discussion to start
commons - we couldn't agree on a name, so I suggested 'rupert'.
needless to say, it didn't take.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
RE: Tools, Tools, Tools...
Posted by Tim Colson <tc...@cisco.com>.
> > > #1 org.apache.commons.beantools
> > > #2 org.apache.commons.toolbeans
> > > I think I like #2 better.
> > +1 on #2
> Well, they aren't all beans, either. I don't think we should make that
> a requirement.
Hmmm... Good point.
org.apache.commons.tools
org.apache.commons.toolbox
org.apache.commons.widgets
org.apache.commons.doodads
org.apache.commons.gizmos
org.apache.commons.gadgets
sorry...couldn't resist, it's Friday. ;-)
TLC
Re: Tools, Tools, Tools...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Tim Colson wrote:
>
> > > o.a.c.webapptools?
> -1 - because the tools can be used for non-web stuff.
>
> > #1 org.apache.commons.beantools
> > #2 org.apache.commons.toolbeans
> > I think I like #2 better.
> +1 on #2
Well, they aren't all beans, either. I don't think we should make that
a requirement.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
RE: Tools, Tools, Tools...
Posted by Tim Colson <tc...@cisco.com>.
> > o.a.c.webapptools?
-1 - because the tools can be used for non-web stuff.
> #1 org.apache.commons.beantools
> #2 org.apache.commons.toolbeans
> I think I like #2 better.
+1 on #2
I'm excited about this -- It's a great feeling to find a ready-built tool
already built/tested and available to do what you need to do, something I've
grown accustomed to using the Module Repository for Perl (CPAN.org). :-)
-Timo
Re: Tools, Tools, Tools...
Posted by Jon Stevens <jo...@latchkey.com>.
on 6/15/01 4:15 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> Christoph proposed the package name org.apache.commons.tools, but I
> think that will be rejected as too generic. Thoughts?
> o.a.c.webapptools?
>
> geir
org.apache.commons.beantools
Or
org.apache.commons.toolbeans
I think I like #2 better.
Also, if they don't go for it in the commons, just put it into CVS as
jakarta-velocity-toolbeans or something like that.
-jon
Re: Tools, Tools, Tools...
Posted by Jason van Zyl <jv...@apache.org>.
On 6/15/01 7:15 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> Christoph Reck just sent me a set of cool tools. Also, a client of mine
> wants to contribute a fancy reporting tool, but are working out the
> 'details'.
>
> Where do we want to do this?
>
>
> I would like to get this started in the jakarta commons sandbox as a
> webapp/servlet tools project, although there was some mention by Jon of
> Turbine as a place as well, so I figured I would float the question
> here.
I think the commons is best. I added something to the turbine cleanup
proposal to pull out some of our utility code and place it in the
commons. Then place our context tools that rely on this utility
code in the templating tools repository.
>
> Either way, I think that we should make every effort to make these tools
> ( with exceptions allowed of course where it can't be avoided )
> independant of Velocity to maximise the sharing potential. Of course I
> believe that everyone should use Velocity, but if we can knock out a
> dependency, we should, if for no other reason than style points :)
+1
>
> In Christophs case, the tools are very well suited for Velocity, much
> more than JSP, but I think our wayward bretheren (:->) in the WebMacro
> community could benefit as well.
>
> I will start working it into the jakarta commons sandbox this weekend if
> I no one has a problem... Anyone who wants to be involved, come on over
> - I think we can work out the charter for what we want the project to
> be, get things cleaned up an consistant, make nice docs, and propose to
> the Commons community to make it a 'regular' commons component.
>
Sounds good, Turbine can definitely contribute an email tool.
> Christoph proposed the package name org.apache.commons.tools, but I
> think that will be rejected as too generic. Thoughts?
> o.a.c.webapptools?
Sure, sounds good.
> geir
--
jvz.
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons