Bleeding Edge Experience... Groovy/Maven2

classic Classic list List threaded Threaded
18 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Bleeding Edge Experience... Groovy/Maven2

Cliff-3
Russel,

The thing I that bothers me is the need to write a build for my project.
That's where M2 shows a huge advantage, where I only need to tweak the build.
DSLs, scripting, and declarative syntax aside I think that abstraction of the
build concepts is a huge step foward. Whether it is acheived through O-O or
through declarative style programming doesn't matter as long as that feature
is there. Also of great importance is M2's implicit resource management
through repositories. While similar features can be met with Ivy I love the
way (with M2) I don't really need to worry about where dependencies are in
the file system. I didn't have the same luxury with Ivy. These are of major
importance in the build world as many technologies are moving toward
repository based management and automatic dependency resolution (RubyGems,
debian's apt-get are other examples). Also with Ivy/Ant I was still writing
my build lifecycles and structure in each script rather than focusing on my
build specifics. So in my eyes all build systems should include these
features. I guess what I'm saying is the next big thing in Java based build
systems should be better than M2. So the question I would ask starting a new
build system is does it make sense to recode many of those features in
another technology or should those features be regarded as unimportant and
dropped? If they're important enough then maybe it would make sense to extend
Maven through groovy the same way Groovy extended Ant with the Antbuilder.
This brings me to my original point of why not compliment the M2 effort and
push some of these newer concepts to reality.
---------------------------------------------------
Clifton C. Craig, Software Engineer
Intelligent Computer Systems -  A Division of GBG
[hidden email]
[hidden email]

On Saturday 01 April 2006 1:17 am, Russel Winder wrote:

> On Fri, 2006-03-31 at 16:02 -0500, Clifton Craig wrote:
> > > However, I am working on this trying to use ideas from SCons and Ant.
> >
> > I never heard of SCons before. I'll look insto this.
>
> The main players in the build game seem to be:
>
> Make
> Autotools
> SCons
> A-A-P
> Rake
> Rant (the Ruby thing not the same named Ant thing)
> Ant
> Maven 2
>
> Make is on the way out generally.  Autotools is the AutoMake, Autoconf,
> Libtool based system created by GNU.  SCons and A-A-P are Python-based
> build systems -- SCons in particular is gaining a strong following.
> Rake and (supposedly better but...) Rant are Ruby-based systems.  Ant
> and Maven 2 are Java-based systems.
>
> In effect all these tools are showing a move towards more and more
> declarative approaches to building.  The benefit of Autootools is that
> it requires very little additional infrastructure to build a project
> release.  However, it has huge shell scripts and is generally a bit
> clunky.  In the Linux/Solaris/UNIX C/C++ world though it is the standard
> -- VC++ tends to be standard in the Windows world.
>
> SCons requires a Python installation which means most Autotools devotees
> sneer at it.  I like it especially it's ability to work well across all
> platforms.  It claims to be able to work for Java as well as C, C++,
> LaTeX, etc. but Ant and Maven are the clear front runners in the Java
> world.
>
> Rake requires Ruby and most Autotools devotees have probably never heard
> of Ruby.  Rake really is a Make replacement whereas SCons uses a
> builders approach.  I now use Rake whenever I might think of using Make
> -- the ability to programmatically synthesize dependency rules is just
> such a huge win.
>
> I haven't really got into A-A-P or Maven 2 yet but they are next on the
> list.
>
> The upshot of all this for me is that using internal DSLs rather than
> extenal DSLs is the way forward for build systems, i.e. having a
> scripting language as the base of the build specification language is
> right.  This is my worry for Ant and Maven 2 but I need to check out
> Maven 2 more.
>
> All this implies that Groovy should be the basis for the next generation
> JVM-oriented build system unless of course Maven 2 can do the job.  For
> me and others Ant XML specifications have to be replaced.
>
> My problem of the moment is whether we need to simply augment the use of
> Ant tasks through the AntBuilder or whether to create a more obvious
> internal DSL in either the SCons or the Rake mould.
>
> > I know but what I've found is that while Ant tasks/types are very
> > powerful, they leave some small gaps where you feel compelled (and are
> > sometimes forced) to break into imperative logic just to accomplish
> > something really simple or stupid.
>
> Agreed.  I find Groovy the way of handling this rather than using all
> the "imperative XML" things that people have created.  I find embedded
> Groovy scripts can solve most of the problems but that there are some
> that cannot be solved with XML as the main specification language.
> Hence the need for a scripting language as the base specification
> language.  SCons builders and Rake synthesized dependencies clearly show
> what Ant is missing.
Reply | Threaded
Open this post in threaded view
|

Re: Bleeding Edge Experience... Groovy/Maven2

Cliff-3
In reply to this post by Cliff-3
More on my M2 experiences:

(I'll keep this post short since I'm supposed to be working.)
I deviated from my M2/Groovy project and decided I would write my first M2
plugin the other day. I felt like I should understand the M2 archetecture
better before devoting my entire life to it. I started by reading the mini
howto on the groovy site and beginning a simple hello world plugin. As it
turns out, it's not hard at all to write a plugin, or at least one that says
hello. Setting up the environment, which was my biggest worry, was a snap.
Why? Because M2 already has an archetype created for plugins. Archetypes are
predefined project types that define the project structure and build
lifecycle. (I may need correcting on the build lifecycle part.) So I used the
command:

mvn archetype:create -DarchetypeArtifactId=maven-archetype-mojo
-DarchetypeGroupId=org.apache.maven.archetypes -DartifactId=my-maven2-plugin
-DgroupId=com.gbg.mojo

...and viola! I had an M2 plugin project started complete with a pre-generated
pom.xml. From my limited understanding so far, a Maven2 plugin is a
collection of what they call Mojo's each of which perform a single task. I
think that single task equates to a goal (as in M1) which would also equate
to a <task/> in Ant. In other words a plugin can have many Mojos the same way
an Ant target can contain many tasks. The upside is that plugins can be
easily shared while Ant targets cannot. The downside is that it takes a
little more effort to code a plugin than it does to inline a target in a
build. It states on there site that the way to get any custom behaviour in M2
is through writing a plugin. M2 seems to encourage coding things generically
so code can be shared.

I studied the docs some more to find out how to define the plugin behaviour.
In M2 you merely extend a base class (the same as you would in Ant) or
alternativly implement an interface with two method signatures. The interface
methods are execute() and setLogger(Logger logger). Using the base class save
you from declaring the setLogger and declaring/setting an instance variable
by offering a preimplemented getLogger(). The Logger is what you would use if
you wanted to spit some text to the screen and it works very similar (if not
exactly) to Ant's project logger. I didn't see this much at first so my
plugin just wrote "Hello" to stdout. Actually, being a TDD addict, I started
writing my plugin's test case first. So in my test case I anticipated "Hello"
being written to std out and proceeded that way.

package com.gbg.mojo;

import java.io.ByteArrayOutputStream;
import java.io.PrintStream;

import junit.framework.TestCase;

public class HelloMojoTest extends TestCase {
        public void testExecute() throws Exception
        {
                PrintStream stdout = System.out;
                ByteArrayOutputStream testOut = new ByteArrayOutputStream();
                System.setOut(new PrintStream(testOut));
                HelloMojo helloMojo = new HelloMojo();
                helloMojo.execute();
                System.setOut(stdout);
                assertEquals("Hello",new String(testOut.toByteArray()).trim());
        }
}

For whatever reason when I finally implemented the Mojo and ran my test I was
getting an extra space on the end of my output string, hence the trim call in
the assert. That was really all there was to it. I wrote the test, stubbed my
impl, compiled and ran it via mvn test (which automatically runs through the
compile step for me). The beautiful thing is I didn't write one line of build
logic. Had this been an Ant-based project or Groovy Ant builder I would have
spent time defining 20-30 properties and types that laid out my project
structure and paths, time defining exactly how to compile and execute tests
and what to compile and test, and more time defining the steps of the build
and more time figuring out why a certain step was skipped or a certain file
wasn't copied over. I then noticed one of M2's flaws. The test ran and failed
but I didn't get any detail about why it failed. From what I understand,
you're supposed to take errors like that and re-run the failing test in
interactive mode. No problem, so that's what I did. A few cycles of test,
refactor, compile, test and I ended up with the following:

package com.gbg.mojo;

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.MojoFailureException;

/**
 *
 * @author ccc
 *
 * @goal hello
 * @description Says hello to stdout
 */
public class HelloMojo extends AbstractMojo {

        public void execute() throws MojoExecutionException, MojoFailureException {
                System.out.println("Hello");
        }

}

The annotations you'll note in the code help Maven define the plugin
descriptor for you. It's an XDoclet-ish thing that, in this case, tells Maven
what goal to bind my Mojo to and what description text to show should I ever
generate documentation for my plugin. There's a bunch of other annotations
for things such as plugin parameters and such. So that was all there was to
it. one more command:

mvn install

and my plugin was re-compiled, retested, packaged, and installed in my maven
repository cache. I ran it with the command:

mvn com.gbg.mojo:my-maven2-plugin:hello

And I saw my hello text on the console. Not bad for a first attempt. I also
noticed in the Maven docs that you can define plugins in alternate scripting
languages though it doesn't tell you how. There is a mini howto on defininig
pluging using Ant syntax, interestingly enough. I may try exploring the
scripting plugin support later. But for now I'm going to look into creating
custom archetypes and build life cycles to make sure I understand it
completely.

---------------------------------------------------
Clifton C. Craig, Software Engineer
Intelligent Computer Systems -  A Division of GBG
[hidden email]
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Bleeding Edge Experience... Groovy/Maven2

Cliff-3
In reply to this post by Cliff-3
Hello all,

I've not posted any activity regarding my experience with Groovy and Maven2 in
a while so I figured a breif update was in order. First off, I'm not sure if
I said this already but I've written my first M2 plugin. Apparently you can
write a plugin in Java, Beanshell or Ant. (There's hooks for any language
just not support out of the box.) Secondly, I found the Maven book recently
published and freely available online so I started reading it. Also we have
started to use Maven2 on pieces of our project and the benefits are already
showing. The coolest thing I discovered was Maven-proxy which allows us to
transparently mirror the Ibiblio Maven2 repository in house, dynamically
fetching and caching only the files we need/use from Ibibilio.

I haven't done anything with Groovy and Maven but I plan to soon. The more I
learn about Maven2 the more I'm starting to question why it wouldn't be the
Ideal build candidate for Groovy. Keeping in mind that I know next to nothing
about Maven 1 except from what I've read in Maven2 docs I understand Groovy's
build (which is based on M1) to be unnecessarily clumsy which is why effort
is underway to create a new Groovy build technology. I was previously against
the idea of yet another build technology but I now I don't see it as such a
bad idea, just maybe not as important as others see it. I think I'm going to
read some more (and practice) Maven2 then see if I can understand, on a high
level, the steps involved in building Groovy. I'd like to see if Maven2 along
with a fresh perspective could simplify some things. Prior to that, I'd like
to write a M2 plugin in Groovy, then maybe even see about Groovy support for
plugin definition. Apparently M2 has support for plugins written in any
language. I'm just not sure if the meta classes (or adapter classes) are
there for languages other than Java, Beanshell, and Ant. It's going to be
fun. I'll try to keep posting back here all of my progress.
---------------------------------------------------
Clifton C. Craig, Software Engineer
Intelligent Computer Systems -  A Division of GBG
[hidden email]
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Bleeding Edge Experience... Groovy/Maven2

Guillaume Laforge
Administrator
Thanks a lot for keeping on sharing your experience with us!

On 4/30/06, Clifton Craig <[hidden email]> wrote:

> Hello all,
>
> I've not posted any activity regarding my experience with Groovy and Maven2 in
> a while so I figured a breif update was in order. First off, I'm not sure if
> I said this already but I've written my first M2 plugin. Apparently you can
> write a plugin in Java, Beanshell or Ant. (There's hooks for any language
> just not support out of the box.) Secondly, I found the Maven book recently
> published and freely available online so I started reading it. Also we have
> started to use Maven2 on pieces of our project and the benefits are already
> showing. The coolest thing I discovered was Maven-proxy which allows us to
> transparently mirror the Ibiblio Maven2 repository in house, dynamically
> fetching and caching only the files we need/use from Ibibilio.
>
> I haven't done anything with Groovy and Maven but I plan to soon. The more I
> learn about Maven2 the more I'm starting to question why it wouldn't be the
> Ideal build candidate for Groovy. Keeping in mind that I know next to nothing
> about Maven 1 except from what I've read in Maven2 docs I understand Groovy's
> build (which is based on M1) to be unnecessarily clumsy which is why effort
> is underway to create a new Groovy build technology. I was previously against
> the idea of yet another build technology but I now I don't see it as such a
> bad idea, just maybe not as important as others see it. I think I'm going to
> read some more (and practice) Maven2 then see if I can understand, on a high
> level, the steps involved in building Groovy. I'd like to see if Maven2 along
> with a fresh perspective could simplify some things. Prior to that, I'd like
> to write a M2 plugin in Groovy, then maybe even see about Groovy support for
> plugin definition. Apparently M2 has support for plugins written in any
> language. I'm just not sure if the meta classes (or adapter classes) are
> there for languages other than Java, Beanshell, and Ant. It's going to be
> fun. I'll try to keep posting back here all of my progress.
> ---------------------------------------------------
> Clifton C. Craig, Software Engineer
> Intelligent Computer Systems - A Division of GBG
> [hidden email]
> [hidden email]
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|

Re: Bleeding Edge Experience... Groovy/Maven2

tugwilson
In reply to this post by Cliff-3

On 30 Apr 2006, at 14:41, Clifton Craig wrote:

> Apparently M2 has support for plugins written in any
> language. I'm just not sure if the meta classes (or adapter  
> classes) are
> there for languages other than Java, Beanshell, and Ant


