melati-developers — Discussion of the development of Melati

[Melati-developers] WebMacro usage by Melati

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

Hi, 

I have hooked WebMacro up to Melati in such a way that the Melati tests illustrate the amount of 
WebMacro used by Melati. 

http://melati.org/melati/cobertura/index.html

The itch that I am aiming to scratch is that WebMacro forces a dependency upon Spring and Ant upon Melati. 

http://melati.org/melati/dependencies.html

Similarly I have removed my dependency upon concurrent.jar, but WebMacro drags it in. 

So my plan is to remove (or move to a sub-project) org.webmacro.adapter.* and org.webmacro.tools

Is anyone currently using these?

I hope to find the time to remove the dependency upon concurrent.jar. 

This would leave us solely dependent upon commons-logging and servlet-api.

Don't hold your breath. 

cheers
Tim









-- 
We are in dialogue.

Re: [Melati-developers] Current state of Velocity tests

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

On Wednesday 03 February 2010 08:41:20 James Wright wrote:
> Hi Tim,
> 
> Here is a plan but I don't think it necessarily starts now ;-)

[snip]

Cool. 
I do not pretend to understand. 

I have found this:

http://mojo.codehaus.org/unix/index.html

which I will have a play with. 

Lets talk on irc/google chat (tim.pizey) 

My tasks are: 

Finish checking translation of WebMacro templates to Velocity templates
Setup Hudson for all Melati projects
Change the template path to be a single directory for all template engines. 
Add  a set of Atom templates to enable an Atom view of a DB
See what we use of WebMacro and roll out a new version only containing that.


cheers
Tim

-- 
We are in dialogue.

Re: [Melati-developers] Current state of Velocity tests

[James W. <ji...@wr...>]

Hi Tim,

Here is a plan but I don't think it necessarily starts now ;-)

1 Instead of starting with a Melati-0-7-8-RC2 tarball, start with a trunk
tarball (hopefully a Melati artifact but the details elude me).
2 Try getting it to build by adding an rpmbuild patch generated from CVS (or
by comparing checkouts) that rolls everything back to Melati-0-7-8-RC2.
There is no doubt it will build, but I might move onto steps 3 and 4 before
committing anything...
3 Fairly rapidly remove large junks of that patch and some other existing
patches (which go forwards from Melati-0-7-8-RC2). Perhaps get poem up to
HEAD first.
4 Refactor the remains into a few small patches e.g.
etc/rpmbuild/fedora/SOURCES/melati-rollback-to-velocity-1.4.patch.
5 Consider changes on the HEAD to reduce the number of rpmbuild patches e.g.
roll back to 1.4

But by the time I get to step 5 Velocity 1.5+ will probably be available for
Fedora. Still, it is nice to know we have options. Thanks.

Jim

On 3 February 2010 01:18, Tim Pizey <ti...@pa...> wrote:

> Hi Jim,
>
> On Sunday 31 January 2010 23:50:22 Tim Pizey wrote:
> >
> > I have fixed a couple of failing tests in Admin tonight, but I still have
> a few others.
>
> Now all tests passing with Velocity as template engine.
>
> > I do not know what the state of the tests were on your branch, but I
> assume that they are passing for you.
> >
> > Do bare in mind that I fixed some pretty important bugs in Melati, those
> in the caching code,
> > which gave a pretty significant improvement in speed, sometime in 2008.
>
>
> I tried reverting from Velocity 1.5 to 1.4, there are only two minor
> compilation problems,.
> which should have comments in the logs as to why they were made.
>
>
> I do not have a problem with reverting to 1.4, but I do worry about
> anything other than HEAD
> being published.
>
> cheers
> Tim
>
>
> --
> We are in dialogue.
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Melati-developers mailing list
> Mel...@li...
> https://lists.sourceforge.net/lists/listinfo/melati-developers
>

Re: [Melati-developers] Current state of Velocity tests

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

Hi Jim, 

On Sunday 31 January 2010 23:50:22 Tim Pizey wrote:
> 
> I have fixed a couple of failing tests in Admin tonight, but I still have a few others. 

Now all tests passing with Velocity as template engine. 

> I do not know what the state of the tests were on your branch, but I assume that they are passing for you.
> 
> Do bare in mind that I fixed some pretty important bugs in Melati, those in the caching code, 
> which gave a pretty significant improvement in speed, sometime in 2008. 


I tried reverting from Velocity 1.5 to 1.4, there are only two minor compilation problems,. 
which should have comments in the logs as to why they were made. 


I do not have a problem with reverting to 1.4, but I do worry about anything other than HEAD 
being published.

cheers
Tim


-- 
We are in dialogue.

[Melati-developers] Current state of Velocity tests

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

Hi Jim, 

With regard to velocity logging, it looks like what you are doing makes sense, and you are the only user, so fill your boots. 

I have fixed a couple of failing tests in Admin tonight, but I still have a few others. 

I do not know what the state of the tests were on your branch, but I assume that they are passing for you.

Do bare in mind that I fixed some pretty important bugs in Melati, those in the caching code, 
which gave a pretty significant improvement in speed, sometime in 2008. 

cheers
Tim



-- 
We are in dialogue.

Re: [Melati-developers] Location of velocity.log

[James W. <ji...@wr...>]

Hi Tim,

On 31 January 2010 21:00, Tim Pizey <ti...@pa...> wrote:

> Jim,
> I have done some googling, made slightly more difficult by
> Velocity having thrown all their old documentation away :(
>

The old docs and Javadocs are also available for Fedora:-) I installed them
earlier.

