Bleeding Edge Experience... Groovy/Maven2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bleeding Edge Experience... Groovy/Maven2

Cliff-3
Hello all,

I was just on the #groovy IRC channel chatting about my Groovy/Maven2
experience when this member suggested I start a thread on the list talking
about it. I know I'm treading very experimental ground here so I don't expect
much input but I felt that it is something I could share with you all. Who
knows, if I'm lucky somebody might chime in with some assistance. My apologies
foe the length of this as it's better suited as a blog posting (and it
probably will end up that way).

First let me begin with what lead me towards this technological combination.
I've been a devoted IntilliJ, Ant, Java developer for years and recently I
started noticing a pattern (or anti-pattern). I've been starting a bunch of
random Java projects on the side lately for various reasons and each one
reqiured the same type of effort to startup, build, and maintain. I would
frequently find myself writing the same type of Ant build files for each
project with minor variations in target/property names or step sequences, all
of them doing the same general thing, copy-resources, compile-code,
copy-testresources, compile tests, generate-reports, package, deploy. My
first stab at fighting the obvious rogue tile pattern was to create an
overall master build that defined the general steps and allowed sub-builds to
extend and override individual steps. The next problem I encountered was
managing my dependencies. I had grown a scattering of random third party jar
files across my hard drive and had trouble keeping things in order. You know,
the "which version of which API is required by this API or that one" deal. I
fought back with Ivy, an open source dependency manager. Then that brought
its own issues into my development.

I started playing with projects like SwixAT and Grails, Equinox, and Ruby
Rails, all of which stubbed out a skeleton project template for you. The
whole time I was looking for a silver bullet technology that would make
starting, coding, testing, and deploying lightning fast and at the same time
I started getting ultra comfortable with Groovy.

Long story short... Well I finally settled on what I felt was a good
combination for starting  a new project, Maven. So I dove in face first
trying to code, TDD style, a component that would allow me to write, test,
and modify XSL stylesheets (since my employer won't purchase a good XSL
editor I have to hack stuff like this). That's what started things.

Day One...
I downloaded and installed the latest version of Eclipse, and tried to install
the Groovy plugin following the instructions on the Groovy site. Well, at the
time there was a couple of minor build errors in the plugin so I contacted
Guilluame directly who replied immediately with the help I needed. Being new
to both the Language and the community I found this refreshing and
encouraging. I then installed toyed with a recently installed copy of M2 and
followed the directions on the Maven site. I was able to create a project
using the Java archetype with one command:

mvn archetype:create -DgroupId=com.mycomp.dataformat -DartifactId=Data-Format

