webmacro-devel — Discuss development issues related to the core of WebMacro

Re: [Webmacro-devel] Next steps towards a WebMacro 2.2

[Guy B. K. <gu...@wa...>]

On 25 Feb 2010, at 21:13, Tim Pizey wrote:

> Thanks Guy.
> 
> Does that mean that the latest build works for you?

$ mvn install

...passes all unit tests and sticks a jar in targets/.  I'm no maven expert, but my ~/.m2/settings.xml is empty, so that should mean I have a fairly vanilla maven setup, yes?  I haven't tested the jar against any of our current projects yet.

Guy.

Re: [Webmacro-devel] Next steps towards a WebMacro 2.2

[Tim P. <ti...@pa...>]

Thanks Guy.

Does that mean that the latest build works for you?

cheers
Tim


On 25 February 2010 19:36, Guy Bolton King  wrote:
>
> On 21 Feb 2010, at 16:02, Tim Pizey wrote:
>>
>> The CVS tree has been reorganised
>
> Hi all: the reorganised webmacro tree didn't appear to have a tag marking the point of reorganisation.  I've added a webmacro-2_2-repo-layout-change tag on 2010-02-20 23:30:07, just for the record.
>
> Regards,
>
> Guy.
>
>

Re: [Webmacro-devel] Ant build running, last call to preserve logging

[Tim P. <ti...@pa...>]

Hi, 
On Tuesday 23 February 2010 23:40:49 I wrote:
> 
> Locally I have ripped out WebMacro's own logging.
> Whilst it was very cool and prefigured many of the ideas which
> have now become standard I think we should go with slf4j.
> Unless there is a reason not too I will commit this change tomorrow night.

Committed.
 
> Then plan to remove Base64 and anything else which is not used in
> WebMacro or is now part of either java or a standard Apache commons project.

Site built and artefacts deployed. 
Test coverage now at 55% overall, 43% for util
http://webmacro.sourceforge.net/cobertura/index.html
This will actually go down when Base64 is deleted, as Base64 is quite well tested. 
However another important metric will come down: number of classes and number of lines. 

There is a little issue with web.sourceforge .net
I could not use scp to deploy to it, as you can with shell.sourceforge.net, but you can use sftp. 

I have put a note in the pom about automating the deployment of the project files. 
What files should the project be releasing? 

cheers
Tim



-- 
We are in dialogue.

Re: [Webmacro-devel] Next steps towards a WebMacro 2.2

[Guy B. K. <gu...@wa...>]

On 21 Feb 2010, at 16:02, Tim Pizey wrote:
> 
> The CVS tree has been reorganised

Hi all: the reorganised webmacro tree didn't appear to have a tag marking the point of reorganisation.  I've added a webmacro-2_2-repo-layout-change tag on 2010-02-20 23:30:07, just for the record.

Regards,

Guy.

Re: [Webmacro-devel] Ant build running, last call to preserve logging

[Endre S. <Endre@Stolsvik.com>]

2010/2/24 Tim Pizey <ti...@pa...>

> Hi Endre,
>
> But you do agree with the removal of WebMacro's own logging
> don't you? I removed it at your suggestion.
>