My understanding is that you need to create a file called
> velocity.properties which is included in the classpath before velocity.jar.
>
> This file should define the property runtime.log
> see
> http://mail-archives.apache.org/mod_mbox/velocity-user/200501.mbox/%3Cc...@ma...%3E
> eg
> runtime.log=/var/log/apache2/velocity.log
> or
> runtime.log= logs/melati-webapp/velocity.log
>
> but these should not be within any melati properties file, in my view.
>
> Agreed.

I believe we still need a property to specify the location of
velocity.properties or the internal
defaults will be used except for those that we configure programatically in
VelocityTemplateEngine.loadProperties().

I am not completely sure - there is a chance that Velocity looks in some
default place(s)
for such a file, but if so this detail is not well documented. It would also
need to decide how it
should be loaded e.g. as a resource on the classpath, as a file system file
or relative to webapp
root (as seems to be the convention for VelocityServlet e.g.
/WEB-INF/velocity.properties
but otherwise Velocity does not know about any web app).

I said I might use org.apache.velocity.properties in the melati properties
file
but it was a little tricky to make this behave the same way as it does for
VelocityServlet so I decided go for consistency with other Melati config
(despite my reservations about duplicating the package prefix).

I now have a /WEB-INF/classes/velocity.properties specifying:

runtime.log= logs/melati-webapp/velocity.log

This is read if (and only if)
WEB-INF/classes/org/melati/org.melati.MelatiConfig.properties has:

org.melati.MelatiConfig.templateEngineConfig=/velocity.properties

For details of how this works, see the recently committed:

etc/rpmbuild/fedora/SOURCES/melati-velocity-config.patch

Jim

Re: [Melati-developers] Location of velocity.log

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

Jim, 
I have done some googling, made slightly more difficult by 
Velocity having thrown all their old documentation away :(

My understanding is that you need to create a file called 
velocity.properties which is included in the classpath before velocity.jar.

This file should define the property runtime.log 
see http://mail-archives.apache.org/mod_mbox/velocity-user/200501.mbox/%3Cc...@ma...%3E
eg 
runtime.log=/var/log/apache2/velocity.log 
or 
runtime.log= logs/melati-webapp/velocity.log

but these should not be within any melati properties file, in my view.

cheers
Tim
- 
We are in dialogue.

Re: [Melati-developers] Location of velocity.log

[James W. <ji...@wr...>]

Hi again,

On 29 January 2010 00:13, James Wright <ji...@wr...> wrote:

> Hi Tim et al,
>
> I am trying to fix this without a hack:
>
> javax.servlet.ServletException: org.melati.template.TemplateEngineException: org.melati.template.TemplateEngineException
> java.lang.Exception: Unable to configure AvalonLogSystem : java.io.FileNotFoundException: /usr/share/tomcat5/velocity.log (Permission denied)
>
> 	org.melati.servlet.TemplateServlet.init(TemplateServlet.java:90)
>
> It seems that VelocityTemplateEngine.init() ignores the given melatiConfig
> and uses loadConfiguration() to get a trivial set of property definitons
> designed solely to load templates. Effectively:
> resource.loader=class
> class.resource.loader.class=WebMacroClasspathResourceLoader
>

I am not sure my understanding is correct, which is why I am writing.
>
> Anyway, org/melati/org.melati.MelatiConfig.properties defines a set of
> properties org.melati.*.
>
> The number of times org*melati appears in the last sentence has always
> looked to me like some kind of smell but I am not sure. If the aim is that
> we can add lines like this:
> org.apache.velocity.properties=/WEB-INF/conf/velocity.properties
>
> then maybe some of the reduncy makes sense.
>

I think this is still an important question. This would be the first
property in a different package namespace AFAIK and I don't want to start
something unless it is good. But on the other hand, what is the point of a
fixed package prefix?


> OK, my suggestion is to pass the melatiConfig to a new
> loadConfig(Properties p) and add any default property definitons to those in
> the config file.
>

I tried adding:

org.apache.velocity.properties=/WEB-INF/conf/velocity.properties

to:

org/melati/org.melati.MelatiConfig.properties

and adding a getter to MelatiConfig.java so that I could pass the full set
of properties to Velocity. The reason it did not work is probably that
org.apache.velocity.properties is understood by:

org.apache.velocity.servlet.VelocityServlet

but not by:

org.apache.velocity.app.Velocity

However, I got it working with a second dirty hack. I added this to
MelatiConfig.properties:

runtime.log = logs/melati-webapp/velocity.log

So my preferred solution now is to borrow the convention used by
VelocityServlet. We need to be able to configure velocity but we don't want
such properties in MelatiConfig.properties except possibly if they are
namespace protected. So we allow:

org.apache.velocity.properties=/WEB-INF/conf/velocity.properties

and if that is specified we read the configured file and pass the properties
to org.apache.velocity.app.Velocity.

If this works (or something else does) the first step will be to commit it
in a patch trunk/etc/rpmbuild/fedora/SOURCES/melati-velocity-config.patch.

I am fairly sure we to need something similar on the trunk. That is, we want
to be able to configure Velocity and so Melati developers are not stuck with
the defaults for things such as runtime.log. But one step at a time.

Jim

Re: [Melati-developers] Location of velocity.log

[James W. <ji...@wr...>]

Hi Tim,

On 31 January 2010 12:18, Tim Pizey <ti...@pa...> wrote:

> On Saturday 30 January 2010 21:27:23 James Wright wrote:
> > Hi Tim,
> >
> > To clarify, this is not a test failure. It is what happens when you
> install
> > melati-webapp in the standard place on Fedora (using the RPM based on
> > trunk/etc/rpmbuild/fedora).
>
> Yes, I understand that.
>
> > So the RPM I have specified installs melati-webapp.war in
> > /usr/share/tomcat5/webapps which is a symlink to
>  /var/lib/tomcat5/webapps
> > but tomcat's PWD is /usr/share/tomcat5 so this is where it tries to
> create
> > velocity.log. The permissions of this directory are set by the tomcat
> > install and do not allow files to be created there except by root.
> Anyway,
> > this is clearly not a very good place for the log so the solution is to
> > configure another location.
> >
> > I will see if my idea works locally before going any further.
> >
>
> I would expect there to be a mechanism withing Velocity to specify where to
> log to.
>
> I suspect it is by adding a properties file with a well known name, such as
> Velocity.properties.
>
> The question is, where to add it? I am attempting to configure its location
because I do not know what the default is or if Fedora changes it, but so
far without success. Maybe I just need to do some more debugging...


> I have run the tests here and discovered some failures, so will investigate
> those.
>
> Thanks.


> Still interested in why you want to use Velocity?
> If you use WebMacro then you are not tied the version delivered with
> RedHat.
>

The decision to use velocity is not what ties me to using a version
delivered with Fedora.

I decided to develop an RPM that uses other components available for Fedora
as RPMs, hence ruling out WebMacro altogether for now and restricting me to
Velocity 1.4.

I cannot easily explain that decision but it could eventually lead to Red
Hat making Melati available for RHEL. There is a long way to go but we start
picking up a few more users long before we get there. I think the first step
is to meet the QA requirements for Fedora extras and this probably means
using versions of binary components also available as RPMs.

I should really be debugging my RPM spec ;-) ...