If you are dealing with complied Groovy classes (i.e. .class files)  
then I would expect M2 to be able to treat then just like Java  
classes. If you can get M2 to use the Groovy classloader then you  
should be able to use .groovy files.

There's a #maven channel on the codehaus IRC server  
(irc.codehaus.org)  -I think the Maven Mavens hang out there.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org


Reply | Threaded
Open this post in threaded view
|

Re: Bleeding Edge Experience... Groovy/Maven2

Cliff-3
In reply to this post by Cliff-3
Ready for the play by play? I'm in the process of learning about the Groovy
plugins for Maven2. I started a couple of hours ago by visiting the
mojo.codehaus.org site and reading up on how to use the plugin sandbox. What
I did so far was checkout the mojo-site project from the svn repo @ codehaus
via:
svn checkout https://svn.codehaus.org/mojo/trunk/mojo mojo-site
in an empty folder. This retrieved all of the plugin source code for all of
the plugins hosted on the mojo site. I read some more and learned that I have
to enable the snapshot repo @ the mojo.codehaus site in either my POM or as a
profile setting in my settings.xml. Since I got real good at editing my
settings.xml recently (trying to setup maven-proxy) I opted for that route.

settings.xml:
<profile>
    <id>Snapshots</id>
    <repositories>
      <repository>
        <id>Maven Snapshots</id>
        <url>http://snapshots.maven.codehaus.org/maven2/</url>
        <snapshots>
          <enabled>true</enabled>
        </snapshots>
        <releases>
          <enabled>false</enabled>
        </releases>
     </repository>
   </repositories>
   <pluginRepositories>
     <pluginRepository>
       <id>Maven Snapshots</id>
       <url>http://snapshots.maven.codehaus.org/maven2/</url>
       <snapshots>
         <enabled>true</enabled>
       </snapshots>
       <releases>
         <enabled>false</enabled>
       </releases>
     </pluginRepository>
   </pluginRepositories>
  </profile>