Yes. That was as a replacement for commons logging, I presumed. Furthermore,
logging is something many web frameworks set up, and one should just slide
along with the existing system. Which is fixed by the logic of slf4j (as was
supposedly fixed by commons loggings, but at a often huge cost of not
understanding anything of your systems's weird behaviours).


>
> I know that WebMacro's own Base64 has a bug.
> Which illustrates why I do not agree with your view that each project
> should
> contain its own copy of everything.
>
> The specialists should maintain the things that they are interested in:
> concurrency, logging, http etc.
>

This is really not that much of a specialist system - it is a single class.
Copy the class from commons, give it a new namespace. Update it when time
permits.

That is what one should have done with the concurrent stuff - which is what
GlazedLists have done (they actually use a wrapper system, whereby
ReadWriteLocks use the own namespaced concurrent if on pre 1.5 systems, and
the JDK version if after).

This is what several frameworks do these days - check out Guice with their
own namespaced proxy making stuff (asm, was it? I don't know, because I
don't care - as I don't have to handle a version of that stupid thing to
have Guice work).

And you contribute to dll hell by doing this. What if I need a newer version
of that library in some three years time - where they have changed around on
some of the packages and names? Then you have made a dependency on ONE
class, but an ENTIRE jar - and I am fubared. Because of one class.


>
> If you want to see a project which follows your idea see eXist: they too
> have their own Base64 encoder and, ultimate proof, their own IRC client,
> (inside an xml database!)
>

I really fail to see the problem. Azureus also have their own irc client. It
is not meant as a fullscale IRC client - more a help channel while using
that program.


Endre.


> On Wednesday 24 February 2010 01:20:52 Endre Stølsvik wrote:
> > Personally, I'm not too fond of depending on Apache's Commons stuff (or
> > anything else for that matter), if you actually mean to depend on it for
> > more than some optional feature ( - and not even then, IMO). We're
> talking
> > about a couple of small classes? It would be sad to have one more
> dependency
> > just for something like that. Rip the class out and embed it instead - in
> > particular if we're talking about something like a base 64 encoder.
> >
> > Btw, here's a take on Maven, since you don't like ant yourself:
> >   http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html
> >
> > :-)
> >
> > Kind regards,
> > Endre.
> >
> > On Wed, Feb 24, 2010 at 00:40, Tim Pizey  wrote:
> >
> > > Hi,
> > >
> > > Both the ant (spit!!) and maven builds are now running out of trunk.
> > > http://hudson.paneris.net/job/webmacro_ant/34/console
> > >
> > > Locally I have ripped out WebMacro's own logging.
> > > Whilst it was very cool and prefigured many of the ideas which
> > > have now become standard I think we should go with slf4j.
> > > Unless there is a reason not too I will commit this change tomorrow
> night.
> > >
> > > Then plan to remove Base64 and anything else which is not used in
> > > WebMacro or is now part of either java or a standard Apache commons
> > > project.
> > >
> > > cheers
> > > Tim
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > Download Intel&#174; Parallel Studio Eval
> > > Try the new software tools for yourself. Speed compiling, find bugs
> > > proactively, and fine-tune applications for parallel performance.
> > > See why Intel Parallel Studio got high marks during beta.
> > > http://p.sf.net/sfu/intel-sw-dev
> > > _______________________________________________
> > > Webmacro-devel mailing list
> > > Web...@li...
> > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > >
> >
>
> --
> We are in dialogue.
>

[Webmacro-devel] Maven vs ant [was Re: Ant build running, last call to preserve logging]

[Tim P. <ti...@pa...>]

Hi Endre,

OK, I'll bite...

2010/2/24 Endre Stølsvik :
> Btw, here's a take on Maven, since you don't like ant yourself:
>   http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html
> :-)


I have read that, though there was little point after the first sentence:
"The best build tool is the one you write yourself".
It boils down to a rant "I do not understand Maven, I like to write
all the code."

This is not the attitude I want in a developer on an open source project and
I would be very worried about it in a paying project.


The modular, packaged, nature of java is deliberate. It enables programmers
to specialise. Specialisation being one of the main tools of advancement in
civilisation. Maven is a build tool, Ant is  a language (written in xml).

Generalists are good in the wilderness, no use to anyone anywhere else.

cheers
Tim

Re: [Webmacro-devel] Ant build running, last call to preserve logging

[Tim P. <ti...@pa...>]

Hi Endre, 

But you do agree with the removal of WebMacro's own logging
don't you? I removed it at your suggestion. 

I know that WebMacro's own Base64 has a bug.
Which illustrates why I do not agree with your view that each project should 
contain its own copy of everything. 

The specialists should maintain the things that they are interested in: 
concurrency, logging, http etc. 

If you want to see a project which follows your idea see eXist: they too 
have their own Base64 encoder and, ultimate proof, their own IRC client, 
(inside an xml database!) 

And of course the Windows Word with its own email client, I could go on. 

cheers
Tim