Cool! I then decided to open my project with Eclipse (this is where things got
a little hairy since I'm rusty with Eclipse). I found a docs explaining
Maven2 Eclipse integration and had a fairly easy job getting a Maven Eclipse
project defined.

mvn eclipse:eclipse

That did the trick, and I was able to run the command directly out of Eclipse
after I set a mvn variable pointing to the mvn executable. I wrote my first
Groovy unit test intentional programming style against a class that didn't
exist. I created it under the stubbed package under the src/test/java folder.
I then created an empty definition of the nonexistant class in another groovy
script under the src/main/java folder and here's where my things got thick. I
naturally wanted to run the test to see it fail and I didn't know how. (I
still don't know how.) Well that took me on a journey learning more about
Groovy, Eclipse, and Maven2. I first decided that since there was no groovy
archetype (an archetype is a project template) in M2 I would treat the Java
archetype as a groovy project. In other words I would treat my groovy files
as Java source since they all compile to the same bytecode anyway. That would
keep me outta defining plugins and tech-specific archetypes and other
complexities that I wasn't ready for yet.

Day two...
I worked with a nice person on the Maven IRC channel who walked me through
getting Maven to compile Groovy in the most familiar way possible. We used
the ant-run plugin for this. I put the following in my pom.xml:

  <build>
    <plugins>
      <plugin>
        <artifactId>maven-antrun-plugin</artifactId>
        <executions>
                                <execution>
                                        <id>compile</id>
                                        <phase>compile</phase>
                                        <configuration>
                                                <tasks>
                                                        <taskdef name="groovyc"
                                                                classname="org.codehaus.groovy.ant.Groovyc">
                                                                <classpath refid="maven.compile.classpath"/>
                                                        </taskdef>
                                                        <groovyc destdir="${project.build.testOutputDirectory}"
                                                                srcdir="${basedir}/src/main/java/" listfiles="true">
                                                                <classpath refid="maven.compile.classpath"/>
                                                        </groovyc>
                                                </tasks>
                                        </configuration>
                                        <goals>
                                                <goal>run</goal>
                                        </goals>
                                </execution>
                                <execution>
                                        <id>test-compile</id>
                                        <phase>test-compile</phase>
                                        <configuration>
                                                <tasks>
                                                        <taskdef name="groovyc"
                                                                classname="org.codehaus.groovy.ant.Groovyc">
                                                                <classpath refid="maven.compile.classpath"/>
                                                        </taskdef>
                                                        <groovyc destdir="${project.build.testOutputDirectory}"
                                                                srcdir="${basedir}/src/test/java/" listfiles="true">
                                                                <classpath refid="maven.test.classpath"/>
                                                        </groovyc>
                                                </tasks>
                                        </configuration>
                                        <goals>
                                                <goal>run</goal>
                                        </goals>
                                </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

That bound the groovy compiler to both the compile and test-compile phases so
now I can run either

mvn compile

or

mvn test-compile to generate bytecode from my groovy sources. I started to
think, "this is better than I thought!" Then I ran:

mvn test

...and got my first failure. Big problem! All I see is the name of the test
that failed and no error info! Now I figure I can dig into Maven and get it
to spit out more info or I can run the test in question interactively under
my IDE and see better what's wrong. (Incidentally, I know what the error is
but since this is an exercise in learning as well as TDD I won't short
circuit the process.) Herein lies my current struggle. It a whole other day
has come and gone and I still don't have an answer. On the Groovy site it
explains how I can use the groovy.util.AllTest suite but when I tried that I
got an error saying that an Ant class couldn't be found. I don't want to pull
Ant in just to run a test in a project that should be M2 based. I may end up
eating those words but for now I'm still trying to find my way. I gotta sign
off now since I have some other work to do. I'll write more about my
experiences 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
|  
Report Content as Inappropriate

Re: Bleeding Edge Experience... Groovy/Maven2

Jochen Theodorou
Clifton Craig schrieb:
> Hello all,
>
> I was just on the #groovy IRC channel chatting about my Groovy/Maven2
> experience when this member suggested I start a thread on the list talking
> about it. I know I'm treading very experimental ground here so I don't expect
> much input but I felt that it is something I could share with you all. Who
> knows, if I'm lucky somebody might chime in with some assistance. My apologies
> foe the length of this as it's better suited as a blog posting (and it
> probably will end up that way).

hehe, no problem. I am not sure how much useful input I can give her, I
know nearly nothing baout maven2 besides the fact that our build file
won't run under maven2 ;)

[...]
> I
> fought back with Ivy, an open source dependency manager. Then that brought
> its own issues into my development.

can you explain this a little more? I am very interested in this issues.

[...]

> Day two...
> I worked with a nice person on the Maven IRC channel who walked me through
> getting Maven to compile Groovy in the most familiar way possible. We used
> the ant-run plugin for this. I put the following in my pom.xml:
>
>   <build>
>     <plugins>
>       <plugin>
>         <artifactId>maven-antrun-plugin</artifactId>
>         <executions>
> <execution>
> <id>compile</id>
> <phase>compile</phase>
> <configuration>
> <tasks>
> <taskdef name="groovyc"
> classname="org.codehaus.groovy.ant.Groovyc">
> <classpath refid="maven.compile.classpath"/>
> </taskdef>
> <groovyc destdir="${project.build.testOutputDirectory}"
> srcdir="${basedir}/src/main/java/" listfiles="true">
> <classpath refid="maven.compile.classpath"/>
> </groovyc>
> </tasks>
> </configuration>
> <goals>
> <goal>run</goal>
> </goals>
> </execution>
> <execution>
> <id>test-compile</id>
> <phase>test-compile</phase>
> <configuration>
> <tasks>
> <taskdef name="groovyc"
> classname="org.codehaus.groovy.ant.Groovyc">
> <classpath refid="maven.compile.classpath"/>
> </taskdef>
> <groovyc destdir="${project.build.testOutputDirectory}"
> srcdir="${basedir}/src/test/java/" listfiles="true">
> <classpath refid="maven.test.classpath"/>
> </groovyc>
> </tasks>
> </configuration>
> <goals>
> <goal>run</goal>
> </goals>
> </execution>
>         </executions>
>       </plugin>
>     </plugins>
>   </build>
>
> That bound the groovy compiler to both the compile and test-compile phases so
> now I can run either

