JSP Precompilation

[Christopher Coco <ca...@gmail.com>]

Hi all,

I'm wondering if anyone has picked up this thread:

http://old.nabble.com/buildr-pre-compile-JSP-for-war--td17109370.html#a17109370

It's more than 3 years old, but Buildr still seems to be lacking this functionality. I wrote a JSP pre-compiler specific for my company, but would be willing to try to abstract it. Again, being new to Ruby and Buildr, I'm trying to figure out the best way to integrate this functionality. It's java specific, and I had thought that a couple of possibilities could be to 
a.) extend the java compiler functionality (though jsp compilation seems like a stretch here), 
b.) to extend the WAR packaging functionality (where I'm leaning), 
c.) separate it completely like the scala plugin (make this is more robust?), 
d.) or even just drop it in as an add-on (not sure the pros/cons). 

I'm looking for some views or opinions on a best approach. Any thoughts?

So far here's what I have as a project extension (it uses the user's TOMCAT_HOME to build a dependency graph, as well as makes some other assumptions):

https://gist.github.com/921897

Thanks,
-c

Re: JSP Precompilation

[je...@orange-ftgroup.com]

On 21/07/2011 21:24, Christopher Coco wrote:
> Hi all,

Hi

> So far here's what I have as a project extension (it uses the user's TOMCAT_HOME to build a dependency graph, as well as makes some other assumptions):
>
> https://gist.github.com/921897

Thanks for sharing this, I wanted to do something like this myself but 
couldn't find time for that.
Could you post (here) some example of use ?
What artifacts should be in JASPER list ?

thanks

-- Jean-Philippe Caruana

















********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

Re: JSP Precompilation

[Christopher Coco <ca...@gmail.com>]

Peter,

Great, thanks for the information. I'll look at starting with an add-on.

-c

On Thursday, July 21, 2011 at 10:33 PM, Peter Donald wrote:

> Hi,
> 
> On Fri, Jul 22, 2011 at 5:24 AM, Christopher Coco <cacoco@gmail.com (mailto:cacoco@gmail.com)> wrote:
> 
> > I'm wondering if anyone has picked up this thread:
> > 
> > 
> > http://old.nabble.com/buildr-pre-compile-JSP-for-war--td17109370.html#a17109370
> 
> 
> Not that I am aware of.
> 
> It's more than 3 years old, but Buildr still seems to be lacking this
> > functionality. I wrote a JSP pre-compiler specific for my company, but would
> > be willing to try to abstract it. Again, being new to Ruby and Buildr, I'm
> > trying to figure out the best way to integrate this functionality. It's java
> > specific, and I had thought that a c
> 
> A couple of possibilities could be to
> > a.) extend the java compiler functionality (though jsp compilation seems
> > like a stretch here),
> > b.) to extend the WAR packaging functionality (where I'm leaning),
> > c.) separate it completely like the scala plugin (make this is more
> > robust?),
> > d.) or even just drop it in as an add-on (not sure the pros/cons).
> > 
> > I'm looking for some views or opinions on a best approach. Any thoughts?
> 
> My approach has always bee d) where possible - it allows you to rapidly
> evolve the plugin and share it between all the different projects that use
> it. It also makes it easy to write tests and validate it easily. If the
> plugin gets general enough and well tested enough you can always donate it
> back to this project. This is the approach I took with various plugins. For
> example [1] is a plugin I developed outside as an extension that eventually
> folded back into buildr while [2] is something that I never get around to
> cleaning up. You will notice that many of the extensions I have made
> actually call out to ant tasks or directly call command line apps. I think
> this is a perfectly reasonable way to approach things.
> 
> [1] https://github.com/realityforge/buildr-bnd
> [2] https://github.com/realityforge/buildr-ipojo
> 
> -- 
> Cheers,
> 
> Peter Donald

Re: JSP Precompilation

[Peter Donald <pe...@realityforge.org>]

Hi,

On Fri, Jul 22, 2011 at 5:24 AM, Christopher Coco <ca...@gmail.com> wrote:

> I'm wondering if anyone has picked up this thread:
>
>
> http://old.nabble.com/buildr-pre-compile-JSP-for-war--td17109370.html#a17109370


Not that I am aware of.

It's more than 3 years old, but Buildr still seems to be lacking this
> functionality. I wrote a JSP pre-compiler specific for my company, but would
> be willing to try to abstract it. Again, being new to Ruby and Buildr, I'm
> trying to figure out the best way to integrate this functionality. It's java
> specific, and I had thought that a c

ouple of possibilities could be to
> a.) extend the java compiler functionality (though jsp compilation seems
> like a stretch here),
> b.) to extend the WAR packaging functionality (where I'm leaning),
> c.) separate it completely like the scala plugin (make this is more
> robust?),
> d.) or even just drop it in as an add-on (not sure the pros/cons).
>
> I'm looking for some views or opinions on a best approach. Any thoughts?
>

My approach has always bee d) where possible - it allows you to rapidly
evolve the plugin and share it between all the different projects that use
it. It also makes it easy to write tests and validate it easily. If the
plugin gets general enough and well tested enough you can always donate it
back to this project. This is the approach I took with various plugins. For
example [1] is a plugin I developed outside as an extension that eventually
folded back into buildr while [2] is something that I never get around to
cleaning up. You will notice that many of the extensions I have made
actually call out to ant tasks or directly call command line apps. I think
this is a perfectly reasonable way to approach things.

[1] https://github.com/realityforge/buildr-bnd
[2] https://github.com/realityforge/buildr-ipojo

-- 
Cheers,

Peter Donald