On Wednesday 24 February 2010 01:20:52 Endre Stølsvik wrote:
> Personally, I'm not too fond of depending on Apache's Commons stuff (or
> anything else for that matter), if you actually mean to depend on it for
> more than some optional feature ( - and not even then, IMO). We're talking
> about a couple of small classes? It would be sad to have one more dependency
> just for something like that. Rip the class out and embed it instead - in
> particular if we're talking about something like a base 64 encoder.
> 
> Btw, here's a take on Maven, since you don't like ant yourself:
>   http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html
> 
> :-)
> 
> Kind regards,
> Endre.
> 
> On Wed, Feb 24, 2010 at 00:40, Tim Pizey  wrote:
> 
> > Hi,
> >
> > Both the ant (spit!!) and maven builds are now running out of trunk.
> > http://hudson.paneris.net/job/webmacro_ant/34/console
> >
> > Locally I have ripped out WebMacro's own logging.
> > Whilst it was very cool and prefigured many of the ideas which
> > have now become standard I think we should go with slf4j.
> > Unless there is a reason not too I will commit this change tomorrow night.
> >
> > Then plan to remove Base64 and anything else which is not used in
> > WebMacro or is now part of either java or a standard Apache commons
> > project.
> >
> > cheers
> > Tim
> >
> >
> > ------------------------------------------------------------------------------
> > Download Intel® Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Webmacro-devel mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >
> 

-- 
We are in dialogue.

Re: [Webmacro-devel] Ant build running, last call to preserve logging

[Endre S. <Endre@Stolsvik.com>]

Personally, I'm not too fond of depending on Apache's Commons stuff (or
anything else for that matter), if you actually mean to depend on it for
more than some optional feature ( - and not even then, IMO). We're talking
about a couple of small classes? It would be sad to have one more dependency
just for something like that. Rip the class out and embed it instead - in
particular if we're talking about something like a base 64 encoder.

Btw, here's a take on Maven, since you don't like ant yourself:
  http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html

:-)

Kind regards,
Endre.

On Wed, Feb 24, 2010 at 00:40, Tim Pizey <ti...@pa...> wrote:

> Hi,
>
> Both the ant (spit!!) and maven builds are now running out of trunk.
> http://hudson.paneris.net/job/webmacro_ant/34/console
>
> Locally I have ripped out WebMacro's own logging.
> Whilst it was very cool and prefigured many of the ideas which
> have now become standard I think we should go with slf4j.
> Unless there is a reason not too I will commit this change tomorrow night.
>
> Then plan to remove Base64 and anything else which is not used in
> WebMacro or is now part of either java or a standard Apache commons
> project.
>
> cheers
> Tim
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>

[Webmacro-devel] Ant build running, last call to preserve logging

[Tim P. <ti...@pa...>]

Hi,

Both the ant (spit!!) and maven builds are now running out of trunk.
http://hudson.paneris.net/job/webmacro_ant/34/console

Locally I have ripped out WebMacro's own logging.
Whilst it was very cool and prefigured many of the ideas which
have now become standard I think we should go with slf4j.
Unless there is a reason not too I will commit this change tomorrow night.

Then plan to remove Base64 and anything else which is not used in
WebMacro or is now part of either java or a standard Apache commons project.

cheers
Tim

Re: [Webmacro-devel] New committer

[Eric B. R. <eb...@tc...>]

On Feb 21, 2010, at 6:39 PM, Tim Pizey wrote:

> I have set myself as the admin for each of the lists. 

/hug

eric

Re: [Webmacro-devel] New committer

[Tim P. <ti...@pa...>]

On Thursday 18 February 2010 00:04:12 Eric B. Ridge wrote:
> 
> If I'm still a SF admin (drater), then I've got access to the mailing lists.  
> It'll take me awhile to try and remember the password I set, but once I do, 
> I'm happy to relinquish power to someone else more interested in WM's future.
 

I have set myself as the admin for each of the lists. 

cheers
Tim


-- 
We are in dialogue.

[Webmacro-devel] Logging was Re: Next steps towards a WebMacro 2.2

[Tim P. <ti...@pa...>]

