You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/06/10 16:47:44 UTC

Maven Integration

Leo, I know you are hard at work on getting Avalon to work with Maven.
My question to you is which version are you using (CVS, Beta 8, ...)?
I would prefer to use a released version.

Also, GUMP does run with it, right?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Maven Integration

Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> 
> Leo, I ran Maven and got the following results:
> 
> $ maven jar
> 
> ' Skip all the output
> 
> with the one JAR file that we normally get.  I thought you said
> something about split jars.  When I ran the "avalon:jars" goal
> which I thought was needed, I got the following results:
> 


Ok.  When I ran

$ maven dist

I got everything.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Maven Integration

Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> $ maven jar  [results in one jar]

hmm. In buildsystem/maven-common.xml, it says:

     <!-- build api and impl jars as well -->
     <preGoal name="java:jar">
         <attainGoal name="avalon:custom-jar"/>
     </preGoal>


where 'avalon:custom-jar' builds the -api and -impl jars. I just found 
in the CVS version of maven for the java:jar goal:

	java:jar is deprecated and will be removed. Please use
	jar:jar

and java:jar redirects to jar:jar (as does 'jar'). So the preGoal should 
probably change to be for jar:jar. Trial-and-error!

> $ maven avalon:jars

obviously doesn't work as expected :D

     <goal name="avalon:jars"
             description="builds all jars">

         <attainGoal name="avalon:header"/>
         <maven:reactor
           basedir="${basedir}"
           includes="*/project.xml"
           goals="java:jar"
           banner="Excalibur is building jar:"
           ignoreFailures="false"/>
     </goal>

this came from the maven.xml in excalibur cvs. Unfortunately,

           includes="*/project.xml"

doesn't match anything! It should read

           basedir="${basedir}/.."

I guess.

- LSD



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Maven Integration

Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> TODO list
> ---------
> - trial gump integration (first run tonite)
> - get you guys to test things and play around, make a few suggestions, 
> complain
> - get a green light on the new api/impl seperation I put in place
> - copy sourcefiles over on the server from the old to the new locations 
> (target date: sunday, unless you guys are still uncomfortable with maven 
> :D)
> - integrate PGP signing and basic key management using <ant:exec/>
> - get maven-forrest-plugin committed and uploaded to ibiblio
> - refactor the huge buildsystem scripts into a more reusable 
> maven-avalon-build-plugin or something like that
> - more docs
> - more tests
> - setup reactor builds (so you can do `cd fortress; maven dist` to build 
> fortress and all subprojects, for example)


Leo, I ran Maven and got the following results:

$ maven jar

' Skip all the output

with the one JAR file that we normally get.  I thought you said
something about split jars.  When I ran the "avalon:jars" goal
which I thought was needed, I got the following results:


$ maven avalon:jars
  __  __
|  \/  |__ Jakarta _ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0-beta-9-SNAPSHOT


avalon:jars:
avalon:header:
     [echo]
             __
            /  \    Apache
           /    \__________________________________
          /  /\  \  \/  /    \ |  |  /   \|   \|  |
         /  /  \  \    /  /\  \|  |_|  O  |  \ \  |
        /__/    \__\__/__/  \__\_____\__ /|__|\___|     Build System

Starting the reactor...
Our processing order:
BUILD SUCCESSFUL
Total time:  4 seconds


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Maven Integration

Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> TODO list
> ---------
> - trial gump integration (first run tonite)
> - get you guys to test things and play around, make a few suggestions, 
> complain
> - get a green light on the new api/impl seperation I put in place
> - copy sourcefiles over on the server from the old to the new locations 
> (target date: sunday, unless you guys are still uncomfortable with maven 
> :D)
> - integrate PGP signing and basic key management using <ant:exec/>

:)  I use GPG.

gpg --detach-sign -a ${filename}

> - get maven-forrest-plugin committed and uploaded to ibiblio
> - refactor the huge buildsystem scripts into a more reusable 
> maven-avalon-build-plugin or something like that
> - more docs
> - more tests
> - setup reactor builds (so you can do `cd fortress; maven dist` to build 
> fortress and all subprojects, for example)

This isn't so critical if we can get the latest as a download.


<snip type="lot's of cool stuff"/>

Sounds great.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Maven Integration

Posted by Leo Simons <le...@apache.org>.
TODO list
---------
- trial gump integration (first run tonite)
- get you guys to test things and play around, make a few suggestions, 
complain
- get a green light on the new api/impl seperation I put in place
- copy sourcefiles over on the server from the old to the new locations 
(target date: sunday, unless you guys are still uncomfortable with maven :D)
- integrate PGP signing and basic key management using <ant:exec/>
- get maven-forrest-plugin committed and uploaded to ibiblio
- refactor the huge buildsystem scripts into a more reusable 
maven-avalon-build-plugin or something like that
- more docs
- more tests
- setup reactor builds (so you can do `cd fortress; maven dist` to build 
fortress and all subprojects, for example)