I activate this profile with a "-PSnapshots" switch setting on the mvn command
line. So far so good. I wanted to see the docs on the groovyc plugin so the
first thing I did from here was cd into the subfolder containing the plugin's
source and execute "mvn -PSnapshots site" I get an error stating that it
can't find the java-alike jar or something like that. I look up a directory
and see that there is some plugin source by that very same name. I got
excited , cd'ed into the folder, ran "mvn -PSnapshots install" and started
this email to express my zeal. The build just finished succesfully so I'm
going back to see what else I can learn. I'm thinking how cool this is going
to be since I finally got maven-proxy running. I can deploy to my maven-proxy
instance this plugin and any other that I wish then my whole team can
benefit. Really cool things are happening, I'll write more later...

On Sunday 30 April 2006 9:41 am, Clifton Craig wrote:

> Hello all,
>
> I've not posted any activity regarding my experience with Groovy and Maven2
> in a while so I figured a breif update was in order. First off, I'm not
> sure if I said this already but I've written my first M2 plugin. Apparently
> you can write a plugin in Java, Beanshell or Ant. (There's hooks for any
> language just not support out of the box.) Secondly, I found the Maven book
> recently published and freely available online so I started reading it.
> Also we have started to use Maven2 on pieces of our project and the
> benefits are already showing. The coolest thing I discovered was
> Maven-proxy which allows us to transparently mirror the Ibiblio Maven2
> repository in house, dynamically fetching and caching only the files we
> need/use from Ibibilio.
>
> I haven't done anything with Groovy and Maven but I plan to soon. The more
> I learn about Maven2 the more I'm starting to question why it wouldn't be
> the Ideal build candidate for Groovy. Keeping in mind that I know next to
> nothing about Maven 1 except from what I've read in Maven2 docs I
> understand Groovy's build (which is based on M1) to be unnecessarily clumsy
> which is why effort is underway to create a new Groovy build technology. I
> was previously against the idea of yet another build technology but I now I
> don't see it as such a bad idea, just maybe not as important as others see
> it. I think I'm going to read some more (and practice) Maven2 then see if I
> can understand, on a high level, the steps involved in building Groovy. I'd
> like to see if Maven2 along with a fresh perspective could simplify some
> things. Prior to that, I'd like to write a M2 plugin in Groovy, then maybe
> even see about Groovy support for plugin definition. Apparently M2 has
> support for plugins written in any language. I'm just not sure if the meta
> classes (or adapter classes) are there for languages other than Java,
> Beanshell, and Ant. It's going to be fun. I'll try to keep posting back
> here all of my progress.