On Sunday 21 February 2010 16:25:13 Endre Stølsvik wrote:
> Commons logging apparently have a bunch of hard-to-debug problems when used
> in servlet container environments (to do with the classloader and the fact
> that "clogging" finds the actual logging sink by dynamically inspecting the
> current runtime context, which not always is a good thing), which lead the
> log4j guy to make "slf4j", Simple Logging Facade For Java. This latter thing
> uses static linking - you simply insert your selected brand of the slfj4 jar
> in the classpath: If you stick the log4j slf4j jar in your classpath, you
> will get output through log4j.
> 
> http://www.slf4j.org/
> 
> He also made "logback", which is his intended log4j replacement. (He didn't
> like how log4j was going, and started afresh on both these problems: The
> logging facade as in commons logging, and the actual log system, as in
> log4j).
> 
> Logback (and an even simpler system called "simple") obviously natively
> implement the slf4j interfaces, while the other slf4j jars are razor-think
> shims that simply call through to the selected log system: log4j or Java
> 1.4's own logging system.
> 
> 
> This is a novel and dead simple idea which I like: You have to insert a jar
> there anyway. The deal here is that you for this one library have four
> different jars to select from, and that selection decides your log sink.
> 
> Endre.

I have converted to slf4j and will commit unless strong objections. 

cheers
Tim


-- 
We are in dialogue.

Re: [Webmacro-devel] Next steps towards a WebMacro 2.2

[Endre S. <Endre@Stolsvik.com>]

Personally, I don't use WebMacro now. But here's a wish list I remember I
had when I did, some of which might still be valid.

1) Make it possible to completely configure the thing in code, letting the
properties-BS just be an option that you can "wire in" if you like that way
of config (which I obviously don't). This has become even more relevant in
these days of Guice and these new-school thoughts of how to wire systems up.

2) I get annoyed with "simple libraries" that suddenly start to fork off
threads without me asking for it. There is or was one "clock thread" that
utterly absurdly was made as a performance optimization to not have to
invoke System.millis that often, for logging, I believe?? This is the
absolute peak of premature optimization IMHO, and pollutes the system. Also,
the "reload templates" thread is pure evil of nearly no use whatsoever after
the development period. Instead it should be possible to programmatically
dump the cache, or possibly check for newness, by invoking some method. One
could then make a little servlet that one could invoke to have the cache
cleaned, or whatever.

3) The cache should be a plug-in architecture.

4) Even the cache-loading should be plug-in - here's the string requested,
here's the current context (which includes path and name of the current
template), get me the new template. (I guess the latter two could be one
unit?)

So basically: Have WebMacro be as thin and lean and mean as possible, not
trying to make "a web development framework", but instead just focus on its
core: Merge a template and a context. All other niceties should be
pluggable.

Well, that was loose, and possibly all is already implemented.

Regards,
Endre.

On Sun, Feb 21, 2010 at 17:02, Tim Pizey <ti...@pa...> wrote:

> Hi all,
>
> I have pretty much scratched my itches:
>
> WebMacro now only has one dependency: commons-logging
> I am no expert on logging, is commons-logging 'the one' to use?
>
> The CVS tree has been reorganised
>
> The Maven build works, with all tests passing.
>
> Further things to do before rolling out 2.2:
>
> 1. Update all code to use generics
> 2. Use Collections
> 3. Use 1.4 Exception handling
> 4. Review TODO and FIXME tags given at
> http://webmacro.sourceforge.net/taglist.html
> 5. Review code coverage given at
> http://webmacro.sourceforge.net/cobertura/index.html and
> http://melati.org/melati/cobertura/index.html
> 6. Delete unused code:
> eg org.webmacro.util.Base64
> 7. Wire in javacc plugin to maven build
> 8. Check Ant build and delete
>
> However there is a lot of other work that could be done:
>
> 1. Move all project site code and documentation up to top level
> 2. Revisit configuration, so that properties files do not pollute default
> namespace.
> 3. Create Maven plugin to convert from WM to Velocity
> 4. And back again
> 5. Proper time tests against Velocity and Framemaker
>
>
> err  I'll stop now,  think I am getting carried away
> but if anyone wants to pile in to any of the above that would be great.
>
> cheers
> Tim
>
>
>
>
>
> --
> We are in dialogue.
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>