I would like to get all this done in a week or two. It is probably 
easiest if I just do most stuff, but I really do need everyone to take a 
look and try things out. Otherwise we fall in the same trap we did with 
excalibur: a state of the art build system that only 2 people could 
maintain.

Longer term:

- fix the maven-gump-plugin and refactor the buildsystem to use it
- figure out what to do about automated site management. I think 
forrestbot will still be able to (or easily adjusted to) do automated 
publishing, but I would like javadoc publishing, test report publishing, 
etc etc, everything automated.
- setup component builds.....working on that already...

bash-2.05b$ pwd
/mnt/data/home/lsimons/cvs/avalon-new/avalon-components
bash-2.05b$ ls
cornerstone-connection   excalibur-compatibility  excalibur-logger
cornerstone-datasource   excalibur-configuration  excalibur-monitor
cornerstone-event        excalibur-datasource     excalibur-pool
cornerstone-rmification  excalibur-event         excalibur-sourceresolve
cornerstone-scheduler    excalibur-extension      excalibur-store
cornerstone-sockets      excalibur-i18n           excalibur-thread
cornerstone-store        excalibur-instrument     excalibur-xfc
cornerstone-threads      excalibur-lifecycle      excalibur-xmlutil
cornerstone-xml          excalibur-loader         pending-removal

but actually writing all the POMs is a terribly unsexy job (yes, even 
more unsexy than build systems!).

Rationale
---------
Why do this?

maven is way more powerful than ant for a few reasons:

- scriptable. Jelly is a fully functional (if awkward) scripting 
language and you can just use it everywhere. Furthermore, you can 
transparently move a goal (maven version of ant's "target") from a 
maven.xml file to some other scriptfile to a jelly-based plugin to java 
sources, without having to change how you use

- workflow. there's <preGoal/>, <postGoal/> and <attainGoal/>, which are 
immensely useful.

- sensible data seperation. The maven project object model is not 
perfect, but seperating it from the build logic makes things a lot 
cleaner. It is much easier to share build logic by writing plugins 
(contrast to the forrest-targets.ent that ant uses, for example)

- dependency management on a sensible level. Dependency management in 
current maven (as opposed to maven-new) may be of limited flexibility, 
one can say that it "Just Works". Most java projects manage deps at the 
jar level, and maven does, too.

- kitchen sink. You can use *any* ant task within a jelly script within 
maven, as well as any jelly tag library, as well as loads of maven 
plugins, and many of them are provided with the distro or auto-installed 
when you install maven.

All this means that you might need one or two custom plugins (or like 
set up now, common jelly scripts, but that's actually less desirable) 
that will take some time to write and set up (especially since the only 
way to learn atm is by example), but that it is a lot easier to maintain 
components; usually all you need is a small project.xml (like, for example,

http://cvs.apache.org/viewcvs.cgi/*checkout*/avalon/fortress/tools/project.xml, 


which actually fits on a single screen). And after that, building a 
release, generating and e-mailing an announcement, signing the releases, 
uploading to the right places looks like:

maven dist -Doverride.version=1.2
maven dist:sign -Doverride.version=1.2     # todo
maven avalon:deploy -Doverride.version=1.2
maven site
maven avalon:deploy-site                   # todo

Anyways, I was sceptical for a long time, but not anymore. Maven beta-9 
provides a ***-load of features, is easy enough to install, stable 
enough to handle big projects, nearly backwards-compatible with ant (you 
can copy large chunks of an existing build.xml into a maven.xml file and 
it will work), and has a rapidly growing dev and user community.

enough blah-blah for today :D

g'night!

- LSD



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Maven Integration

Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> Leo, I know you are hard at work on getting Avalon to work with Maven.
> My question to you is which version are you using (CVS, Beta 8, ...)?

I'm using beta-9 (latest release). I think beta-8 would work as well. 
I've tried the cvs version and it works as well.

> I would prefer to use a released version.

+1

> Also, GUMP does run with it, right?

what I've set up right now is generating ant buildfiles and gump 
descriptors from the maven descriptors (try cd avalon/buildsystem; maven 
avalon:info for, you got it, info). That works (though not actually 
tested for avalon yet). I will run tests on my own machines before 
switching over.

What would be better is a <maven/> tag for gump, as it makes more sense 
to me to have gump support maven builds than the other way around, since 
one of the gump design goals is to use the same environment the 
developers use, which of course means it should run maven if we use 
maven :D. I am expecting this to be a lot more difficult to do cleanly, 
since the maven dependency tree is rather bigger than that of ant.

- LSD



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org