You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Vincent Massol <vm...@octo.com> on 2002/12/24 13:30:35 UTC
[PROPOSAL] New directory structure?
Hi,
As a christmas gift, I'd like to propose a new directory structure to
follow-up on the new web site presentation email I've sent (provided it
is well received on course ;-)).
Here's the new structure I'd like to propose:
jakarta-cactus
|_ anttasks
(only keep in this subproject the Ant tasks that are not related
to Cactus. This subproject is expected to disappear over time as
it is expected Ant will provide solutions to perform what we are
doing)
|_ framework
|_ documentation
|_ samples
|_ sample-servlet
|_ sample-jetty
|_ sample-ejb (in the future)
|_ frontends
|_ eclipse
|_ ant
(contains Cactus related Ant tasks such as StartTask, StopTask,
etc and reusable Ant scriptlets for several containers. See
the other email entitled "Ant subproject packaging" for more
ideas on the artifacts from this subproject)
As you can see, it is not a major change but I feel it is time to start
putting these additional directories: "samples" and "frontends" to
better compartiment stuff.
Do you like this new structure?
We really need a good name to describe what I've been calling Front Ends
till now. Is Front End a word you like and find expressive enough? Do
you have a better alternative?
Thanks
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] New directory structure?
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
>>BTW, this also seems like a good time to think about moving the
>>org.apache.cactus.unit regression test suite into the framework,
>
>
> hum... I'm not sure it goes in the framework, the reason being it needs
> Cactus itself and all the container configurations/scripts which are
> located in the "spines/frontends"/ant directory.
>
>
>>or at
>>least out of the sample-servlet.
>
>
> I'm not 100% sure. I've always considered these tests to be real useful
> to learn how to use Cactus as they show almost every possibility of
> using Cactus. So, not only are they regression tests, they are also
> documentation/samples. I do agree they are not at exactly the same level
> as the provided few "real" samples.
>
> I can see 3 solutions:
>
> A/ Leave both the test suite and the "real" samples in sample-servlet,
> adding a README file explaining the difference.
>
> B/ Remove the few "real" samples and make sample-servlet a regression
> suite that also acts as documentation/sample. This means removing the
> src/sample directory and only keeping the src/unit one (which could be
> renamed should we wish)
>
> C/ Make 2 subprojects in jakarta-cactus/samples:
>
> servlet/ : "real" samples
> testsuite/ : regression test suite
I'd rather have a jakarta-cactus/testsuite module.
> Then, the last question is whether the regression test suite is packaged
> in the cactus distribution or not.
This is a good question. Personally, I don't find the regression test
suite very good at demonstrating how to use Cactus. Rather, it might
confuse users, because it looks more like a regression test suite for
the servlet-container, the http-client-library and of course Cactus. At
least, *I* was confused when seeing the names of the tests flying by for
the first time. Not exactly the type of stuff you want to test about
your typical web-application.
That being said, the testsuite *does* of course contain code that is
useful as a reference. However, that's not unusual about test code. The
question remains whether the testsuite should be included with the
binary distribution...
> Personally, I find C/ the most complex as it means a new subproject and
> thus a new build. I think my preference would go towards B/.
To summarize, I'd prefer the regression test suite (i.e. the tests that
test Cactus using Cactus) to be in a module in its own right (for
instance jakarta-cactus/testsuite). I think that such a testsuite module
using its own build will make the actual sample application cleaner
and easier to understand. But that really also depends on the "Ant
Spine" module, providing an integration with Ant that is more reusable.
That's why I was suggesting the change in this thread.
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] New directory structure?
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 25 December 2002 12:36
> To: Cactus Developers List
> Subject: Re: [PROPOSAL] New directory structure?
>
> BTW, this also seems like a good time to think about moving the
> org.apache.cactus.unit regression test suite into the framework,
hum... I'm not sure it goes in the framework, the reason being it needs
Cactus itself and all the container configurations/scripts which are
located in the "spines/frontends"/ant directory.
> or at
> least out of the sample-servlet.
I'm not 100% sure. I've always considered these tests to be real useful
to learn how to use Cactus as they show almost every possibility of
using Cactus. So, not only are they regression tests, they are also
documentation/samples. I do agree they are not at exactly the same level
as the provided few "real" samples.
I can see 3 solutions:
A/ Leave both the test suite and the "real" samples in sample-servlet,
adding a README file explaining the difference.
B/ Remove the few "real" samples and make sample-servlet a regression
suite that also acts as documentation/sample. This means removing the
src/sample directory and only keeping the src/unit one (which could be
renamed should we wish)
C/ Make 2 subprojects in jakarta-cactus/samples:
servlet/ : "real" samples
testsuite/ : regression test suite
Then, the last question is whether the regression test suite is packaged
in the cactus distribution or not.
Personally, I find C/ the most complex as it means a new subproject and
thus a new build. I think my preference would go towards B/.
What about you?
Thanks
-Vincent
>
> Vincent Massol wrote:
> > Hi,
> >
> > As a christmas gift, I'd like to propose a new directory structure
to
> > follow-up on the new web site presentation email I've sent (provided
it
> > is well received on course ;-)).
> >
> > Here's the new structure I'd like to propose:
> >
> > jakarta-cactus
> > |_ anttasks
> > (only keep in this subproject the Ant tasks that are not
related
> > to Cactus. This subproject is expected to disappear over time
as
> > it is expected Ant will provide solutions to perform what we
are
> > doing)
> > |_ framework
> > |_ documentation
> > |_ samples
> > |_ sample-servlet
> > |_ sample-jetty
> > |_ sample-ejb (in the future)
> > |_ frontends
> > |_ eclipse
> > |_ ant
> > (contains Cactus related Ant tasks such as StartTask,
StopTask,
> > etc and reusable Ant scriptlets for several containers. See
> > the other email entitled "Ant subproject packaging" for more
> > ideas on the artifacts from this subproject)
> >
> > As you can see, it is not a major change but I feel it is time to
start
> > putting these additional directories: "samples" and "frontends" to
> > better compartiment stuff.
> >
> > Do you like this new structure?
> >
> > We really need a good name to describe what I've been calling Front
Ends
> > till now. Is Front End a word you like and find expressive enough?
Do
> > you have a better alternative?
> >
> > Thanks
> > -Vincent
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] New directory structure?
Posted by Christopher Lenz <cm...@gmx.de>.
BTW, this also seems like a good time to think about moving the
org.apache.cactus.unit regression test suite into the framework, or at
least out of the sample-servlet.
Vincent Massol wrote:
> Hi,
>
> As a christmas gift, I'd like to propose a new directory structure to
> follow-up on the new web site presentation email I've sent (provided it
> is well received on course ;-)).
>
> Here's the new structure I'd like to propose:
>
> jakarta-cactus
> |_ anttasks
> (only keep in this subproject the Ant tasks that are not related
> to Cactus. This subproject is expected to disappear over time as
> it is expected Ant will provide solutions to perform what we are
> doing)
> |_ framework
> |_ documentation
> |_ samples
> |_ sample-servlet
> |_ sample-jetty
> |_ sample-ejb (in the future)
> |_ frontends
> |_ eclipse
> |_ ant
> (contains Cactus related Ant tasks such as StartTask, StopTask,
> etc and reusable Ant scriptlets for several containers. See
> the other email entitled "Ant subproject packaging" for more
> ideas on the artifacts from this subproject)
>
> As you can see, it is not a major change but I feel it is time to start
> putting these additional directories: "samples" and "frontends" to
> better compartiment stuff.
>
> Do you like this new structure?
>
> We really need a good name to describe what I've been calling Front Ends
> till now. Is Front End a word you like and find expressive enough? Do
> you have a better alternative?
>
> Thanks
> -Vincent
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cactus Ant Tasks (was Re: [PROPOSAL] New directory structure?)
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 05 January 2003 20:06
> To: Cactus Developers List
> Subject: Re: Cactus Ant Tasks (was Re: [PROPOSAL] New directory
> structure?)
>
[snip]
> >>----------------------------------------------------------
> >>org.apache.cactus.ant.ArgListTask
> >>----------------------------------------------------------
> >>I haven't completely understood why this task exists. IMHO
> >>it could be just kicked out (deprecated ;-) ), and its use
> >>replaced with the normal <arg>, <vmarg> and <sysproperty>
> >>stuff instead, which also have more power when it comes to
> >>handling paths etc.
> >
> >
> > <arg>, <vmarg>, etc are not able to pass optional properties. If you
> > write <vmarg value="-Dxxx=${some.properties}"/> and some.properties
is
> > not defined the called Ant script will receive a property xxx whose
> > value is "${some.properties}" (and not "").
>
> Hmm.. a possible solution would be to make <arg> et al accept
if/unless
> attributes. That would be in the Ant code base, of course. When I find
> some time, I'll try to submit a corresponding patch to the Ant team.
Cool.
>
> >>----------------------------------------------------------
> >>org.apache.cactus.ant.ChangeLogTask
> >>----------------------------------------------------------
> >>Without having looked at it closely, couldn't the use of
> >>this task be replaced with the standard <cvschangelog> ?
> >
> >
> > Almost, except that <cvschangelog> (which by the way was included in
Ant
> > by Peter Donald and myself) does not allow to specify to
include/exclude
> > files, which we need (it may do that now as I think I have asked to
add
> > this feature some while ago).
>
> Okay. AFAICT, <cvschangelog> doesn't support filesets. BTW, that would
> be patternsets, no?
>
> Again, I'll try to get that into the Ant code base as soon as I find
> some time (probably not so soon :-P ).
Cool again. Be careful that the cactus cvschangelog task creates an
empty result XML file if the cvs command fails. This is needed for the
XSL stylesheet that includes the CVS changelog.
>
> >
> >>----------------------------------------------------------
> >>org.apache.cactus.ant.CheckPropertiesTask
> >>org.apache.cactus.ant.CheckPropertyItem
> >>org.apache.cactus.ant.PropertyName
> >>----------------------------------------------------------
> >>All for checking whether a specific property has been set,
> >>and optionally if it refers to an existing file. It is
> >>used to check whether required JAR locations have been set
> >>as properties, bailing if not. In addition, it outputs the
> >>value of the properties.
> >>IMHO, this task can be replaced by standard mechanisms,
> >>using <available>, <fail>, etc. The drawback is a somewhat
> >>longer build file.
> >>
> >>I'd like to avoid having to compile Ant tasks before being able to
> >>compile the framework. I think that for <argList> and
> >
> > <checkProperties>
> >
> >>the additional overhead is not warranted. But just IMHO ;-)
> >
> >
> > I'm +1 to remove any Ant non-standard Ant task provided we don't
loose
> > anything in functionality. ATM I don't see how to do this, except by
> > trying to get our Ant tasks in the Ant optional jars (I tried some
while
> > ago but it is so hard to get heard on the Ant list that I stopped).
> >
> > WRT <checkProperties>, I don't know any nice out of the box Ant
solution
> > to this problem. The best solution I have is:
> >
> > <target name="check.property1">
> > <available property="property1.exist" file="${property1}"/>
> > <echo unless="property1.exist">XXXXXXXXXX</echo>
> > </target>
> >
> > <target name="check.property2">
> > <available property="property2.exist" file="${property2}"/>
> > <echo unless="property2.exist">XXXXXXXXXX</echo>
> > </target>
> >
> > [...]
> >
> > <target name="check.all"
> > depends="check.property1,check.property2,[...]"/>
> >
> > So, if you have 10 properties to check, you need to add 60 lines of
> > build code simply to check that the properties exist. And, it won't
even
> > tell you if the property is not defined or if it points to an
invalid
> > directory/file (but you can guess that). And you don't factorize the
> > message being echoed, etc.
> >
> > There may be a better solution though...
> >
> > But I'm all with you with removing these custom tasks, so if you
find
> > solutions please go ahead if you have an itch to scratch.
>
> For *required* properties, I don't think so much overhead is required.
> Just one target with some <condition> and <fail unless='...'> tasks.
For
> optional properties, you usually need a separate 'warn' target
(because
> <echo> doesn't have if/else-support AFAIK), so that's more complex.
>
> Anyway, I seldomly see the <checkProperty> task do anything useful,
> because the master build file doesn't use it, and I usually invoke
> everything from the master build file.
>
> Usually, simply running ant with the "-verbose" option reveals any
> problems that might occur during build, and in a more detailled
fashion
> than <checkProperty>.
>
> [An additional problem with <checkProperty> is, that it only checks
> whether the property is set, and optionally whether it points to a
valid
> file. It won't detect if a property points the the wrong file, for
> example. In my build files, I use <available classname='...'> to check
> for one central class per library.]
hum. Good points. I just don't like the extra verbosity required in the
build file but please go ahead and remove the checkProperty task.
>
> >
> >> ---- Used at run time ----
> >>
> >>------------------------------------------------------------
> >>org.apache.cactus.ant.AbstractServerRun
> >>org.apache.cactus.ant.EnhydraRun
> >>org.apache.cactus.ant.ResinRun
> >>------------------------------------------------------------
> >>These are all classes for starting/stopping containers.
> >>IMHO they could be useful outside of the Ant tasks module.
> >>What about moving them into the framework?
> >
> >
> > I would like the framework to be completely independent of the
> > frontends. These tasks are definitely needed only by front ends
(maybe
> > not only by Ant tasks although I have not found such a need). Do you
> > currently have a real world use case for them outside of Ant?
>
> Nope ;-)
>
> But then, I don't use any front end other than Ant, currently ;-)
;-)
ATM, let's keep them in the Ant front-end. If we find that several front
ends need to share classes, then we'll refactor.
>
> >>------------------------------------------------------------
> >>org.apache.cactus.ant.RunServerTestsTask
> >>org.apache.cactus.ant.StartServerHelper
> >>org.apache.cactus.ant.StartServerTask
> >>org.apache.cactus.ant.StopServerHelper
> >>org.apache.cactus.ant.StopServerTask
> >>------------------------------------------------------------
> >>The <runservertests>-Task is probably the only task from
> >>this module that most (all?) users have ever used. I'm not
> >>sure about use cases for the StartServerTask/StopServerTask.
> >
> >
> > Hum.... right.... I can't think of any need either ;-)
>
> Candidates for deprecation/removal, then?
ok. Maybe an email on the user list to ask if anyone is using them or
has a use case, before we remove/deprecate?
>
> >>But overall, this code should stay where it is (speaking of
> >>packages), but moved to frontends/ant eventually.
> >>We should have an example that uses
> >><parallel>/<sequential>/<http>/<waitfor> instead of
> >><runservertests>.
> >
> >
> > +1
> >
>
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cactus Ant Tasks (was Re: [PROPOSAL] New directory structure?)
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
>
>>-----Original Message-----
>>From: Christopher Lenz [mailto:cmlenz@gmx.de]
>>Sent: 26 December 2002 16:13
>>To: Cactus Developers List
>>Subject: Cactus Ant Tasks (was Re: [PROPOSAL] New directory
>
> structure?)
>
>>Vincent Massol wrote:
>>[snip]
>>
>>>jakarta-cactus
>>> |_ anttasks
>>> (only keep in this subproject the Ant tasks that are not
>>
> related
>
>>> to Cactus. This subproject is expected to disappear over time
>>
> as
>
>>> it is expected Ant will provide solutions to perform what we
>>
> are
>
>>> doing)
>>
>>[snip]
>>
>>I'll take this as an opportunity to assemble an overview of what
>>currently exists in the anttasks module, and attach my thoughts about
>>each of the parts ...
>
>
> cool :-)
>
>
>> ---- Used at build time ----
>>
>>----------------------------------------------------------
>>org.apache.cactus.ant.ArgListTask
>>----------------------------------------------------------
>>I haven't completely understood why this task exists. IMHO
>>it could be just kicked out (deprecated ;-) ), and its use
>>replaced with the normal <arg>, <vmarg> and <sysproperty>
>>stuff instead, which also have more power when it comes to
>>handling paths etc.
>
>
> <arg>, <vmarg>, etc are not able to pass optional properties. If you
> write <vmarg value="-Dxxx=${some.properties}"/> and some.properties is
> not defined the called Ant script will receive a property xxx whose
> value is "${some.properties}" (and not "").
Hmm.. a possible solution would be to make <arg> et al accept if/unless
attributes. That would be in the Ant code base, of course. When I find
some time, I'll try to submit a corresponding patch to the Ant team.
>>----------------------------------------------------------
>>org.apache.cactus.ant.ChangeLogTask
>>----------------------------------------------------------
>>Without having looked at it closely, couldn't the use of
>>this task be replaced with the standard <cvschangelog> ?
>
>
> Almost, except that <cvschangelog> (which by the way was included in Ant
> by Peter Donald and myself) does not allow to specify to include/exclude
> files, which we need (it may do that now as I think I have asked to add
> this feature some while ago).
Okay. AFAICT, <cvschangelog> doesn't support filesets. BTW, that would
be patternsets, no?
Again, I'll try to get that into the Ant code base as soon as I find
some time (probably not so soon :-P ).
>
>>----------------------------------------------------------
>>org.apache.cactus.ant.CheckPropertiesTask
>>org.apache.cactus.ant.CheckPropertyItem
>>org.apache.cactus.ant.PropertyName
>>----------------------------------------------------------
>>All for checking whether a specific property has been set,
>>and optionally if it refers to an existing file. It is
>>used to check whether required JAR locations have been set
>>as properties, bailing if not. In addition, it outputs the
>>value of the properties.
>>IMHO, this task can be replaced by standard mechanisms,
>>using <available>, <fail>, etc. The drawback is a somewhat
>>longer build file.
>>
>>I'd like to avoid having to compile Ant tasks before being able to
>>compile the framework. I think that for <argList> and
>
> <checkProperties>
>
>>the additional overhead is not warranted. But just IMHO ;-)
>
>
> I'm +1 to remove any Ant non-standard Ant task provided we don't loose
> anything in functionality. ATM I don't see how to do this, except by
> trying to get our Ant tasks in the Ant optional jars (I tried some while
> ago but it is so hard to get heard on the Ant list that I stopped).
>
> WRT <checkProperties>, I don't know any nice out of the box Ant solution
> to this problem. The best solution I have is:
>
> <target name="check.property1">
> <available property="property1.exist" file="${property1}"/>
> <echo unless="property1.exist">XXXXXXXXXX</echo>
> </target>
>
> <target name="check.property2">
> <available property="property2.exist" file="${property2}"/>
> <echo unless="property2.exist">XXXXXXXXXX</echo>
> </target>
>
> [...]
>
> <target name="check.all"
> depends="check.property1,check.property2,[...]"/>
>
> So, if you have 10 properties to check, you need to add 60 lines of
> build code simply to check that the properties exist. And, it won't even
> tell you if the property is not defined or if it points to an invalid
> directory/file (but you can guess that). And you don't factorize the
> message being echoed, etc.
>
> There may be a better solution though...
>
> But I'm all with you with removing these custom tasks, so if you find
> solutions please go ahead if you have an itch to scratch.
For *required* properties, I don't think so much overhead is required.
Just one target with some <condition> and <fail unless='...'> tasks. For
optional properties, you usually need a separate 'warn' target (because
<echo> doesn't have if/else-support AFAIK), so that's more complex.
Anyway, I seldomly see the <checkProperty> task do anything useful,
because the master build file doesn't use it, and I usually invoke
everything from the master build file.
Usually, simply running ant with the "-verbose" option reveals any
problems that might occur during build, and in a more detailled fashion
than <checkProperty>.
[An additional problem with <checkProperty> is, that it only checks
whether the property is set, and optionally whether it points to a valid
file. It won't detect if a property points the the wrong file, for
example. In my build files, I use <available classname='...'> to check
for one central class per library.]
>
>> ---- Used at run time ----
>>
>>------------------------------------------------------------
>>org.apache.cactus.ant.AbstractServerRun
>>org.apache.cactus.ant.EnhydraRun
>>org.apache.cactus.ant.ResinRun
>>------------------------------------------------------------
>>These are all classes for starting/stopping containers.
>>IMHO they could be useful outside of the Ant tasks module.
>>What about moving them into the framework?
>
>
> I would like the framework to be completely independent of the
> frontends. These tasks are definitely needed only by front ends (maybe
> not only by Ant tasks although I have not found such a need). Do you
> currently have a real world use case for them outside of Ant?
Nope ;-)
But then, I don't use any front end other than Ant, currently ;-)
>>------------------------------------------------------------
>>org.apache.cactus.ant.RunServerTestsTask
>>org.apache.cactus.ant.StartServerHelper
>>org.apache.cactus.ant.StartServerTask
>>org.apache.cactus.ant.StopServerHelper
>>org.apache.cactus.ant.StopServerTask
>>------------------------------------------------------------
>>The <runservertests>-Task is probably the only task from
>>this module that most (all?) users have ever used. I'm not
>>sure about use cases for the StartServerTask/StopServerTask.
>
>
> Hum.... right.... I can't think of any need either ;-)
Candidates for deprecation/removal, then?
>>But overall, this code should stay where it is (speaking of
>>packages), but moved to frontends/ant eventually.
>>We should have an example that uses
>><parallel>/<sequential>/<http>/<waitfor> instead of
>><runservertests>.
>
>
> +1
>
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cactus Ant Tasks (was Re: [PROPOSAL] New directory structure?)
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 26 December 2002 16:13
> To: Cactus Developers List
> Subject: Cactus Ant Tasks (was Re: [PROPOSAL] New directory
structure?)
>
> Vincent Massol wrote:
> [snip]
> > jakarta-cactus
> > |_ anttasks
> > (only keep in this subproject the Ant tasks that are not
related
> > to Cactus. This subproject is expected to disappear over time
as
> > it is expected Ant will provide solutions to perform what we
are
> > doing)
> [snip]
>
> I'll take this as an opportunity to assemble an overview of what
> currently exists in the anttasks module, and attach my thoughts about
> each of the parts ...
cool :-)
>
> ---- Used at build time ----
>
> ----------------------------------------------------------
> org.apache.cactus.ant.ArgListTask
> ----------------------------------------------------------
> I haven't completely understood why this task exists. IMHO
> it could be just kicked out (deprecated ;-) ), and its use
> replaced with the normal <arg>, <vmarg> and <sysproperty>
> stuff instead, which also have more power when it comes to
> handling paths etc.
<arg>, <vmarg>, etc are not able to pass optional properties. If you
write <vmarg value="-Dxxx=${some.properties}"/> and some.properties is
not defined the called Ant script will receive a property xxx whose
value is "${some.properties}" (and not "").
>
> ----------------------------------------------------------
> org.apache.cactus.ant.ChangeLogTask
> ----------------------------------------------------------
> Without having looked at it closely, couldn't the use of
> this task be replaced with the standard <cvschangelog> ?
Almost, except that <cvschangelog> (which by the way was included in Ant
by Peter Donald and myself) does not allow to specify to include/exclude
files, which we need (it may do that now as I think I have asked to add
this feature some while ago).
>
> ----------------------------------------------------------
> org.apache.cactus.ant.CheckPropertiesTask
> org.apache.cactus.ant.CheckPropertyItem
> org.apache.cactus.ant.PropertyName
> ----------------------------------------------------------
> All for checking whether a specific property has been set,
> and optionally if it refers to an existing file. It is
> used to check whether required JAR locations have been set
> as properties, bailing if not. In addition, it outputs the
> value of the properties.
> IMHO, this task can be replaced by standard mechanisms,
> using <available>, <fail>, etc. The drawback is a somewhat
> longer build file.
>
> I'd like to avoid having to compile Ant tasks before being able to
> compile the framework. I think that for <argList> and
<checkProperties>
> the additional overhead is not warranted. But just IMHO ;-)
I'm +1 to remove any Ant non-standard Ant task provided we don't loose
anything in functionality. ATM I don't see how to do this, except by
trying to get our Ant tasks in the Ant optional jars (I tried some while
ago but it is so hard to get heard on the Ant list that I stopped).
WRT <checkProperties>, I don't know any nice out of the box Ant solution
to this problem. The best solution I have is:
<target name="check.property1">
<available property="property1.exist" file="${property1}"/>
<echo unless="property1.exist">XXXXXXXXXX</echo>
</target>
<target name="check.property2">
<available property="property2.exist" file="${property2}"/>
<echo unless="property2.exist">XXXXXXXXXX</echo>
</target>
[...]
<target name="check.all"
depends="check.property1,check.property2,[...]"/>
So, if you have 10 properties to check, you need to add 60 lines of
build code simply to check that the properties exist. And, it won't even
tell you if the property is not defined or if it points to an invalid
directory/file (but you can guess that). And you don't factorize the
message being echoed, etc.
There may be a better solution though...
But I'm all with you with removing these custom tasks, so if you find
solutions please go ahead if you have an itch to scratch.
>
> ---- Used at run time ----
>
> ------------------------------------------------------------
> org.apache.cactus.ant.AbstractServerRun
> org.apache.cactus.ant.EnhydraRun
> org.apache.cactus.ant.ResinRun
> ------------------------------------------------------------
> These are all classes for starting/stopping containers.
> IMHO they could be useful outside of the Ant tasks module.
> What about moving them into the framework?
I would like the framework to be completely independent of the
frontends. These tasks are definitely needed only by front ends (maybe
not only by Ant tasks although I have not found such a need). Do you
currently have a real world use case for them outside of Ant?
>
> ------------------------------------------------------------
> org.apache.cactus.ant.RunServerTestsTask
> org.apache.cactus.ant.StartServerHelper
> org.apache.cactus.ant.StartServerTask
> org.apache.cactus.ant.StopServerHelper
> org.apache.cactus.ant.StopServerTask
> ------------------------------------------------------------
> The <runservertests>-Task is probably the only task from
> this module that most (all?) users have ever used. I'm not
> sure about use cases for the StartServerTask/StopServerTask.
Hum.... right.... I can't think of any need either ;-)
> But overall, this code should stay where it is (speaking of
> packages), but moved to frontends/ant eventually.
> We should have an example that uses
> <parallel>/<sequential>/<http>/<waitfor> instead of
> <runservertests>.
+1
Thanks
-Vincent
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Cactus Ant Tasks (was Re: [PROPOSAL] New directory structure?)
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
[snip]
> jakarta-cactus
> |_ anttasks
> (only keep in this subproject the Ant tasks that are not related
> to Cactus. This subproject is expected to disappear over time as
> it is expected Ant will provide solutions to perform what we are
> doing)
[snip]
I'll take this as an opportunity to assemble an overview of what
currently exists in the anttasks module, and attach my thoughts about
each of the parts ...
---- Used at build time ----
----------------------------------------------------------
org.apache.cactus.ant.ArgListTask
----------------------------------------------------------
I haven't completely understood why this task exists. IMHO
it could be just kicked out (deprecated ;-) ), and its use
replaced with the normal <arg>, <vmarg> and <sysproperty>
stuff instead, which also have more power when it comes to
handling paths etc.
----------------------------------------------------------
org.apache.cactus.ant.ChangeLogTask
----------------------------------------------------------
Without having looked at it closely, couldn't the use of
this task be replaced with the standard <cvschangelog> ?
----------------------------------------------------------
org.apache.cactus.ant.CheckPropertiesTask
org.apache.cactus.ant.CheckPropertyItem
org.apache.cactus.ant.PropertyName
----------------------------------------------------------
All for checking whether a specific property has been set,
and optionally if it refers to an existing file. It is
used to check whether required JAR locations have been set
as properties, bailing if not. In addition, it outputs the
value of the properties.
IMHO, this task can be replaced by standard mechanisms,
using <available>, <fail>, etc. The drawback is a somewhat
longer build file.
I'd like to avoid having to compile Ant tasks before being able to
compile the framework. I think that for <argList> and <checkProperties>
the additional overhead is not warranted. But just IMHO ;-)
---- Used at run time ----
------------------------------------------------------------
org.apache.cactus.ant.AbstractServerRun
org.apache.cactus.ant.EnhydraRun
org.apache.cactus.ant.ResinRun
------------------------------------------------------------
These are all classes for starting/stopping containers.
IMHO they could be useful outside of the Ant tasks module.
What about moving them into the framework?
------------------------------------------------------------
org.apache.cactus.ant.RunServerTestsTask
org.apache.cactus.ant.StartServerHelper
org.apache.cactus.ant.StartServerTask
org.apache.cactus.ant.StopServerHelper
org.apache.cactus.ant.StopServerTask
------------------------------------------------------------
The <runservertests>-Task is probably the only task from
this module that most (all?) users have ever used. I'm not
sure about use cases for the StartServerTask/StopServerTask.
But overall, this code should stay where it is (speaking of
packages), but moved to frontends/ant eventually.
We should have an example that uses
<parallel>/<sequential>/<http>/<waitfor> instead of
<runservertests>.
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] New Terminology (was RE: [PROPOSAL] New directory
structure?)
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
[snip]
>>Hmm, "Front End" is indeed not very clear IMHO, but I'm also having a
>>hard time thinking of a better term. The only term I can come up with
>
> is
>
>>"integration" as a directory name, i.e. integration/ant,
>>integration/eclipse. But I don't like that very much either.
>
>
> Yeah, I thought about that one too but I'm not completely happy with it.
> It sounds not too bad as a directory name but not very good as a
> functional subsystem name. I like "Cactus Runners" (although it comes
> from JUnit). They really are integration front ends that act as cactus
> enablers/activators/runners/etc.
Okay, I suggested 'integration' only as a directory name. I wouldn't
view it as a functional sub-system. Rather, the individual modules are
the sub-systems: Cactus/Ant-Integration, Cactus/Eclipse-Integration,
Cactus/Maven-Integration etc. etc. "Runners", IMHO, would be a bit
misleading, as it implies an actual TestRunner.
> Or shall we come up with a nice Cactish name ... :-) humm, let's see ...
> What about "Spines". We have the core framework which is the bulk of the
> Cactus and then several Spines which grow out of the core to activate
> it!
>
> I'm writing this email while flying across the world (London-Mumbai) and
> I don't have an internet connection available for look for other cactish
> names... That will have to wait but I'm sure we can find some nice
> terminology revolving around cactus, if you like the idea of course.
>
> I kinda like Spines though :-)
Spines sounds pretty cool, and non-technical names are always good if
you can't agree on a more technical term ;-)
Only two concerns:
- Spines are the things that actual hurt about Cactusses... I'd rather
call the TestCases or Redirectors or whatever "spines", but not really
the modules that ease the use of Cactus. But I'm not going to insist on
this standpoint ;-)
- Such names need a "Why the name?" explanation. The purpose of a
Cactus/Ant-Spine isn't as obvious as the purpose of a
Cactus/Ant-Integration or Cactus/Ant-Front-End.
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PROPOSAL] New Terminology (was RE: [PROPOSAL] New directory structure?)
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 25 December 2002 12:34
> To: Cactus Developers List
> Subject: Re: [PROPOSAL] New directory structure?
>
> Hi Vincent,
>
> Vincent Massol wrote:
> > Hi,
> >
> > As a christmas gift, I'd like to propose a new directory structure
to
> > follow-up on the new web site presentation email I've sent (provided
it
> > is well received on course ;-)).
> >
> > Here's the new structure I'd like to propose:
> >
> > jakarta-cactus
> > |_ anttasks
> > (only keep in this subproject the Ant tasks that are not
related
> > to Cactus. This subproject is expected to disappear over time
as
> > it is expected Ant will provide solutions to perform what we
are
> > doing)
> > |_ framework
> > |_ documentation
> > |_ samples
> > |_ sample-servlet
> > |_ sample-jetty
> > |_ sample-ejb (in the future)
>
> Could drop the "sample-" prefix here.
Sure, +1
>
> > |_ frontends
> > |_ eclipse
> > |_ ant
> > (contains Cactus related Ant tasks such as StartTask,
StopTask,
> > etc and reusable Ant scriptlets for several containers. See
> > the other email entitled "Ant subproject packaging" for more
> > ideas on the artifacts from this subproject)
> >
> > As you can see, it is not a major change but I feel it is time to
start
> > putting these additional directories: "samples" and "frontends" to
> > better compartiment stuff.
> >
> > Do you like this new structure?
>
> +1
>
> Very much. The current folder hierarchy is too flat.
>
> > We really need a good name to describe what I've been calling Front
Ends
> > till now. Is Front End a word you like and find expressive enough?
Do
> > you have a better alternative?
>
> Hmm, "Front End" is indeed not very clear IMHO, but I'm also having a
> hard time thinking of a better term. The only term I can come up with
is
> "integration" as a directory name, i.e. integration/ant,
> integration/eclipse. But I don't like that very much either.
Yeah, I thought about that one too but I'm not completely happy with it.
It sounds not too bad as a directory name but not very good as a
functional subsystem name. I like "Cactus Runners" (although it comes
from JUnit). They really are integration front ends that act as cactus
enablers/activators/runners/etc.
Or shall we come up with a nice Cactish name ... :-) humm, let's see ...
What about "Spines". We have the core framework which is the bulk of the
Cactus and then several Spines which grow out of the core to activate
it!
I'm writing this email while flying across the world (London-Mumbai) and
I don't have an internet connection available for look for other cactish
names... That will have to wait but I'm sure we can find some nice
terminology revolving around cactus, if you like the idea of course.
I kinda like Spines though :-)
Ideas?
Thanks
-Vincent
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
>
> --
> To unsubscribe, e-mail: <mailto:cactus-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] New directory structure?
Posted by Christopher Lenz <cm...@gmx.de>.
Hi Vincent,
Vincent Massol wrote:
> Hi,
>
> As a christmas gift, I'd like to propose a new directory structure to
> follow-up on the new web site presentation email I've sent (provided it
> is well received on course ;-)).
>
> Here's the new structure I'd like to propose:
>
> jakarta-cactus
> |_ anttasks
> (only keep in this subproject the Ant tasks that are not related
> to Cactus. This subproject is expected to disappear over time as
> it is expected Ant will provide solutions to perform what we are
> doing)
> |_ framework
> |_ documentation
> |_ samples
> |_ sample-servlet
> |_ sample-jetty
> |_ sample-ejb (in the future)
Could drop the "sample-" prefix here.
> |_ frontends
> |_ eclipse
> |_ ant
> (contains Cactus related Ant tasks such as StartTask, StopTask,
> etc and reusable Ant scriptlets for several containers. See
> the other email entitled "Ant subproject packaging" for more
> ideas on the artifacts from this subproject)
>
> As you can see, it is not a major change but I feel it is time to start
> putting these additional directories: "samples" and "frontends" to
> better compartiment stuff.
>
> Do you like this new structure?
+1
Very much. The current folder hierarchy is too flat.
> We really need a good name to describe what I've been calling Front Ends
> till now. Is Front End a word you like and find expressive enough? Do
> you have a better alternative?
Hmm, "Front End" is indeed not very clear IMHO, but I'm also having a
hard time thinking of a better term. The only term I can come up with is
"integration" as a directory name, i.e. integration/ant,
integration/eclipse. But I don't like that very much either.
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>