Re: [Webmacro-devel] Next steps towards a WebMacro 2.2

[Endre S. <Endre@Stolsvik.com>]

Commons logging apparently have a bunch of hard-to-debug problems when used
in servlet container environments (to do with the classloader and the fact
that "clogging" finds the actual logging sink by dynamically inspecting the
current runtime context, which not always is a good thing), which lead the
log4j guy to make "slf4j", Simple Logging Facade For Java. This latter thing
uses static linking - you simply insert your selected brand of the slfj4 jar
in the classpath: If you stick the log4j slf4j jar in your classpath, you
will get output through log4j.

http://www.slf4j.org/

He also made "logback", which is his intended log4j replacement. (He didn't
like how log4j was going, and started afresh on both these problems: The
logging facade as in commons logging, and the actual log system, as in
log4j).

Logback (and an even simpler system called "simple") obviously natively
implement the slf4j interfaces, while the other slf4j jars are razor-think
shims that simply call through to the selected log system: log4j or Java
1.4's own logging system.


This is a novel and dead simple idea which I like: You have to insert a jar
there anyway. The deal here is that you for this one library have four
different jars to select from, and that selection decides your log sink.

Endre.

On Sun, Feb 21, 2010 at 17:02, Tim Pizey <ti...@pa...> wrote:

> Hi all,
>
> I have pretty much scratched my itches:
>
> WebMacro now only has one dependency: commons-logging
> I am no expert on logging, is commons-logging 'the one' to use?
>
> The CVS tree has been reorganised
>
> The Maven build works, with all tests passing.
>
> Further things to do before rolling out 2.2:
>
> 1. Update all code to use generics
> 2. Use Collections
> 3. Use 1.4 Exception handling
> 4. Review TODO and FIXME tags given at
> http://webmacro.sourceforge.net/taglist.html
> 5. Review code coverage given at
> http://webmacro.sourceforge.net/cobertura/index.html and
> http://melati.org/melati/cobertura/index.html
> 6. Delete unused code:
> eg org.webmacro.util.Base64
> 7. Wire in javacc plugin to maven build
> 8. Check Ant build and delete
>
> However there is a lot of other work that could be done:
>
> 1. Move all project site code and documentation up to top level
> 2. Revisit configuration, so that properties files do not pollute default
> namespace.
> 3. Create Maven plugin to convert from WM to Velocity
> 4. And back again
> 5. Proper time tests against Velocity and Framemaker
>
>
> err  I'll stop now,  think I am getting carried away
> but if anyone wants to pile in to any of the above that would be great.
>
> cheers
> Tim
>
>
>
>
>
> --
> We are in dialogue.
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>

[Webmacro-devel] Next steps towards a WebMacro 2.2

[Tim P. <ti...@pa...>]

Hi all, 

I have pretty much scratched my itches: 

WebMacro now only has one dependency: commons-logging 
I am no expert on logging, is commons-logging 'the one' to use?

The CVS tree has been reorganised

The Maven build works, with all tests passing. 

Further things to do before rolling out 2.2: 

1. Update all code to use generics
2. Use Collections 
3. Use 1.4 Exception handling
4. Review TODO and FIXME tags given at http://webmacro.sourceforge.net/taglist.html
5. Review code coverage given at http://webmacro.sourceforge.net/cobertura/index.html and 
http://melati.org/melati/cobertura/index.html
6. Delete unused code: 
eg org.webmacro.util.Base64
7. Wire in javacc plugin to maven build
8. Check Ant build and delete

However there is a lot of other work that could be done: 

1. Move all project site code and documentation up to top level
2. Revisit configuration, so that properties files do not pollute default namespace. 
3. Create Maven plugin to convert from WM to Velocity
4. And back again 
5. Proper time tests against Velocity and Framemaker


err  I'll stop now,  think I am getting carried away 
but if anyone wants to pile in to any of the above that would be great. 

cheers
Tim





-- 
We are in dialogue.

Re: [Webmacro-devel] Upgrading to java.util.concurrent