good to know... only I am unsure about the classpath. There is a reason
why we have that root loader trick. But if maven2 handles the classpath
cleaner than ye old maven, you may not have that problem with
conflicting jars.

[...]
> mvn test-compile to generate bytecode from my groovy sources. I started to
> think, "this is better than I thought!" Then I ran:
>
> mvn test
>
> ...and got my first failure. Big problem! All I see is the name of the test
> that failed and no error info!

that must be because of maven2, or not? how about defining an error
reporter?

[...]
> On the Groovy site it
> explains how I can use the groovy.util.AllTest suite but when I tried that I
> got an error saying that an Ant class couldn't be found. I don't want to pull
> Ant in just to run a test in a project that should be M2 based.

well.. AllTest uses the filescanner from ant. but don't the groovyc task
use ant too? Groovyc extends MatchingTask, which is a ant class. So even
your project is m2 based, it still uses ant under the covers. In the
end, AllTestSuit is just a way to collect .groovy files and to execute
them as tests. As long as m2 does have something like the ant junit
task, you can do the same thing manually with precompiled files.

bye blackdrag
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bleeding Edge Experience... Groovy/Maven2

Cliff-3
Jochen,

>
> hehe, no problem. I am not sure how much useful input I can give her, I
> know nearly nothing baout maven2 besides the fact that our build file
> won't run under maven2 ;)
>

At this point I'm just sharing my experience so that's no problem.

>
> > I
> > fought back with Ivy, an open source dependency manager. Then that
> > brought its own issues into my development.
>
> can you explain this a little more? I am very interested in this issues.
>

To be honest, I liked the Ant/Ivy combo. There's really nothing wrong with it
outside of the fact that it has its own learning curve. There were some
issues early on, mostly regarding authentication with our in office proxy. I
overcame those issues using an ugly splash of Beanshell scripting in my Ant
build to set an HTTPAuthenticator. I never completely learned the project
development cycle concepts of Ivy. The real issues I fought at this stage
stemmed from having to maintain my Ant build. Once I found myself asking the
question, "how do I unit test my Ant build?" I knew I had crossed the
boundary of bad design. You see, I always felt that the build should be
simple yet powerful. Once it became a prgramming excercise rather than merely
declaring simple actions to take I had to step away for a while and think.

> good to know... only I am unsure about the classpath. There is a reason
> why we have that root loader trick. But if maven2 handles the classpath
> cleaner than ye old maven, you may not have that problem with
> conflicting jars.
>

I too am unsure about the classpath. I'm sure there's a much better way to do
this. (Maybe the Groovy M2 plugin?) This is just my first shot at
understanding and using a bunch of stuff for the first time.

>
> that must be because of maven2, or not? how about defining an error
> reporter?
>

I wouldn't even know where to begin with defining an error reporter. I see no
M2 docs on the topic and I'm not trying to do too much Ant programming to get
things to work. That would be a step backwards.

> well.. AllTest uses the filescanner from ant. but don't the groovyc task
> use ant too? Groovyc extends MatchingTask, which is a ant class. So even
> your project is m2 based, it still uses ant under the covers. In the
> end, AllTestSuit is just a way to collect .groovy files and to execute
> them as tests. As long as m2 does have something like the ant junit
> task, you can do the same thing manually with precompiled files.

Here's the thing. I didn't want to bring Ant into my Eclipse classpath just to
run interactive unit tests. That's an extra manual step that I feel should
not be necessary. I understand that M2 can automatically import Ant or
anything else as it needs to, and under M2 that would be acceptable. I was
really looking for a way for the Groovy Eclipse plugin to run the unit tests
for me. I'm looking for RAD similar to what could do in Idea with Java. In
Idea I can right click any testX method and either invoke it independently,
or create/save a JUnit run configuration for it. In Eclipse/Groovy I'll
settle for just a quick way to run a single test script independently. Maybe
I just don't have the plugin configured correctly and maybe I'm missing
something there?

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

Re: Bleeding Edge Experience... Groovy/Maven2

Jochen Theodorou
Clifton Craig schrieb:
[...]
>>> I
>>> fought back with Ivy, an open source dependency manager. Then that
>>> brought its own issues into my development.
>> can you explain this a little more? I am very interested in this issues.
>
> To be honest, I liked the Ant/Ivy combo.

