You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brian Pedersen <ba...@yahoo.dk> on 2003/10/11 10:38:45 UTC
A cache plugin ...
Hi
We are around 30 developers doing J2EE developement in my company.
When building with either ant or maven, a large part of the time consumed is by
generating code using various tools, such as ejbgen, xjc, wsgen etc. and the
following compilation.
To deal with this I have created a simple plugin that writes a serialized cache
to a specified location, containing any cached directories/attributes.
When performing a build, this cache is loaded and compared to the present values,
and only if changes has been applied, the defined build process starts.
Here is an example jellyscript:
<cache:load path="${maven.build.dir}/gen/xjc/build.cache">
<cache:compare key="src" dir="${maven.src.dir}/xsd" includes="*.xsd"/>
<cache:compare key="xjcVersion" value="${xjcVersion}"/>
<cache:modified>
<xjc extension="true" target="${maven.build.dir}/gen/xjc"
package="foo.ejb.dao.xml.webservice.events.param">
<schema dir="${maven.src.dir}/xsd" includes="*.xsd"/>
</xjc>
</cache:modified>
</cache:load>
The above shows a simple example of using the cache-plugin, only when xsd files
are changed in the defined srcdir or when the xjc-version(read from POM
dependencies) are changed, the xjc task are performed.
The cache can take any number of directories/attributes and store/compare.
This simple plugin, based on the org.apache.tools.ant.DirectoryScanner, actually
saves 2-3 minutes buildtime in my current project !
I will be happy to contribute it to the maven core-plugins, if you guys are
interested.
Regards
Brian Pedersen
Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: A cache plugin ...
Posted by Brian Pedersen <ba...@yahoo.dk>.
Actually I didnt know about the uptodate task before reading your mail, if I did,
I probably wouldnt have made my plugin.
That being said, after reading the documentation of the uptodate task and
assuming I understand its features, I belive my plugin actually does a better
job.
The uptodate task compares the latest lastModified date of one directory with the
latest lastModified date of another, so if the target dir has the latest
lastModified date compared to the src dir, a build is not run.
That is if I understand the task correctly.
But what if srcfiles were deleted ?
What if a CVS update added som older srcfiles ?
What if you have some critical properties that after modification should result
in a new build ?
I guess the developer would have to know about this and call a clean target first
?
That is if I understand the uptodate task correctly.
My plugin can compare properties as well as directories.
This often comes in handy to ensure a new build is enforced by contextchanges.
This could ofcause be achieved by persisting these in various property/xml files,
which they in the first place often are, but you would have to compare the whole
file, so like changing the description in your POM would result in a new build if
you wanted to watch a dependency version or you would have to temporarely store
these values elsewhere, which would require a lot more jelly code.
In my plugin this is handled elegantly by one line:
<cache:compare key="xjcVersion" value="${xjcVersion}"/>
When comparing directories my plugin compares absolute filename, lastModified and
filesize for every single file and afterwards compares total filecount for the
directory, thereby eliminating the above mentioned problems concearning deleted
files or new files with older timestamp.
The information are kept serialized for later comparison and updated with every
build.
If a property or directory should not be persisted by default, this can defined
using the persist attribute:
<cache:compare key="xjcVersion" value="${xjcVersion}" persist="false"/>
and afterwards manually persisted:
<cache:persist key="xjcVersion" value="${xjcVersion}">
But as stated earlier, if I knew about the uptodate task a couple of days ago, I
might not have made my plugin. Compared to the uptodate task, it does however
seem more powerfull.
Regards
Brian Pedersen
--- dion@multitask.com.au skrev: > How does this compare with Ant's uptodate
task?
> --
> dIon Gillard, Multitask Consulting
> Blog: http://blogs.codehaus.org/people/dion/
>
>
> Brian Pedersen <ba...@yahoo.dk> wrote on 11/10/2003 06:38:45 PM:
>
> > Hi
> >
> > We are around 30 developers doing J2EE developement in my company.
> >
> > When building with either ant or maven, a large part of the time
> > consumed is by
> > generating code using various tools, such as ejbgen, xjc, wsgen etc. and
> the
> > following compilation.
> >
> > To deal with this I have created a simple plugin that writes a
> > serialized cache
> > to a specified location, containing any cached directories/attributes.
> > When performing a build, this cache is loaded and compared to the
> > present values,
> > and only if changes has been applied, the defined build process starts.
> >
> > Here is an example jellyscript:
> >
> > <cache:load path="${maven.build.dir}/gen/xjc/build.cache">
> > <cache:compare key="src" dir="${maven.src.dir}/xsd" includes="*.xsd"/>
> > <cache:compare key="xjcVersion" value="${xjcVersion}"/>
> > <cache:modified>
> > <xjc extension="true" target="${maven.build.dir}/gen/xjc"
> > package="foo.ejb.dao.xml.webservice.events.param">
> > <schema dir="${maven.src.dir}/xsd" includes="*.xsd"/>
> > </xjc>
> > </cache:modified>
> > </cache:load>
> >
> > The above shows a simple example of using the cache-plugin, only
> > when xsd files
> > are changed in the defined srcdir or when the xjc-version(read from POM
> > dependencies) are changed, the xjc task are performed.
> > The cache can take any number of directories/attributes and
> store/compare.
> >
> > This simple plugin, based on the org.apache.tools.ant.
> > DirectoryScanner, actually
> > saves 2-3 minutes buildtime in my current project !
> >
> > I will be happy to contribute it to the maven core-plugins, if you guys
> are
> > interested.
> >
> > Regards
> > Brian Pedersen
> >
> >
> > Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads,
> > spamfilter og virusscan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: A cache plugin ...
Posted by di...@multitask.com.au.
How does this compare with Ant's uptodate task?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Brian Pedersen <ba...@yahoo.dk> wrote on 11/10/2003 06:38:45 PM:
> Hi
>
> We are around 30 developers doing J2EE developement in my company.
>
> When building with either ant or maven, a large part of the time
> consumed is by
> generating code using various tools, such as ejbgen, xjc, wsgen etc. and
the
> following compilation.
>
> To deal with this I have created a simple plugin that writes a
> serialized cache
> to a specified location, containing any cached directories/attributes.
> When performing a build, this cache is loaded and compared to the
> present values,
> and only if changes has been applied, the defined build process starts.
>
> Here is an example jellyscript:
>
> <cache:load path="${maven.build.dir}/gen/xjc/build.cache">
> <cache:compare key="src" dir="${maven.src.dir}/xsd" includes="*.xsd"/>
> <cache:compare key="xjcVersion" value="${xjcVersion}"/>
> <cache:modified>
> <xjc extension="true" target="${maven.build.dir}/gen/xjc"
> package="foo.ejb.dao.xml.webservice.events.param">
> <schema dir="${maven.src.dir}/xsd" includes="*.xsd"/>
> </xjc>
> </cache:modified>
> </cache:load>
>
> The above shows a simple example of using the cache-plugin, only
> when xsd files
> are changed in the defined srcdir or when the xjc-version(read from POM
> dependencies) are changed, the xjc task are performed.
> The cache can take any number of directories/attributes and
store/compare.
>
> This simple plugin, based on the org.apache.tools.ant.
> DirectoryScanner, actually
> saves 2-3 minutes buildtime in my current project !
>
> I will be happy to contribute it to the maven core-plugins, if you guys
are
> interested.
>
> Regards
> Brian Pedersen
>
>
> Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads,
> spamfilter og virusscan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org