[Tim P. <ti...@pa...>]

Thanks Brian, 

That was what I needed.

All tests passing again now. 

Tim


On Sunday 21 February 2010 02:15:44 Brian Goetz wrote:
> ClockDaemon became ScheduledExecutorService.
> 
> On 2/20/2010 9:05 PM, Tim Pizey wrote:
> > Hi,
> >
> > It turns out not to be completely straight forward.
> >
> > ClockDaemon did not make it into java.util.concurrent,
> > and java.util.Timer is not a straight swap, so ReloadingCacheManager
> > currently does not compile.
> >
> > If anyone has already traveled this road please let me know.
> >
> > cheers
> > Tim
> >
> >
> 
> 

-- 
We are in dialogue.

[Webmacro-devel] Love it that something is happening

[Marcello H <mar...@gm...>]

Hey dudes,

I love it that some people still using WM, and willing to spend some
development time in this.
My compliments. If I have some time, I can check if my stuff still works,
based on the newest development.

Keep up the good work :-)

Greetings from Holland,
Marcel

Re: [Webmacro-devel] Upgrading to java.util.concurrent

[Brian G. <br...@br...>]

ClockDaemon became ScheduledExecutorService.

On 2/20/2010 9:05 PM, Tim Pizey wrote:
> Hi,
>
> It turns out not to be completely straight forward.
>
> ClockDaemon did not make it into java.util.concurrent,
> and java.util.Timer is not a straight swap, so ReloadingCacheManager
> currently does not compile.
>
> If anyone has already traveled this road please let me know.
>
> cheers
> Tim
>
>

[Webmacro-devel] Upgrading to java.util.concurrent

[Tim P. <ti...@pa...>]

Hi, 

It turns out not to be completely straight forward. 

ClockDaemon did not make it into java.util.concurrent, 
and java.util.Timer is not a straight swap, so ReloadingCacheManager
currently does not compile. 

If anyone has already traveled this road please let me know. 

cheers
Tim


-- 
We are in dialogue.

Re: [Webmacro-devel] PayPal ID Changed

[Tim P. <ti...@pa...>]

Hi, 

I just got these two messages: 

On Saturday 20 February 2010 23:54:22 SourceForge.net wrote:
> Hello,
> 
> This message is being sent to all members of the WebMacro project.
> 
> The PayPal ID used to receive donations has been changed to "" by timp.
> 
> Thanks,
> The SourceForge.net Crew
> 
> 

and also 

> Hello,
> 
> This message is being sent to all members of the WebMacro project.
> 
> This project is no longer receiving donations.
> 
> Thanks,
> The SourceForge.net Crew
> 

They were as a result of me opting in to donations, I am the only Admin who has, 
as far as the site told me. 

If I have just severed a vital income stream let me know, but I think that these emails were sent in error.
 

If you want to opt in then please do. 


cheers
Tim



-- 
We are in dialogue.

[Webmacro-devel] Progress so far

[Tim P. <ti...@pa...>]

Hi, 

I now have all tests running and passing under Maven, ant and eclipse. 

I have committed my changes, tagged(twice).
Regenerated and redeployed site to http://webmacro.sourceforge.net
Deployed current snapshot to  http://webmacro.sourceforge.net/maven2
Uploaded 2.1 binaries to sourceforge

This should draw a line under 2.1

I have tagged and updated pom so we are now at 2.2-SNAPSHOT whic means we are aiming towards a 2.2 release. 

To this end I have backup up the CVS repository and then used the sourceforge repoAdmin tool 
to start to restructure the CVS tree. 

A complete copy of the original structure is in /original 

then the structure is 
webmacro
  contrib
    Added Tools
    Added Adaptors
   Added OpenDoor
  webmacro
   src
      main
         java
      test
        java
  wiki


I has nearly finished, but sourceforge shutdown on me, 
so had to repeat. 

There is a lot now that can be done, but my aim would be to get a very lean, 
minimal WebMacro out. 

cheers
Tim





cheers
tim







-- 
We are in dialogue.

Re: [Webmacro-devel] Semantics of class instantiation in set properties

[Tim P. <ti...@pa...>]