Jim

Re: [Melati-developers] Location of velocity.log

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

On Saturday 30 January 2010 21:27:23 James Wright wrote:
> Hi Tim,
> 
> To clarify, this is not a test failure. It is what happens when you install
> melati-webapp in the standard place on Fedora (using the RPM based on
> trunk/etc/rpmbuild/fedora).

Yes, I understand that.
 
> So the RPM I have specified installs melati-webapp.war in
> /usr/share/tomcat5/webapps which is a symlink to  /var/lib/tomcat5/webapps
> but tomcat's PWD is /usr/share/tomcat5 so this is where it tries to create
> velocity.log. The permissions of this directory are set by the tomcat
> install and do not allow files to be created there except by root. Anyway,
> this is clearly not a very good place for the log so the solution is to
> configure another location.
> 
> I will see if my idea works locally before going any further.
> 

I would expect there to be a mechanism withing Velocity to specify where to log to. 

I suspect it is by adding a properties file with a well known name, such as Velocity.properties. 

I have run the tests here and discovered some failures, so will investigate those. 

Still interested in why you want to use Velocity? 
If you use WebMacro then you are not tied the version delivered with RedHat. 

cheers
Tim


-- 
We are in dialogue.

Re: [Melati-developers] Location of velocity.log

[James W. <ji...@wr...>]

Hi Tim,

To clarify, this is not a test failure. It is what happens when you install
melati-webapp in the standard place on Fedora (using the RPM based on
trunk/etc/rpmbuild/fedora).

So the RPM I have specified installs melati-webapp.war in
/usr/share/tomcat5/webapps which is a symlink to  /var/lib/tomcat5/webapps
but tomcat's PWD is /usr/share/tomcat5 so this is where it tries to create
velocity.log. The permissions of this directory are set by the tomcat
install and do not allow files to be created there except by root. Anyway,
this is clearly not a very good place for the log so the solution is to
configure another location.

I will see if my idea works locally before going any further.

Jim

On 30 January 2010 13:12, Tim Pizey <ti...@pa...> wrote:

> Hi Jim,
>
> My understanding was that this added to the properties that were
> set by velocity.
>
> I have just had a bit of a poke around and see that there is now
> a velocity 1.6.3 so perhaps we should see if all the tests pass with that.
>
> I am not hot on the configuration of velocity, but imagine that it is
> looking for a velocity.properties in the classpath.
> Sorry not to be more help.
>
> I still use WebMacro, as all my templates are in WM.
>
> I will check that the head passes all tests when Velocity is
> selected as the template engine.
>
>
> cheers
> Tim
>
>
>
>
> On Thursday 28 January 2010 23:13:28 James Wright wrote:
> > Hi Tim et al,
> >
> > I am trying to fix this without a hack:
> >
> > javax.servlet.ServletException:
> > org.melati.template.TemplateEngineException:
> > org.melati.template.TemplateEngineException
> > java.lang.Exception: Unable to configure AvalonLogSystem :
> > java.io.FileNotFoundException: /usr/share/tomcat5/velocity.log
> > (Permission denied)
> >       org.melati.servlet.TemplateServlet.init(TemplateServlet.java:90)
> >
> > It seems that VelocityTemplateEngine.init() ignores the given
> melatiConfig
> > and uses loadConfiguration() to get a trivial set of property definitons
> > designed solely to load templates. Effectively:
> > resource.loader=class
> > class.resource.loader.class=WebMacroClasspathResourceLoader
> >
> > I am not sure my understanding is correct, which is why I am writing.
> >
> > Anyway, org/melati/org.melati.MelatiConfig.properties defines a set of
> > properties org.melati.*.
> >
> > The number of times org*melati appears in the last sentence has always
> > looked to me like some kind of smell but I am not sure. If the aim is
> that
> > we can add lines like this:
> > org.apache.velocity.properties=/WEB-INF/conf/velocity.properties
> >
> > then maybe some of the reduncy makes sense.
> >
> > OK, my suggestion is to pass the melatiConfig to a new
> loadConfig(Properties
> > p) and add any default property definitons to those in the config file.
> >
> > Maybe I will try it over the weekend. In the meantime I would be grateful
> > for any comments. TIA.
> >
> > Jim
> >
>
> --
> We are in dialogue.
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Melati-developers mailing list
> Mel...@li...
> https://lists.sourceforge.net/lists/listinfo/melati-developers
>