I asked because Russel and some others may start a build system written
in and for groovy. This system would then use Ivy and Ant... without
much xml ;)

 > I never completely learned the project
> development cycle concepts of Ivy.

I thought Ivy is only for dependencies

>> good to know... only I am unsure about the classpath. There is a reason
>> why we have that root loader trick. But if maven2 handles the classpath
>> cleaner than ye old maven, you may not have that problem with
>> conflicting jars.
>
> I too am unsure about the classpath. I'm sure there's a much better way to do
> this. (Maybe the Groovy M2 plugin?) This is just my first shot at
> understanding and using a bunch of stuff for the first time.

There are rumors about a groovy M2 plugin, but I never have seen it.

>> that must be because of maven2, or not? how about defining an error
>> reporter?
>
> I wouldn't even know where to begin with defining an error reporter. I see no
> M2 docs on the topic and I'm not trying to do too much Ant programming to get
> things to work. That would be a step backwards.

this may have to do with the fact, that early M2 doesn't even had an ant
integration and no junit. so there was no way to execute junit on M2...
at last as I know. both are possible now, but afaik not seen as good. M2
has its own version of junit... forogt the name of the project. In the
end it is just like junit, buit no realy junit, which means the api is
completely different. GroovyTestCase wouldn't run there as expected.

[...]
> I didn't want to bring Ant into my Eclipse classpath just to
> run interactive unit tests.

AllTest is relativly new. You don't ahve to concentrate too much on it.
In the end you just have to replace it - no, you just have to replace
the file collecting. That's all. Take a look at the sources. You then
could write your own groovy-junit-plugin for M2. I heard it's easy.

> I was
> really looking for a way for the Groovy Eclipse plugin to run the unit tests
> for me.

from M2! That's important to mention here.

> I'm looking for RAD similar to what could do in Idea with Java. In
> Idea I can right click any testX method and either invoke it independently,
> or create/save a JUnit run configuration for it.

oh yes, good idea, we should add this top the eclipse plugin... But
currently the plugin doesn't do much more than basic highliting and
compile/run

> In Eclipse/Groovy I'll
> settle for just a quick way to run a single test script independently. Maybe
> I just don't have the plugin configured correctly and maybe I'm missing
> something there?

No you don't miss anything, it is just not implemented. The Plugin
really needs some work. Go to
http://docs.codehaus.org/display/GROOVY/Eclipse+Plugin+Development and
add your wishes, it's a wiki. But don't hold your breath, the active
developers are mostly no eclipse pde experts.

bye blackdrag

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bleeding Edge Experience... Groovy/Maven2

Cliff-3
Jochen,

On Thursday 30 March 2006 10:35 am, Jochen Theodorou wrote:
> I asked because Russel and some others may start a build system written
> in and for groovy. This system would then use Ivy and Ant... without
> much xml ;)
>

That's good news about the proposed build system, though it would have some
catching up to do. I played with the Groovy Ant builder stuff and it lacks a
big piece from Ant, the dependency chain. I also looked at Rake. It's
powerful but for one reason or another I can't get past Ruby's syntax. Right
now I'm seeing M2 as the cat's meow for many reasons. One big reason is how
it removes the burden of coding the build life cycle, abstracting it into a
unique concept. I also really appreciate how it transparently handles
resources. Whatever the groovy team comes up with I'd likely compare to these
features.

> I thought Ivy is only for dependencies
>

Ivy IS strictly for dependencies. What I was referring to was the dependency
management lifecycle. I only learned how to retreive dependency but there's
more to it. With Ivy your project can be installed in it's packaged form into
the local repo much the same way that M2 handles installs. That's the part I
never learned so I struggled with a multi-project build and intra-project
dependencies that probably could have been avoided had I built each project
independantly and installed them into my local repo.

> >> good to know... only I am unsure about the classpath. There is a reason
> >> why we have that root loader trick. But if maven2 handles the classpath
> >> cleaner than ye old maven, you may not have that problem with
> >> conflicting jars.

regarding that root loader trick, I take it that I need to understand it
better and watch out for side effects.

> There are rumors about a groovy M2 plugin, but I never have seen it.

I saw the plugin in the Maven sandbox. When I get time I'll try it and give
some feed back here.

> this may have to do with the fact, that early M2 doesn't even had an ant
> integration and no junit. so there was no way to execute junit on M2...
> at last as I know. both are possible now, but afaik not seen as good. M2
> has its own version of junit... forogt the name of the project. In the
> end it is just like junit, buit no realy junit, which means the api is
> completely different. GroovyTestCase wouldn't run there as expected.

