Re: Sanity Check
On Mon, Jun 28, 2010 at 3:57 PM, Manfred Moser wrote: > You could use maven shell for faster feedback. > yeah.. that actually works well.. I'd like it to happen automatically, though. -- Greg Akins http://insomnia-consulting.org http://www.pghcodingdojo.org http://pittjug.dev.java.net http://twitter.com/akinsgre http://www.linkedin.com/in/akinsgre - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Sanity Check
> On Mon, Jun 28, 2010 at 3:53 PM, Greg Akins wrote: >> On Sat, Jun 26, 2010 at 11:20 AM, Stephen Connolly >> wrote: >>> [Returning reply to the list so that others may benefit] >>> >>> http://wiki.hudson-ci.org/display/HUDSON/File+System+SCM >>> >> >> That's cool. Thanks for the suggestion. >> >> Still it seems that this will be pretty slow compared to a maven >> plugin that can run and just execute "test" when ever the files >> change. >> >> Autotest reminds me of using editors that give "real-time" compile >> information.. it's that quick (obviously assuming your tests are quick >> to begin with) >> >> Even if I could execute 'mvn test' every time a file changed, just the >> startup of mvn is enough to slow that feedback look considerably. You could use maven shell for faster feedback. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Sanity Check
On Mon, Jun 28, 2010 at 3:53 PM, Greg Akins wrote: > On Sat, Jun 26, 2010 at 11:20 AM, Stephen Connolly > wrote: >> [Returning reply to the list so that others may benefit] >> >> http://wiki.hudson-ci.org/display/HUDSON/File+System+SCM >> > > That's cool. Thanks for the suggestion. > > Still it seems that this will be pretty slow compared to a maven > plugin that can run and just execute "test" when ever the files > change. > > Autotest reminds me of using editors that give "real-time" compile > information.. it's that quick (obviously assuming your tests are quick > to begin with) > > Even if I could execute 'mvn test' every time a file changed, just the > startup of mvn is enough to slow that feedback look considerably. > -- Greg Akins http://insomnia-consulting.org http://www.pghcodingdojo.org http://pittjug.dev.java.net http://twitter.com/akinsgre http://www.linkedin.com/in/akinsgre - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Sanity Check
[Returning reply to the list so that others may benefit] http://wiki.hudson-ci.org/display/HUDSON/File+System+SCM I've not used it though On 26 June 2010 11:38, Greg Akins wrote: > On Sat, Jun 26, 2010 at 3:25 AM, Stephen Connolly > wrote: > > What is wrong with using a CI system to do this for you?, e.g. Hudson > > > > It's trivial to run Hudson on your own machine > > > > -Stephen > > I thought about that, but don't think that Hudson can just watch a > filesystem; I think it has to look for changes to SCM and only does so > based on timed intervals. > > I'm looking for something like Ruby's Autospec, and want to > incorporate a listener on the filesystem so that 'mvn test' will run > as soon as I save a file. > -- > Greg Akins > > http://insomnia-consulting.org > http://www.pghcodingdojo.org > http://pittjug.dev.java.net > http://twitter.com/akinsgre > http://www.linkedin.com/in/akinsgre >
Re: Sanity Check
What is wrong with using a CI system to do this for you?, e.g. Hudson
It's trivial to run Hudson on your own machine
-Stephen
On 26 June 2010 03:39, Greg Akins wrote:
> I feel like creating a plug-in that will monitor for file changes and
> run "test" when notified of a change.
>
> 1) It looks like it's a little cumbersome to call a goal for one
> plugin from the execute method of another.
> 2) There are a few plugins that look like they wrap this ability
> alread ("inherit" is one, "cli" and "mojo-executor library")
>
> Does anyone have an opinions? I'll probably follow this blog
> (
> http://unserializableone.blogspot.com/2009/06/executing-maven-plugin-from-maven.html
> )
> to get started and have an execute method with
>
> public void execute() {
> while(true) {
>if (lookForChanges()) TestMojo().execute();
> }
> }
>
> --
> Greg Akins
>
> http://insomnia-consulting.org
> http://www.pghcodingdojo.org
> http://pittjug.dev.java.net
> http://twitter.com/akinsgre
> http://www.linkedin.com/in/akinsgre
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Sanity Check
I feel like creating a plug-in that will monitor for file changes and
run "test" when notified of a change.
1) It looks like it's a little cumbersome to call a goal for one
plugin from the execute method of another.
2) There are a few plugins that look like they wrap this ability
alread ("inherit" is one, "cli" and "mojo-executor library")
Does anyone have an opinions? I'll probably follow this blog
(http://unserializableone.blogspot.com/2009/06/executing-maven-plugin-from-maven.html)
to get started and have an execute method with
public void execute() {
while(true) {
if (lookForChanges()) TestMojo().execute();
}
}
--
Greg Akins
http://insomnia-consulting.org
http://www.pghcodingdojo.org
http://pittjug.dev.java.net
http://twitter.com/akinsgre
http://www.linkedin.com/in/akinsgre
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Sanity Check Regarding Launching External Tools
Yep, these sound fine. - Brett On 11/10/05, Allison, Bob <[EMAIL PROTECTED]> wrote: > I just wanted to make sure that I am doing things correctly before I go > too far on the RPM plugin... > > > 1) To build the RPM, I need to run the command "rpmbuild". Based on > what I saw in the release plugin, I am using classes in package > org.codehaus.plexus.util.cli (in org.codehaus.plexus:plexus-utils) to > run the command and forward the command output to the build log. Is > this the "best practice" for a Mojo to run command-line tools? > > > 2) I am going to use a plexus archiver component (DirectoryArchiver) to > do the copying of files into the RPM work area. To get this reference, > I have the following (adapted from other plugins): >/** > * @component role="org.codehaus.plexus.archiver.Archiver" > *roleHint="dir" > */ >private DirectoryArchiver dirarchiver; > > This provides a reference, as intended, but I wanted to make sure that > this was the best way of doing things. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sanity Check Regarding Launching External Tools
I just wanted to make sure that I am doing things correctly before I go too far on the RPM plugin... 1) To build the RPM, I need to run the command "rpmbuild". Based on what I saw in the release plugin, I am using classes in package org.codehaus.plexus.util.cli (in org.codehaus.plexus:plexus-utils) to run the command and forward the command output to the build log. Is this the "best practice" for a Mojo to run command-line tools? 2) I am going to use a plexus archiver component (DirectoryArchiver) to do the copying of files into the RPM work area. To get this reference, I have the following (adapted from other plugins): /** * @component role="org.codehaus.plexus.archiver.Archiver" *roleHint="dir" */ private DirectoryArchiver dirarchiver; This provides a reference, as intended, but I wanted to make sure that this was the best way of doing things. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