Re: [Melati-developers] Location of velocity.log

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

Hi Jim, 

My understanding was that this added to the properties that were 
set by velocity. 

I have just had a bit of a poke around and see that there is now 
a velocity 1.6.3 so perhaps we should see if all the tests pass with that. 

I am not hot on the configuration of velocity, but imagine that it is 
looking for a velocity.properties in the classpath. 
Sorry not to be more help. 

I still use WebMacro, as all my templates are in WM. 

I will check that the head passes all tests when Velocity is 
selected as the template engine. 


cheers
Tim




On Thursday 28 January 2010 23:13:28 James Wright wrote:
> Hi Tim et al,
> 
> I am trying to fix this without a hack:
> 
> javax.servlet.ServletException:
> org.melati.template.TemplateEngineException:
> org.melati.template.TemplateEngineException
> java.lang.Exception: Unable to configure AvalonLogSystem :
> java.io.FileNotFoundException: /usr/share/tomcat5/velocity.log
> (Permission denied)
> 	org.melati.servlet.TemplateServlet.init(TemplateServlet.java:90)
> 
> It seems that VelocityTemplateEngine.init() ignores the given melatiConfig
> and uses loadConfiguration() to get a trivial set of property definitons
> designed solely to load templates. Effectively:
> resource.loader=class
> class.resource.loader.class=WebMacroClasspathResourceLoader
> 
> I am not sure my understanding is correct, which is why I am writing.
> 
> Anyway, org/melati/org.melati.MelatiConfig.properties defines a set of
> properties org.melati.*.
> 
> The number of times org*melati appears in the last sentence has always
> looked to me like some kind of smell but I am not sure. If the aim is that
> we can add lines like this:
> org.apache.velocity.properties=/WEB-INF/conf/velocity.properties
> 
> then maybe some of the reduncy makes sense.
> 
> OK, my suggestion is to pass the melatiConfig to a new loadConfig(Properties
> p) and add any default property definitons to those in the config file.
> 
> Maybe I will try it over the weekend. In the meantime I would be grateful
> for any comments. TIA.
> 
> Jim
> 

-- 
We are in dialogue.

[Melati-developers] Location of velocity.log

[James W. <ji...@wr...>]

Hi Tim et al,

I am trying to fix this without a hack:

javax.servlet.ServletException:
org.melati.template.TemplateEngineException:
org.melati.template.TemplateEngineException
java.lang.Exception: Unable to configure AvalonLogSystem :
java.io.FileNotFoundException: /usr/share/tomcat5/velocity.log
(Permission denied)
	org.melati.servlet.TemplateServlet.init(TemplateServlet.java:90)

It seems that VelocityTemplateEngine.init() ignores the given melatiConfig
and uses loadConfiguration() to get a trivial set of property definitons
designed solely to load templates. Effectively:
resource.loader=class
class.resource.loader.class=WebMacroClasspathResourceLoader

I am not sure my understanding is correct, which is why I am writing.

Anyway, org/melati/org.melati.MelatiConfig.properties defines a set of
properties org.melati.*.

The number of times org*melati appears in the last sentence has always
looked to me like some kind of smell but I am not sure. If the aim is that
we can add lines like this:
org.apache.velocity.properties=/WEB-INF/conf/velocity.properties

then maybe some of the reduncy makes sense.

OK, my suggestion is to pass the melatiConfig to a new loadConfig(Properties
p) and add any default property definitons to those in the config file.

Maybe I will try it over the weekend. In the meantime I would be grateful
for any comments. TIA.

Jim

Re: [Melati-developers] Melati RPMs for Fedora

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

Hi Jim, 

On Tuesday 05 January 2010 23:09:55 James Wright wrote:
> Hi Tim,
> 
> Thanks for your reply - just answering a few points...
> 
> 2010/1/4 Tim Pizey wrote:

[snip]
 
> > > OK, I am ready to commit ...
> > Great, I look forward to it.
> >
> 
> It is definitely committed because I just checked it out on another machine.

In one of those wonderful CVS oddities I cannot checkout due to 
/var/lock/subsys/cvs/melati/etc/rpmbuild being owned by you. 

I now have checked out, can't do much more tonight.
Congrats!!

> I do not see the notification here:
> http://sourceforge.net/mailarchive/forum.php?forum_name=melati-cvs
> 
> Does ji...@pa... need to be subscribed?

Yes, I think so. 

cheers
timp
 
PS Deep snow (6 inches) here!!


-- 
We are in dialogue.

Re: [Melati-developers] Melati RPMs for Fedora

[James W. <ji...@wr...>]

Hi Tim,

Thanks for your reply - just answering a few points...

2010/1/4 Tim Pizey <ti...@pa...>

>
> >    - One thing I am not committing is the ant script I use to run
> rpmbuild.
> Umm, why not?
>
> >    This first creates a source archive from Melati-0-7-8-RC2 i.e. the
> sources
> >    with that tag in CVS
>

Here is part answer to your question...

(and I assume this should be a Maven artifact in
> >    future).
>

So the first such thing to commit (on the trunk) is a Maven assembly or
source-plugin-thing that creates a tarball.