The surefire plugin is what M2 uses for Unit tests. I'm not sure how different
it is from Junit or if it just uses JUnit in the background but from what I
know it is supposed to run JUnit test suites so I don't think it could afford
much of a difference. I think My problem stems from my lack of understanding
of M2 as well as trying to use it for a job that is better suited for my IDE.

> AllTest is relativly new. You don't ahve to concentrate too much on it.
> In the end you just have to replace it - no, you just have to replace
> the file collecting. That's all. Take a look at the sources. You then
> could write your own groovy-junit-plugin for M2. I heard it's easy.

I gotta try writing a simple M2 plugin now. It's burning me to try it.
Everywhere I ask for advice this always seems to come up. It is the perferred
way to get things done in M2. I'm just a little scared because I'm not sure
how involved it is.

> > I was
> > really looking for a way for the Groovy Eclipse plugin to run the unit
> > tests for me.
>
> from M2! That's important to mention here.

Thats an interesting concept. Though, I was thinking of using M2 surefire just
for running my entire collection of tests in my project and looking for the
plugin to offer a simpler solution where the script could just execute
without requiring compilation and without involving Ant, Maven or any build
specifics. It is an interpreted language after all and the test script (as
well as the tested script) should be able to just be sourced. I would reserve
the compilation step for after I finish a class definition with all green
bars. I do wonder if that adds its own unnecessary complexity dealing with
potentially both compiled and scripted definitions of the same classes. Maybe
compiled sources could and should be excluded from the JUnit execution
classpath?

> oh yes, good idea, we should add this top the eclipse plugin... But
> currently the plugin doesn't do much more than basic highliting and
> compile/run

I wish I knew enough to jump in and make the necessary mods myself! I have
read up on Eclipse plugin creation and I do have the CVS head checked out. I
feel like I'm right there. But with some many other conflicting priorities
right now it's a wonder that I can manage to even experiment with any of this
stuff.

> No you don't miss anything, it is just not implemented. The Plugin
> really needs some work. Go to
> http://docs.codehaus.org/display/GROOVY/Eclipse+Plugin+Development and
> add your wishes, it's a wiki. But don't hold your breath, the active
> developers are mostly no eclipse pde experts.

No problem. Somebody must know something though. Otherwise how did the plugin
get created in the first place?

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

Re: Bleeding Edge Experience... Groovy/Maven2

Russel Winder
On Thu, 2006-03-30 at 12:17 -0500, Clifton Craig wrote:

> That's good news about the proposed build system, though it would have some
> catching up to do. I played with the Groovy Ant builder stuff and it lacks a
> big piece from Ant, the dependency chain. I also looked at Rake. It's
> powerful but for one reason or another I can't get past Ruby's syntax. Right
> now I'm seeing M2 as the cat's meow for many reasons. One big reason is how
> it removes the burden of coding the build life cycle, abstracting it into a
> unique concept. I also really appreciate how it transparently handles
> resources. Whatever the groovy team comes up with I'd likely compare to these
> features.

I am currently doing lots of investigation into SCons and Rake with a
view to making proposals regarding how to handle the dependency issue in
using the AntBuilder in Groovy.  Unfortunately it is slow as paying work
has to be done as well :-)

I like Rake and I particularly like the internal DSL mechanism.  Jochen,
however prefers staying with a function call approach.  The issue is
whether metaclass magic underneath function call can handle all the
cases that creating a dependency tree can.  Currently the jury is out
pending some experimental evidence.  Basically I need to try building a
metaclass.

Just looking at the maven.xml file for Groovy was enough to turn me off
Maven 1 immediately.  Maven 2 however has done away with Ant and Jelly
(all taska are programmed in Java) and so may be a viable alternative.
Certainly I was thinking of creating a Maven 2 build for Groovy since
Maven 1 is really on notice of being deprecated.

Mevenide, the Maven 1 plugin for Eclipse, seems to have been a disaster
and never worked properly.  Is there a sensible working Maven 2 plugin
for Eclipse?

(Not that I use Eclipse for any serious work other than Java ME projects
but I know a lot of people can't survive without Eclipse -- or Intellij
IDEA ;-)