Hi,
On 19 February 2010 01:39, I wrote:
>
> PS can't get ant to work on the build machine (debian etch with ant-optional installed) but all works at home

I ended up copying webmacro/lib/junit.jar to
/usr/share/ant/lib/ant-junit.jar which fixed the problem:

http://hudson.paneris.net/job/webmacro_ant/

cheers
Tim

Re: [Webmacro-devel] Semantics of class instantiation in set properties

[Endre S. <Endre@Stolsvik.com>]

Maybe somehow document what classes should be in the set (if un-nulled) to
ensure basic operation of the system (basic collection implementations,
String?), *at least* for webmacro itself (like your example
SparseProperties)?

Regards,
Endre.

2010/2/19 Tim Pizey <ti...@pa...>

> Endre,
>
> Thank you for this.
>
> The bean directive, for example, expects to be able to create
> org.webmacro.util.SparseProperties.
>
> What you say is plausible, so I will write it into the javadoc and
> ensure it with tests.
>
> cheers
> Tim
>
>
>
> 2010/2/19 Endre Stølsvik <En...@st...>:
> > Are you sure this wasn't for backwards compatibility? I do vaguely
> remember
> > this interest in security at some point - and I think this was the
> solution.
> > At least you will probably kill most everything out there if you change
> it
> > you suggest now. And I do actually find it somewhat reasonable as it
> stands
> > - by default, this is an open system, which probably will be just fine
> for,
> > circa, 99.99% of use cases. But if you want, you can lock it down. I
> wonder
> > if this wasn't thought about for some shared hosting scenarios or
> whatever?
> > Maybe some search through list archive could shed light on it?
> > Kind regards,
> > Endre.
> >
> > On Fri, Feb 19, 2010 at 02:39, Tim Pizey <ti...@pa...> wrote:
> >>
> >> Hi,
> >>
> >>
> >> The current semantics of class instantiation in the Setprops directive
> are
> >> a bit odd:
> >>
> >> If the property org.webmacro.AllowedPackages is null then any class may
> be
> >> instantiated.
> >>
> >> If it is not empty then it must contain the package of the class you are
> >> trying to instantiate.
> >>
> >> I think that this is a bug.
> >>
> >> The test TestSetpropsDirective was failing when run through Maven but
> >> passing in Eclipse.
> >> I have set the Maven tests to fork pertest and all tests pass.
> >>
> >> However this was a bad smell, so I have fished around and made the test
> so
> >> that they
> >> no longer interfere with each other.  (Well they are in an order so that
> >> they don't)
> >>
> >> So the current failing test illustrates that we have no restrictions on
> >> what classes are instantiated
> >> using the setprops directive.
> >>
> >> I think the desired behavior is for a default set of packages to be
> >> allowed (java.util, java.lang, org.webmacro.util)
> >> and for these also to be implied packages, ie you can refer to them
> >> without a full classname: just using HashMap or Exception
> >>
> >> If you alter the configuation then you must explicitly specify all
> >> packages, including the default.
> >> This can be used to disallow even the default packages.
> >> If you try to instantiate any other classes that will be disallowed.
> >>
> >>
> >> Does this make sense?
> >> Tim
> >>
> >> PS can't get ant to work on teh build machine (debian etch with
> >> ant-optional installed) but all works at home
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> We are in dialogue.
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Download Intel&#174; Parallel Studio Eval
> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> proactively, and fine-tune applications for parallel performance.
> >> See why Intel Parallel Studio got high marks during beta.
> >> http://p.sf.net/sfu/intel-sw-dev
> >> _______________________________________________
> >> Webmacro-devel mailing list
> >> Web...@li...
> >> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Webmacro-devel mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >
> >
>

Re: [Webmacro-devel] Semantics of class instantiation in set properties

[Tim P. <ti...@pa...>]

Endre,

Thank you for this.

The bean directive, for example, expects to be able to create
org.webmacro.util.SparseProperties.

What you say is plausible, so I will write it into the javadoc and
ensure it with tests.

cheers
Tim