The other part of the answer is that my ant script is integrated with my
local dev env and there is not much scope for usefully factoring stuff out.


>  ?? I may be inspired to write a .deb package
>

Yes, there is plenty to do ;-) I was just looking at
https://fedoraproject.org/wiki/Package_Review_Process


This is my big TODO - change the directory structure so that
> the template engine is only specified by the template extension not by the
> path and extension.
>

Suits me.


>
> >       - I tried to avoid using anything that is not native to Fedora but
> >       only after I had installed mockobjects from jpackage-generic-5.0
> RPM
> >       repository.
>
> Mock objects is nearly completely removed, removing mockobjects is a todo.
>

OK


> > OK, I am ready to commit ...
> Great, I look forward to it.
>

It is definitely committed because I just checked it out on another machine.

I do not see the notification here:
http://sourceforge.net/mailarchive/forum.php?forum_name=melati-cvs

Does ji...@pa... need to be subscribed?

I spent a hungover morning at TimJ's  getting JammyJoes in step with HEAD,
> but jammyjoes live site I do not think has been updated.
> (Hint, hint - hey timj what's the score?)
>

Good to hear!

Jim

Re: [Melati-developers] Melati RPMs for Fedora

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

Hi Jim, 

On Sunday 03 January 2010 21:51:17 James Wright wrote:
> Hi Tim and any lurkers,
> 
> Happy new year.

And to you. 

 
> The last day of my break coincides with a complete build within rpmbuild.
> That is only a stage, but still a good stage to commit, which I will do
> shortly. Here are some key points:
> 
>    - One thing I am not committing is the ant script I use to run rpmbuild.

Umm, why not?

>    This first creates a source archive from Melati-0-7-8-RC2 i.e. the sources
>    with that tag in CVS (and I assume this should be a Maven artifact in
>    future). 

Eek, that tag is getting rather old now. 

>    It appears that the tagged sources pre-date this
> email<http://sourceforge.net/mailarchive/message.php?msg_name=200804032337.05536.timp%40paneris.org>,
>    so I had to cope with some test failures but actually the fixes use Velocity
>    1.5 features and the latest Fedora (fc12) comes with Velocity 1.4. 

Wow, 1.5 has been out for a while. 

>    So while
>    the tag might be out of date, it suits me to leave it as it is.

OK

>    - Of course I am committing to the trunk, in etc/rpmbuild/fedora. 

Perfect

>    I don't
>    know if it is realistic that each release includes files to create an RPM
>    from it, but the directory structure supports it. (It is certainly possible
>    e.g. by creating a patch from CVS that rolls back to an earlier release and
>    including that with other rpmbuild patches, but what does that achieve?)

?? I may be inspired to write a .deb package

>    Until this evening I had a directory fc11 because I am currently developing
>    an RPM for Fedora 11 but I am fairly sure rpmbuild has features to support
>    more than one platform with a single set of files, so that is the plan for
>    fedora versions. Supporting the most recent 2 or 3 releases would be
>    reasonable.
>    - rpmbuild for beginners (like me ;-) ):
>       - It's functionality overlaps with maven. Whereas maven specifies
>       dependency versions in the POM, rpmbuild specifies them in the spec file
>       etc/rpmbuild/fedora/SPECS/melati.spec. When creating a RPM for a project
>       built using maven, rpmbuild wins i.e. the carefully thought out
> dependencies
>       in the POM are abandoned and the packages available for the
> target platform
>       are used. 

Ahh, that should be fun. 
As far as I know we are using very standard bits of very old APIs so should be OK. 