> Ivy IS strictly for dependencies. What I was referring to was the dependency
> management lifecycle. I only learned how to retreive dependency but there's
> more to it. With Ivy your project can be installed in it's packaged form into
> the local repo much the same way that M2 handles installs. That's the part I
> never learned so I struggled with a multi-project build and intra-project
> dependencies that probably could have been avoided had I built each project
> independantly and installed them into my local repo.

Someone did an Ant+Ivy build for Groovy as a replacement for the Maven 1
build some time ago but I am not sure if it worked, certainly most
people are still working with the Maven 1 system.

--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bleeding Edge Experience... Groovy/Maven2

Cliff-3
Hi Russel,

On Friday 31 March 2006 4:51 am, Russel Winder wrote:

> I am currently doing lots of investigation into SCons and Rake with a
> view to making proposals regarding how to handle the dependency issue in
> using the AntBuilder in Groovy.  Unfortunately it is slow as paying work
> has to be done as well :-)
>
> I like Rake and I particularly like the internal DSL mechanism.  Jochen,
> however prefers staying with a function call approach.  The issue is
> whether metaclass magic underneath function call can handle all the
> cases that creating a dependency tree can.  Currently the jury is out
> pending some experimental evidence.  Basically I need to try building a
> metaclass.

What would really be the magic bullet here would be a combination of the
Antbuilder stuff that supported all of Ant's tasks. (I don't know if it
currently does or not since the docs aren't clear on this and have not taken
the time to experiment.) I like the DSL approach too though I don't
completely understand what it means and can't explain it. I do know, however,
when something scratches the right itch. I think that build technology is
best expressed in declarative syntax such as Ant however it has to be done in
a way that it doesn't leave many of the big holes that Ant leaves. (Anyone
who has ever spent days trying to coerce/manipulate a string so that it
matches a certain pattern or anyone who has wasted days trying to pull
entries from a fileset into a property can attest to what I'm saying.)

> Just looking at the maven.xml file for Groovy was enough to turn me off
> Maven 1 immediately.  Maven 2 however has done away with Ant and Jelly
> (all taska are programmed in Java) and so may be a viable alternative.
> Certainly I was thinking of creating a Maven 2 build for Groovy since
> Maven 1 is really on notice of being deprecated.

That's what I think would be the best Idea. While it's still brand new, I love
what I'm seeing in the M2 project. I am totally taken with the idea of
declarative build technology. I beleive that's what Ant was supposed to be in
the first place. In M2 the build life cycle is completely abstracted from the
things that occur during the lifecycle. Plus given the added transitve
dependencies competing with Ivy and native multiple project support I don't
see how one could go wrong. It's just so new, that's the thing that bothers
me. It needs more docs and more time for the plugin repo to grow. (waiting
for the Groovy plugin...)

> Mevenide, the Maven 1 plugin for Eclipse, seems to have been a disaster
> and never worked properly.  Is there a sensible working Maven 2 plugin
> for Eclipse?

There is what looks like a sensible Eclipse plugin for M2 but I can't
reccomend it. I haven't gotten it to work right due partly to my lack of
understanding of M2 and partly to what I was told was a recently discovered
bug. It looks very promising though, barring they get the bug fixed.

> (Not that I use Eclipse for any serious work other than Java ME projects
> but I know a lot of people can't survive without Eclipse -- or Intellij
> IDEA ;-)

Are you talking 'bout me? ;-)

> Someone did an Ant+Ivy build for Groovy as a replacement for the Maven 1
> build some time ago but I am not sure if it worked, certainly most
> people are still working with the Maven 1 system.

Interesting, indeed. I sure wish I could be of help but unfortunately paying
work is always a priority. It's hard enough for me to even try getting some
of these newer projects to build and work for me. I'd be completely
overwhelmed with contributing, though I wish I knew enough to at least make
an occasional contribution.

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

Re: Bleeding Edge Experience... Groovy/Maven2

Russel Winder
On Fri, 2006-03-31 at 09:48 -0500, Clifton Craig wrote:

> What would really be the magic bullet here would be a combination of the
> Antbuilder stuff that supported all of Ant's tasks. (I don't know if it
> currently does or not since the docs aren't clear on this and have not taken
> the time to experiment.) I like the DSL approach too though I don't
> completely understand what it means and can't explain it. I do know, however,
> when something scratches the right itch. I think that build technology is
> best expressed in declarative syntax such as Ant however it has to be done in
> a way that it doesn't leave many of the big holes that Ant leaves. (Anyone
> who has ever spent days trying to coerce/manipulate a string so that it
> matches a certain pattern or anyone who has wasted days trying to pull
> entries from a fileset into a property can attest to what I'm saying.)
As far as I am aware the AntBuilder handles all tasks -- mostly because
it handles none, the whole point about the builder stuff is that it
effectively just processes strings.  The downside of this is the lack of
attribute checking that gives rise to problems only at the very last
moment or, as we have seen with the delete/fileset include/includes
problem, never (to totally disastrous results).