2010/2/19 Endre Stølsvik <En...@st...>:
> Are you sure this wasn't for backwards compatibility? I do vaguely remember
> this interest in security at some point - and I think this was the solution.
> At least you will probably kill most everything out there if you change it
> you suggest now. And I do actually find it somewhat reasonable as it stands
> - by default, this is an open system, which probably will be just fine for,
> circa, 99.99% of use cases. But if you want, you can lock it down. I wonder
> if this wasn't thought about for some shared hosting scenarios or whatever?
> Maybe some search through list archive could shed light on it?
> Kind regards,
> Endre.
>
> On Fri, Feb 19, 2010 at 02:39, Tim Pizey <ti...@pa...> wrote:
>>
>> Hi,
>>
>>
>> The current semantics of class instantiation in the Setprops directive are
>> a bit odd:
>>
>> If the property org.webmacro.AllowedPackages is null then any class may be
>> instantiated.
>>
>> If it is not empty then it must contain the package of the class you are
>> trying to instantiate.
>>
>> I think that this is a bug.
>>
>> The test TestSetpropsDirective was failing when run through Maven but
>> passing in Eclipse.
>> I have set the Maven tests to fork pertest and all tests pass.
>>
>> However this was a bad smell, so I have fished around and made the test so
>> that they
>> no longer interfere with each other.  (Well they are in an order so that
>> they don't)
>>
>> So the current failing test illustrates that we have no restrictions on
>> what classes are instantiated
>> using the setprops directive.
>>
>> I think the desired behavior is for a default set of packages to be
>> allowed (java.util, java.lang, org.webmacro.util)
>> and for these also to be implied packages, ie you can refer to them
>> without a full classname: just using HashMap or Exception
>>
>> If you alter the configuation then you must explicitly specify all
>> packages, including the default.
>> This can be used to disallow even the default packages.
>> If you try to instantiate any other classes that will be disallowed.
>>
>>
>> Does this make sense?
>> Tim
>>
>> PS can't get ant to work on teh build machine (debian etch with
>> ant-optional installed) but all works at home
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> We are in dialogue.
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Webmacro-devel mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>

Re: [Webmacro-devel] Semantics of class instantiation in set properties

[Endre S. <Endre@Stolsvik.com>]

Are you sure this wasn't for backwards compatibility? I do vaguely remember
this interest in security at some point - and I think this was the solution.
At least you will probably kill most everything out there if you change it
you suggest now. And I do actually find it somewhat reasonable as it stands
- by default, this is an open system, which probably will be just fine for,
circa, 99.99% of use cases. But if you want, you can lock it down. I wonder
if this wasn't thought about for some shared hosting scenarios or whatever?

Maybe some search through list archive could shed light on it?

Kind regards,
Endre.

On Fri, Feb 19, 2010 at 02:39, Tim Pizey <ti...@pa...> wrote:

> Hi,
>
>
> The current semantics of class instantiation in the Setprops directive are
> a bit odd:
>
> If the property org.webmacro.AllowedPackages is null then any class may be
> instantiated.
>
> If it is not empty then it must contain the package of the class you are
> trying to instantiate.
>
> I think that this is a bug.
>
> The test TestSetpropsDirective was failing when run through Maven but
> passing in Eclipse.
> I have set the Maven tests to fork pertest and all tests pass.
>
> However this was a bad smell, so I have fished around and made the test so
> that they
> no longer interfere with each other.  (Well they are in an order so that
> they don't)
>
> So the current failing test illustrates that we have no restrictions on
> what classes are instantiated
> using the setprops directive.
>
> I think the desired behavior is for a default set of packages to be allowed
> (java.util, java.lang, org.webmacro.util)
> and for these also to be implied packages, ie you can refer to them without
> a full classname: just using HashMap or Exception
>
> If you alter the configuation then you must explicitly specify all
> packages, including the default.
> This can be used to disallow even the default packages.
> If you try to instantiate any other classes that will be disallowed.
>
>
> Does this make sense?
> Tim
>
> PS can't get ant to work on teh build machine (debian etch with
> ant-optional installed) but all works at home
>
>
>
>
>
>
>
>
>
>
>
>
> --
> We are in dialogue.
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>