---------------------------------------------------
Clifton C. Craig, Software Engineer
Intelligent Computer Systems -  A Division of GBG
[hidden email]
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Bleeding Edge Experience... Groovy/Maven2

Cliff-3
Rats! Dead in the water it seems! I tried installing the groovyc-maven-plugin
and I get errors regarding 4 missing artifacts. I don't quite understand why
this is so, I have the sandbox enabled as well as my htpp proxy settings.
Apparently the plugin is calling for something it can't find on the sandbox
or on my maven-proxy instance. I'll have to get back to this later when I
have time. For now it was fun while it lasted. I really need a blog to put
this stuff on. Can anybody suggest good free blog hosting?

On Wednesday 10 May 2006 2:45 pm, Clifton Craig wrote:

> Ready for the play by play? I'm in the process of learning about the Groovy
> plugins for Maven2. I started a couple of hours ago by visiting the
> mojo.codehaus.org site and reading up on how to use the plugin sandbox.
> What I did so far was checkout the mojo-site project from the svn repo @
> codehaus via:
> svn checkout https://svn.codehaus.org/mojo/trunk/mojo mojo-site
> in an empty folder. This retrieved all of the plugin source code for all of
> the plugins hosted on the mojo site. I read some more and learned that I
> have to enable the snapshot repo @ the mojo.codehaus site in either my POM
> or as a profile setting in my settings.xml. Since I got real good at
> editing my settings.xml recently (trying to setup maven-proxy) I opted for
> that route.
>
> settings.xml:
> <profile>
>     <id>Snapshots</id>
>     <repositories>
>       <repository>
>         <id>Maven Snapshots</id>
>         <url>http://snapshots.maven.codehaus.org/maven2/</url>
>         <snapshots>
>           <enabled>true</enabled>
>         </snapshots>
>         <releases>
>           <enabled>false</enabled>
>         </releases>
>      </repository>
>    </repositories>
>    <pluginRepositories>
>      <pluginRepository>
>        <id>Maven Snapshots</id>
>        <url>http://snapshots.maven.codehaus.org/maven2/</url>
>        <snapshots>
>          <enabled>true</enabled>
>        </snapshots>
>        <releases>
>          <enabled>false</enabled>
>        </releases>
>      </pluginRepository>
>    </pluginRepositories>
>   </profile>
>
> I activate this profile with a "-PSnapshots" switch setting on the mvn
> command line. So far so good. I wanted to see the docs on the groovyc
> plugin so the first thing I did from here was cd into the subfolder
> containing the plugin's source and execute "mvn -PSnapshots site" I get an
> error stating that it can't find the java-alike jar or something like that.
> I look up a directory and see that there is some plugin source by that very
> same name. I got excited , cd'ed into the folder, ran "mvn -PSnapshots
> install" and started this email to express my zeal. The build just finished
> succesfully so I'm going back to see what else I can learn. I'm thinking
> how cool this is going to be since I finally got maven-proxy running. I can
> deploy to my maven-proxy instance this plugin and any other that I wish
> then my whole team can benefit. Really cool things are happening, I'll
> write more later...
>

---------------------------------------------------
Clifton C. Craig, Software Engineer
Intelligent Computer Systems -  A Division of GBG
[hidden email]
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Bleeding Edge Experience... Groovy/Maven2

Cliff-3
Double drats! I thought I had it! Two things going on here. 1st, I noticed the
groovyc plugin had a dependency on groovy-1.0-JSR-03-SNAPSHOT. That caused me
problems in the past. I changed it to depend on groovy-all-1.0-JSR-05. 2nd,
why do the groovy-1.0-JSR-XX-snapshots have unreachable dependencies on
ibibilio? It seems like a problem that should be fixed or maybe I'm not
understanding something? Anyway, changing the dependency fixed the four
missing artifact error in my build but I still get a missing artifact error
regarding plexus-compiler-groovyc. I can see where that's a requirement but I
don't know where to find it. It's not on the Mojo repo and obviously not on
the official Ibiblio repo. I'm stuck again! Ok, now I'm really calling it
quits at this point!

---------------------------------------------------
Clifton C. Craig, Software Engineer
Intelligent Computer Systems -  A Division of GBG
[hidden email]
[hidden email]
12