The principal problem we have in using the AntBuilder with Groovy is the
current lack of ability to express dependencies between targets.  Also
Ant allows taskdefs outside targets which I can't think of a neat way if
expressing just now.  And then there is the "subant" problem -- Ant
allows what is effectively recursive activity which is not easy to
replicate in Groovy scripts in an efficient manner.  However, I am
working on this trying to use ideas from SCons and Ant.

> That's what I think would be the best Idea. While it's still brand new, I love
> what I'm seeing in the M2 project. I am totally taken with the idea of
> declarative build technology. I beleive that's what Ant was supposed to be in
> the first place. In M2 the build life cycle is completely abstracted from the
> things that occur during the lifecycle. Plus given the added transitve
> dependencies competing with Ivy and native multiple project support I don't
> see how one could go wrong. It's just so new, that's the thing that bothers
> me. It needs more docs and more time for the plugin repo to grow. (waiting
> for the Groovy plugin...)

Basic Ant is declarative.  You only get imperative features if you use
the Ant extensions.

Maven 2 can only do the abstraction because of the structural
impositions leading to all the assumptions that can be made.  This is no
bad thing if the project structure Maven assumes actually works for all
real projects.

> > Mevenide, the Maven 1 plugin for Eclipse, seems to have been a disaster
> > and never worked properly.  Is there a sensible working Maven 2 plugin
> > for Eclipse?
>
> There is what looks like a sensible Eclipse plugin for M2 but I can't
> reccomend it. I haven't gotten it to work right due partly to my lack of
> understanding of M2 and partly to what I was told was a recently discovered
> bug. It looks very promising though, barring they get the bug fixed.
>
> > (Not that I use Eclipse for any serious work other than Java ME projects
> > but I know a lot of people can't survive without Eclipse -- or Intellij
> > IDEA ;-)
>
> Are you talking 'bout me? ;-)
Actually no, unless you want it to be ;-)

In fact, it was a little attempt to stir up all the people who say that
Eclipse is great to and that a Groovy plugin is essential to do Groovy
(or indeed any) programming to actually fix it then I can try it!

> Interesting, indeed. I sure wish I could be of help but unfortunately paying
> work is always a priority. It's hard enough for me to even try getting some
> of these newer projects to build and work for me. I'd be completely
> overwhelmed with contributing, though I wish I knew enough to at least make
> an occasional contribution.

That is the problem with a totally volunteer project as Groovy is, we
are reliant on spare time or companies putting people to work on the
project.

--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bleeding Edge Experience... Groovy/Maven2

Cliff-3
On Friday 31 March 2006 10:44 am, Russel Winder wrote:

> As far as I am aware the AntBuilder handles all tasks -- mostly because
> it handles none, the whole point about the builder stuff is that it
> effectively just processes strings.  

That's good to know.

> The downside of this is the lack of
> attribute checking that gives rise to problems only at the very last
> moment or, as we have seen with the delete/fileset include/includes
> problem, never (to totally disastrous results).

I'm not familiar with these issues. Mostly because I've only written a simple
build with Antbuilder.

> 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.

> Basic Ant is declarative.  You only get imperative features if you use
> the Ant extensions.

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.

> Maven 2 can only do the abstraction because of the structural
> impositions leading to all the assumptions that can be made.  This is no
> bad thing if the project structure Maven assumes actually works for all
> real projects.

Like I said in my response in the other thread, the structure isn't imposed.
Rather it is abstracted presenting a unique and interesting way to define
your build. What I didn't mention in the other thread is the ability to
override or add to the project structure from within the project's pom. There
you can set additional source/resource folders to your desire. I know It
feels restrictive and awkward if you don't understand it completely but I
think the idea has its merits. I think Maven2 is definitely worth a look at
if you're considering alternate build technology. Listen to me sounding like
an M2 developer! this is the Groovy list and I should be getting back to
work...

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

Re: Bleeding Edge Experience... Groovy/Maven2

Russel Winder
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.

--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
12
Loading...