>       Still, it is a fixed set of versions against which tests can be
>       performed.
>       - A dependency map etc/rpmbuild/fedora/SOURCES/melati-depmap.xml fills
>       some gaps in the system dependency maps under /etc/maven on
> fedora. Maven is
>       encapsulated in a script mvn-jpp which ensures the versions in POMs are
>       ignored, online maven repositories are also ignored etc.
>       - The many patches rpmbuild/fedora/SOURCES/*.patch fix the bugs that
>       result from using a different set of dependencies.
>    - I had to be quite ruthless with patches applied by rpmbuild because
>    various dependencies are not currently available for Fedora. In some cases I
>    chose to add shell commands to the RPM spec file. I don't know if this is
>    good practise but it seems more robust than deleting files in patches. Main
>    details:
>       - Generally the patch filenames are self documenting. A few are unused
>       as described below. (Those that are used are listed in the spec file AND
>       applied with e.g. %patch1 -p. )
>       - Dependencies that are removed include webmacro (and quite a few
>       sourcefiles), mckoi, odmg, jetty (or at least maven-jetty-plugin),
>       tango-icon-theme, jwebunit, JSP related stuff, 

All cool. 

>       exec-maven-plugin, ...?
This enables a shell script to be run from withing Maven. 


>       - Nothing is assumed to be under /dist/melati but sometimes we instead
>       assume for the purpose of building the RPM that the same things are in a
>       relative location.

I feel a bit embarrassed about /dist/ but it has worked for me for a long time.

>       - For example,
>       melati-automateCreationOfVmfromWmDuringRpmDevelopment.patch
> creates missing
>       velocity templates in the patched source directories. 

Ahh, cool, I have done this too in a few ways. 
One is to uncomment the 'write out converted file' line in 
the velocity/webmacro converter. 

This is my big TODO - change the directory structure so that 
the template engine is only specified by the template extension not by the 
path and extension. 
This will result in a lot more sane template handling. 


>       The plan is to create
>       patches that add these files and then switch to
>       melati-noCreationOfVmFromWm.patch (currently unused)
>       - I tried to avoid using anything that is not native to Fedora but
>       only after I had installed mockobjects from jpackage-generic-5.0 RPM
>       repository. 

Mock objects is nearly completely removed, removing mockobjects is a todo. 


>       Since this was relatively painless (as compared with e.g.
>       maven-jetty-plugin) I have listed it in the spec file as required for the
>       RPM build (but not to install the resulting RPM). So
>       melati-no-mockobjects.patch is unused.
>       - melati-no-cyclic-poem-dependency.patch is interesting. It took some
>       effort to come up with an alternative hack that I hoped might be
> the basis
>       for a robust solution i.e. how to ensure Poem.dsd can be located
> by the DSD
>       plugin. 

Yes, this is horrid. Maven really does not like us. The current(?) Maven 
on Debian, which I am increasingly happy to use, has changed its behaviour. 
I have had to make a copy of poem and install that as poemCopy.jar by hand.

>       I discovered at the final hurdle that my hack did not work for
>       melati-example-contacts. However, I have another hack that
> enables this to
>       build at least. So melati-skip-example-contacts.patch is unused. I'm not
>       motivated to improve on this because I see DSLs as clever and fun but not
>       wise, and maven may not even make a nice solution possible.
>       - There are also shell commands in the spec file to move some
>       org.melati.util sources from the melati module to the poem module. Search
>       for FIXME.
> 
> My plan now is to take my maven/Java hat off and focus on packaging the
> results into RPMs. Then I will install these RPMs and probably find stuff
> that is broken and necessitates putting the maven/Java hat on again. I've no
> time plan ;-)


I am a little pushed for spare time, but will try to stick with you. 
 
> Other TODOs:
> 
>    - create a source archive during the maven build to meet requirements of
>    rpmbuild etc.
>    - any .vm templates automatically created from .wm templates can be
>    committed so we do not need patches or similar.

yes.

>    - the tail should not wag the dog (RPM is designed to make that
>    unnecessary) but we could reduce the number of rpmbuild patches by other
>    changes on the trunk:
>       - I am already using nojetty. Maybe we could use more maven profiles.

Cool

>       - ?
>    - The sources that I moved from the melati module to poem should perhaps
>    be moved in CVS too.

OK,  I hope that I have actually done this in HEAD??

>    - Fix xsi:schemaLocation in the parent POM. (No patch for this - seems to
>    cause no noticeable problems)
> 
> OK, I am ready to commit ...
> 
> Jim

Great, I look forward to it. 

I spent a hungover morning at TimJ's  getting JammyJoes in step with HEAD, 
but jammyjoes live site I do not think has been updated. 
(Hint, hint - hey timj what's the score?)


I will rollout a Melati-0-7-8 sometime soon :)

cheers
TimP


-- 
We are in dialogue.

Re: [Melati-developers] Melati RPMs for Fedora

[James W. <ji...@wr...>]

Hi Tim and any lurkers,

Happy new year.

The last day of my break coincides with a complete build within rpmbuild.
That is only a stage, but still a good stage to commit, which I will do
shortly. Here are some key points:

   - One thing I am not committing is the ant script I use to run rpmbuild.
   This first creates a source archive from Melati-0-7-8-RC2 i.e. the sources
   with that tag in CVS (and I assume this should be a Maven artifact in
   future). It appears that the tagged sources pre-date this
email<http://sourceforge.net/mailarchive/message.php?msg_name=200804032337.05536.timp%40paneris.org>,
   so I had to cope with some test failures but actually the fixes use Velocity
   1.5 features and the latest Fedora (fc12) comes with Velocity 1.4. So while
   the tag might be out of date, it suits me to leave it as it is.
   - Of course I am committing to the trunk, in etc/rpmbuild/fedora. I don't
   know if it is realistic that each release includes files to create an RPM
   from it, but the directory structure supports it. (It is certainly possible
   e.g. by creating a patch from CVS that rolls back to an earlier release and
   including that with other rpmbuild patches, but what does that achieve?)
   Until this evening I had a directory fc11 because I am currently developing
   an RPM for Fedora 11 but I am fairly sure rpmbuild has features to support
   more than one platform with a single set of files, so that is the plan for
   fedora versions. Supporting the most recent 2 or 3 releases would be
   reasonable.
   - rpmbuild for beginners (like me ;-) ):
      - It's functionality overlaps with maven. Whereas maven specifies
      dependency versions in the POM, rpmbuild specifies them in the spec file
      etc/rpmbuild/fedora/SPECS/melati.spec. When creating a RPM for a project
      built using maven, rpmbuild wins i.e. the carefully thought out
dependencies
      in the POM are abandoned and the packages available for the
target platform
      are used. Still, it is a fixed set of versions against which tests can be
      performed.
      - A dependency map etc/rpmbuild/fedora/SOURCES/melati-depmap.xml fills
      some gaps in the system dependency maps under /etc/maven on
fedora. Maven is
      encapsulated in a script mvn-jpp which ensures the versions in POMs are
      ignored, online maven repositories are also ignored etc.
      - The many patches rpmbuild/fedora/SOURCES/*.patch fix the bugs that
      result from using a different set of dependencies.
   - I had to be quite ruthless with patches applied by rpmbuild because
   various dependencies are not currently available for Fedora. In some cases I
   chose to add shell commands to the RPM spec file. I don't know if this is
   good practise but it seems more robust than deleting files in patches. Main
   details:
      - Generally the patch filenames are self documenting. A few are unused
      as described below. (Those that are used are listed in the spec file AND
      applied with e.g. %patch1 -p. )
      - Dependencies that are removed include webmacro (and quite a few
      sourcefiles), mckoi, odmg, jetty (or at least maven-jetty-plugin),
      tango-icon-theme, jwebunit, JSP related stuff, exec-maven-plugin, ...?
      - Nothing is assumed to be under /dist/melati but sometimes we instead
      assume for the purpose of building the RPM that the same things are in a
      relative location.
      - For example,
      melati-automateCreationOfVmfromWmDuringRpmDevelopment.patch
creates missing
      velocity templates in the patched source directories. The plan
is to create
      patches that add these files and then switch to
      melati-noCreationOfVmFromWm.patch (currently unused)
      - I tried to avoid using anything that is not native to Fedora but
      only after I had installed mockobjects from jpackage-generic-5.0 RPM
      repository. Since this was relatively painless (as compared with e.g.
      maven-jetty-plugin) I have listed it in the spec file as required for the
      RPM build (but not to install the resulting RPM). So
      melati-no-mockobjects.patch is unused.
      - melati-no-cyclic-poem-dependency.patch is interesting. It took some
      effort to come up with an alternative hack that I hoped might be
the basis
      for a robust solution i.e. how to ensure Poem.dsd can be located
by the DSD
      plugin. I discovered at the final hurdle that my hack did not work for
      melati-example-contacts. However, I have another hack that
enables this to
      build at least. So melati-skip-example-contacts.patch is unused. I'm not
      motivated to improve on this because I see DSLs as clever and fun but not
      wise, and maven may not even make a nice solution possible.
      - There are also shell commands in the spec file to move some
      org.melati.util sources from the melati module to the poem module. Search
      for FIXME.

My plan now is to take my maven/Java hat off and focus on packaging the
results into RPMs. Then I will install these RPMs and probably find stuff
that is broken and necessitates putting the maven/Java hat on again. I've no
time plan ;-)

Other TODOs:

   - create a source archive during the maven build to meet requirements of
   rpmbuild etc.
   - any .vm templates automatically created from .wm templates can be
   committed so we do not need patches or similar.
   - the tail should not wag the dog (RPM is designed to make that
   unnecessary) but we could reduce the number of rpmbuild patches by other
   changes on the trunk:
      - I am already using nojetty. Maybe we could use more maven profiles.
      - ?
   - The sources that I moved from the melati module to poem should perhaps
   be moved in CVS too.
   - Fix xsi:schemaLocation in the parent POM. (No patch for this - seems to
   cause no noticeable problems)

OK, I am ready to commit ...

Jim
------------------------------

[Melati-developers] Melati RPMs for Fedora

[James W. <ji...@wr...>]

Hi Tim,

2 years after suggesting it, I have had another go at creating a set of
Melati RPMs for Fedora. I made some progress based on POMs and source JARs
downloaded from:
http://melati.org/maven2/org/melati/

BTW I don't really understand what I see there - a number of builds for each
RC.

Anyway, there is (I think) one file like this for each RC of each subproject
(module):

http://melati.org/maven2/org/melati/poem/0.7.8-RC2-SNAPSHOT/poem-0.7.8-RC2-20090930.091550-22-sources.jar

so these are what I am using, along with the corresponding POMs.

ISSUE1: Today I noticed that this one is almost empty:
http://melati.org/maven2/org/melati/melati-webapp/0.7.8-RC2-SNAPSHOT/melati-webapp-0.7.8-RC2-20090930.091550-8-sources.jar

Here is what I get as a consequence. I think the good news outweighs the bad
;-)

[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
------------------------------------------------------------------------
[INFO] Melati Home ........................................... SUCCESS
[10.123s]
[INFO] Throwing JDBC ......................................... SUCCESS
[4.646s]
[INFO] DSD Processor ......................................... SUCCESS
[3.136s]
[INFO] POEM .................................................. SUCCESS
[1.250s]
[INFO] Melati ................................................ SUCCESS
[17.433s]
[INFO] Contacts Example ...................................... SUCCESS
[0.698s]
[INFO] Melati Webapp ......................................... FAILED
[0.956s]
[INFO] Melati Archetype ...................................... SUCCESS
[0.287s]
[INFO] Melati Skin ........................................... SUCCESS
[0.209s]
[INFO]
------------------------------------------------------------------------
[INFO] Error for project: Melati Webapp (during install)
[INFO]
------------------------------------------------------------------------
[INFO] Error assembling WAR: Deployment descriptor:
/home/jwright/rpmbuild/BUILD/melati-0.7.8/melati-webapp/target/melati-webapp/WEB-INF/web.xml
does not exist.

Note that I hacked out melati-example-odmg using an rpmbuild patch. There
are many other such hacks/patches that may mean the results are not as good
as they look.

ISSUE2: Today I tried to checkout using anonymous access and it does not
appear to work as described here: http://melati.org/Download.html.
cvs login: authorization failed: server melati.org rejected access to
/usr/cvsroot for user anonymous

ISSUE3: Following the link on the same page to the CVS web interface I get
403 Forbidden. http://melati.org/cgi-bin/cvsweb.cgi/~checkout~/melati/

Can you send me a password update so I can update my existing CVS working
directory? I have no clue what it was and anyway recall you disabled some
accounts on the server and offered to reinstate them by request.

At some point I will probably want to make some commits. I can think of at
least one change I made locally which was a fix as opposed to a patch
required to work within the constraints of Fedora 11. Also, I think it might
be good to put the RPM specification in Melati CVS e.g. in a directory
rpmbuild/fc11.

TIA,

Jim

[Melati-developers] Removal of checked exceptions

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

Hi, 

I am using Melati in my current post, and so am moving it forwards. 

I am changing the api so that IOExceptions are rarely thrown but 
instead are caught and rethrown as RuntimeExceptions. 
This makes the API cleaner to use and I can honestly say that we have not seen 
IOExceptions being thrown in ten years. 
Finally converting these to RuntimeExceptions allows the API to follow the maxim 
that checked exceptions should only be used for something the programmer 
can respond to. 

Have also started to code to Java5 and retrofit. 

cheers
Tim




-- 
We are in dialogue.

Re: [Melati-developers] Bug in Poem?

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

On Friday 20 February 2009 22:32:37 William Chesters wrote:
> I tried reproducing this by changing the "Input-box width" for the
> "User.Full name" field to something huge and back --- it works fine,
> the change being reflected immediately in the User record pages.

There was a problem here too (you are changing a ColumnInfo here, 
not a Setting), but I fixed that a while ago, I think.

> However, I'm sure I have noticed the same apparent bug before.  I wonder
> if it has "gone away" because I've set "Cache-Control: no-cache" in
> the copy I'm using for Belinda's site?  Have you tried forcing yr browser
> to update the pane in question?

I checked that this problem was only surfacing in the Settings table, 
as I seemed to remember a time when the only way to get meta-data 
changes to come into effect was to restart, but no, everything working 
just fine now.

Where have you put the no-cache?
Do you want to commit?

In the course of all this I am revisiting a few other funnies and non-coverages: 
have found a bug in YMDateAdaptor and overcome a bug in gargolyes javascript 
implementation so that I can turn scripting on for the automated testing of Admin.

There is a bug in the Admin system such that selecting a subsection of 
the ColumnInfo table based upon owning table does not work.

I currently have Melati test coverage up from 64% to 74%, I think I can get it to 
the same league as POEM  (82%) with a little more effort.

cheers
Tim


> 
> Tim Pizey writes:
>  > Hi, 
>  > 
>  > I have noticed for a while that there is a problem with the the sequence of writedown 
>  > in the admin system on modify.
>  > 
>  > If one uses the admin system to modify a record in the settings table, 
>  > say the height and width of the input widget this value is not applied.
>  > 
>  > It is applied only after a restart, though the values are still displayed correctly. 
>  > 
>  > No doubt this is a problem I have introduced but comments welcome. 
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Melati-developers mailing list
> Mel...@li...
> https://lists.sourceforge.net/lists/listinfo/melati-developers
> 
> 



-- 
We are in dialogue.

[Melati-developers] FIXED Re: Bug in Poem?

[<wil...@pa...>]

Tim Pizey writes:
 > This was pretty tricky, though obvious in retrospect, the attributes 
 > of the value field of a Setting are the attributes of that setting, 
 > however they were cached, so only changed when the jvm was restarted. 
 > 
 > Adding a postEdit() method to null the cached value has fixed. 

Nice one.  "All programming is an exercise in caching" ... I am
increasingly sure that the next big programming craze is going to be
dependency graphs!

[Melati-developers] Bug in Poem?

[<wil...@pa...>]

I tried reproducing this by changing the "Input-box width" for the
"User.Full name" field to something huge and back --- it works fine,
the change being reflected immediately in the User record pages.

However, I'm sure I have noticed the same apparent bug before.  I wonder
if it has "gone away" because I've set "Cache-Control: no-cache" in
the copy I'm using for Belinda's site?  Have you tried forcing yr browser
to update the pane in question?

Tim Pizey writes:
 > Hi, 
 > 
 > I have noticed for a while that there is a problem with the the sequence of writedown 
 > in the admin system on modify.
 > 
 > If one uses the admin system to modify a record in the settings table, 
 > say the height and width of the input widget this value is not applied.
 > 
 > It is applied only after a restart, though the values are still displayed correctly. 
 > 
 > No doubt this is a problem I have introduced but comments welcome. 

[Melati-developers] FIXED Re: Bug in Poem?

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

On Friday 20 February 2009 19:23:57 Tim Pizey wrote:
> Hi, 
> 
> I have noticed for a while that there is a problem with the the sequence of writedown 
> in the admin system on modify.
> 
> If one uses the admin system to modify a record in the settings table, 
> say the height and width of the input widget this value is not applied.
> 
> It is applied only after a restart, though the values are still displayed correctly. 
> 
> No doubt this is a problem I have introduced but comments welcome. 
> 
> 

This was pretty tricky, though obvious in retrospect, the attributes 
of the value field of a Setting are the attributes of that setting, 
however they were cached, so only changed when the jvm was restarted. 

Adding a postEdit() method to null the cached value has fixed. 

Tim


-- 
We are in dialogue.

[Melati-developers] Bug in Poem?

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

Hi, 

I have noticed for a while that there is a problem with the the sequence of writedown 
in the admin system on modify.

If one uses the admin system to modify a record in the settings table, 
say the height and width of the input widget this value is not applied.

It is applied only after a restart, though the values are still displayed correctly. 

No doubt this is a problem I have introduced but comments welcome. 


-- 
We are in dialogue.

Re: [Melati-developers] Melati 0.7.8-RC2 re-released

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

On Wednesday 18 February 2009 00:32:51 Tim Pizey wrote:
> 
> I have also fixed the long standing bug in template flushing.

I have, honest, see  
http://www.melati.org:8080/melati-webapp/org.melati.test.FlushingServletTest
however 
http://www.melati.org/melati-webapp/org.melati.test.FlushingServletTest
exhibits the old behaviour, as the proxy is page based :(

Any suggestions?

-- 
We are in dialogue.