You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <ds...@gluecode.com> on 2004/10/06 04:53:43 UTC
Proposed new multiproject build
I have rewritten our multiproject build to add support for windows.
The new goals all start with m: so as to not disrupt our current stuff.
Assuming everyone is happy, I would like to remove the current
multiproject and reactor goals (and drop the m: prefix). This is only
a proposal, so if people don't like it I can just delete or refactor
the goals.
Before I get to the new goals, there are a few weirdism. I disabled
the activemq tests as they take for ever (like 30 minutes) and
eventually fail. This is a hard coded disable, as maven 1 would not
let me do it in a more elegant way. I also disabled the openejb itests
as they fail every time. This failure is due to something outside of
the multiproject build (i.e. it happens in standalone openejb). I also
had to disable the geronimo itests as they use some artifacts from the
openejb itests. Hopefully these problems can be worked out and all of
the test reenabled. I have verified that the current goals work on Mac
OS X and Windows. Anyway, on the the new goals....
The main goals for the new multiproject build are:
m:default or m:build
Executes default build for all available project modules
m:clean
Deletes the 'target' directory in all available project modules
m:clean-repo
Deletes the local repository artifacts of ActiveMQ, Geronimo, HOWL,
OpenEJB, and TranQL. NOTE: This may cause problem is you do not have
the source for the all of the other projects available.
m:rebuild
Same as m:clean m:default
m:rebuild-all
Same as m:clean m:clean-repo m:default and it includes
geronimo-spec modules
m:checkout or m:co
Checks out ActiveMQ, HOWL, OpenEJB, and TranQL
m:update
Updates ActiveMQ, Geronimo, HOWL, OpenEJB, and TranQL from cvs/svn
HEAD
m:fresh-checkout
BE CAREFUL: Deletes checkout of ActiveMQ, HOWL, OpenEJB, and TranQL
and checks them out again
In addition to the above we support a -Dmodules command line option
which is a comma separated list of module names (ie. common, core, ...)
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
Re: Proposed new multiproject build
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Oct 7, 2004, at 3:27 PM, David Jencks wrote:
> not sure what you mean. What I'm talking about can be seen in the idea
> project configuration for a module: instead of a spec subproject being
> listed as a "library" it will be listed as a "dependency". As a
> result, the source code is available from the using module. For
> instance, pressing F4 on a class name will find the source code, not
> decompile the binary.
What if I don't want to import the spec stuff into my idea project... I
will have dependencies on stuff I don't have in my global project.
-dain
Re: Proposed new multiproject build
Posted by David Jencks <dj...@gluecode.com>.
On Oct 7, 2004, at 3:06 PM, Dain Sundstrom wrote:
> On Oct 7, 2004, at 1:39 PM, David Jencks wrote:
>
>>
>> On Oct 7, 2004, at 12:44 PM, Dain Sundstrom wrote:
>>
>>> On Oct 7, 2004, at 12:30 PM, David Jencks wrote:
>>>
>>>> Right, I was trying to use a checkout from the previous version of
>>>> maven.xml. I don't know why it didn't work, but after m:co
>>>> m:update works.
>>>
>>> Cool
>>>
>>>> Now I'm having what I consider a severe problem with m:idea. I
>>>> think it should include the spec modules but it doesn't.
>>>
>>> David, I think you are the only one that regularly builds specs, so
>>> if you want to add it to your idea build, just change this in your
>>> project.properties file
>>>
>>> maven.idea.project.multiproject.includes=${maven.multiproject.include
>>> s},specs/*/project.xml
>>
>> What I want is for m:idea to recognize that project dependencies to
>> specs are to other modules that are part of geronimo, so you can work
>> with the spec classes in idea in the generated projects. (this only
>> works with my maven-idea-plugin patch). I'm fine with your extra
>> target for actually building the specs.
>
> Will it link specs binaries to the maven repo or to
> target/xxxxx-version.jar?
not sure what you mean. What I'm talking about can be seen in the idea
project configuration for a module: instead of a spec subproject being
listed as a "library" it will be listed as a "dependency". As a
result, the source code is available from the using module. For
instance, pressing F4 on a class name will find the source code, not
decompile the binary.
david jencks
>
>> Another thing that defeats automatic dependency recognition is use of
>> the aggregated spec jar rather than the jars that are related to the
>> source locations.
>
> You could switch all of the modules over to not use the aggregated
> dependencies, but it will be a ton of work....
>
> -dain
>
Re: Proposed new multiproject build
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Oct 7, 2004, at 1:39 PM, David Jencks wrote:
>
> On Oct 7, 2004, at 12:44 PM, Dain Sundstrom wrote:
>
>> On Oct 7, 2004, at 12:30 PM, David Jencks wrote:
>>
>>> Right, I was trying to use a checkout from the previous version of
>>> maven.xml. I don't know why it didn't work, but after m:co m:update
>>> works.
>>
>> Cool
>>
>>> Now I'm having what I consider a severe problem with m:idea. I
>>> think it should include the spec modules but it doesn't.
>>
>> David, I think you are the only one that regularly builds specs, so
>> if you want to add it to your idea build, just change this in your
>> project.properties file
>>
>> maven.idea.project.multiproject.includes=${maven.multiproject.includes
>> },specs/*/project.xml
>
> What I want is for m:idea to recognize that project dependencies to
> specs are to other modules that are part of geronimo, so you can work
> with the spec classes in idea in the generated projects. (this only
> works with my maven-idea-plugin patch). I'm fine with your extra
> target for actually building the specs.
Will it link specs binaries to the maven repo or to
target/xxxxx-version.jar?
> Another thing that defeats automatic dependency recognition is use of
> the aggregated spec jar rather than the jars that are related to the
> source locations.
You could switch all of the modules over to not use the aggregated
dependencies, but it will be a ton of work....
-dain
Re: Proposed new multiproject build
Posted by David Jencks <dj...@gluecode.com>.
On Oct 7, 2004, at 12:44 PM, Dain Sundstrom wrote:
> On Oct 7, 2004, at 12:30 PM, David Jencks wrote:
>
>> Right, I was trying to use a checkout from the previous version of
>> maven.xml. I don't know why it didn't work, but after m:co m:update
>> works.
>
> Cool
>
>> Now I'm having what I consider a severe problem with m:idea. I think
>> it should include the spec modules but it doesn't.
>
> David, I think you are the only one that regularly builds specs, so if
> you want to add it to your idea build, just change this in your
> project.properties file
>
> maven.idea.project.multiproject.includes=${maven.multiproject.includes}
> ,specs/*/project.xml
What I want is for m:idea to recognize that project dependencies to
specs are to other modules that are part of geronimo, so you can work
with the spec classes in idea in the generated projects. (this only
works with my maven-idea-plugin patch). I'm fine with your extra
target for actually building the specs.
Another thing that defeats automatic dependency recognition is use of
the aggregated spec jar rather than the jars that are related to the
source locations.
david jencks
>
> Please don't check that change in though.
>
> -dain
>
Re: Proposed new multiproject build
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I think I missed this earlier, but how do you set your CVS account
to check out a subproject with write permissions if you use m:co? Does it
use the same properties that "maven getotherprojects" does?
Thanks,
Aaron
On Thu, 7 Oct 2004, Dain Sundstrom wrote:
> On Oct 7, 2004, at 12:30 PM, David Jencks wrote:
>
> > Right, I was trying to use a checkout from the previous version of
> > maven.xml. I don't know why it didn't work, but after m:co m:update
> > works.
>
> Cool
>
> > Now I'm having what I consider a severe problem with m:idea. I think
> > it should include the spec modules but it doesn't.
>
> David, I think you are the only one that regularly builds specs, so if
> you want to add it to your idea build, just change this in your
> project.properties file
>
> maven.idea.project.multiproject.includes=${maven.multiproject.includes},
> specs/*/project.xml
>
> Please don't check that change in though.
>
> -dain
>
>
Re: Proposed new multiproject build
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Oct 7, 2004, at 12:30 PM, David Jencks wrote:
> Right, I was trying to use a checkout from the previous version of
> maven.xml. I don't know why it didn't work, but after m:co m:update
> works.
Cool
> Now I'm having what I consider a severe problem with m:idea. I think
> it should include the spec modules but it doesn't.
David, I think you are the only one that regularly builds specs, so if
you want to add it to your idea build, just change this in your
project.properties file
maven.idea.project.multiproject.includes=${maven.multiproject.includes},
specs/*/project.xml
Please don't check that change in though.
-dain
Re: Proposed new multiproject build
Posted by David Jencks <dj...@gluecode.com>.
Right, I was trying to use a checkout from the previous version of
maven.xml. I don't know why it didn't work, but after m:co m:update
works.
Now I'm having what I consider a severe problem with m:idea. I think
it should include the spec modules but it doesn't.
thanks
david jencks
On Oct 6, 2004, at 5:39 PM, Dain Sundstrom wrote:
> This is caused when you don't have all of the modules checked out yet.
> I believe that if you drop your current checkout and checkout again
> with m:co, m:update will start working for you.
>
> BTW I have been using m:update on my mac laptop and a windows desktop,
> which is checking out anonymously, all day. I did reproduce this bug
> by doing a clean checkout and runing m:update without m:co.
>
> I'll add some jelly to not try to update modules you don't have
> checked out.
>
> -dain
>
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
>
> On Oct 6, 2004, at 11:51 AM, David Jencks wrote:
>
>> m:update doesn't work for me. Geronimo and activemq are updated,
>> then it tries to update geronimo using cvs.
>>
>> BUILD FAILED
>> File...... /Users/david/geronimo/geronimo/svn/geronimo/trunk/maven.xml
>> Element... ant:cvs
>> Line...... 205
>> Column.... 15
>> cvs exited with error code 1
>> Command line was [Executing 'cvs' with arguments:
>> 'update'
>> '-P'
>> '-d'
>>
>> The ' characters around the executable and arguments are
>> not part of the command.
>>
>>
>> environment:
>>
>> MANPATH=/sw/share/man:/usr/share/man:/usr/X11R6/man
>> SSH_AGENT_PID=6483
>> TERM_PROGRAM=Apple_Terminal
>> SHELL=/bin/bash
>> TERM=xterm-color
>> PERL5LIB=/sw/lib/perl5:/sw/lib/perl5
>> TERM_PROGRAM_VERSION=100
>> USER=david
>> SSH_AUTH_SOCK=/tmp/ssh-QTULRgs2/agent.6482
>> __CF_USER_TEXT_ENCODING=0x1F5:0:0
>> MAVEN_OPTS=-Xmx625m
>>
>> PATH=/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/Users/david/
>> java/maven/1.0binary/maven-1.0/bin:/usr/X11R6/bin
>> MAVEN_HOME=/Users/david/java/maven/1.0binary/maven-1.0
>> PWD=/Users/david/geronimo/geronimo/svn/geronimo/trunk
>> CVSIGNORE=target *.iml *.ipr *.log junit*.properties
>> HOME=/Users/david
>> SHLVL=2
>> LOGNAME=david
>> INFOPATH=/sw/share/info:/sw/info:/usr/share/info
>> SECURITYSESSIONID=20f3c0
>>
>> _=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/
>> Home/bin/java
>> JAVA_MAIN_CLASS_16297=com.werken.forehead.Forehead
>> CVS_PASSFILE=/Users/david/.cvspass
>> CVS_RSH=ssh]
>> Total time: 21 seconds
>> Finished at: Wed Oct 06 11:46:43 PDT 2004
>>
>>
>> (I think it is trying to update geronimo with cvs due to the PWD env
>> var)
>>
>> thanks
>> david jencks
>>
>>
>> On Oct 5, 2004, at 7:53 PM, Dain Sundstrom wrote:
>>
>>> I have rewritten our multiproject build to add support for windows.
>>> The new goals all start with m: so as to not disrupt our current
>>> stuff. Assuming everyone is happy, I would like to remove the
>>> current multiproject and reactor goals (and drop the m: prefix).
>>> This is only a proposal, so if people don't like it I can just
>>> delete or refactor the goals.
>>>
>>> Before I get to the new goals, there are a few weirdism. I disabled
>>> the activemq tests as they take for ever (like 30 minutes) and
>>> eventually fail. This is a hard coded disable, as maven 1 would not
>>> let me do it in a more elegant way. I also disabled the openejb
>>> itests as they fail every time. This failure is due to something
>>> outside of the multiproject build (i.e. it happens in standalone
>>> openejb). I also had to disable the geronimo itests as they use
>>> some artifacts from the openejb itests. Hopefully these problems
>>> can be worked out and all of the test reenabled. I have verified
>>> that the current goals work on Mac OS X and Windows. Anyway, on the
>>> the new goals....
>>>
>>>
>>> The main goals for the new multiproject build are:
>>>
>>> m:default or m:build
>>> Executes default build for all available project modules
>>>
>>> m:clean
>>> Deletes the 'target' directory in all available project modules
>>>
>>> m:clean-repo
>>> Deletes the local repository artifacts of ActiveMQ, Geronimo,
>>> HOWL, OpenEJB, and TranQL. NOTE: This may cause problem is you do
>>> not have the source for the all of the other projects available.
>>>
>>> m:rebuild
>>> Same as m:clean m:default
>>>
>>> m:rebuild-all
>>> Same as m:clean m:clean-repo m:default and it includes
>>> geronimo-spec modules
>>>
>>> m:checkout or m:co
>>> Checks out ActiveMQ, HOWL, OpenEJB, and TranQL
>>>
>>> m:update
>>> Updates ActiveMQ, Geronimo, HOWL, OpenEJB, and TranQL from
>>> cvs/svn HEAD
>>>
>>> m:fresh-checkout
>>> BE CAREFUL: Deletes checkout of ActiveMQ, HOWL, OpenEJB, and
>>> TranQL and checks them out again
>>>
>>>
>>> In addition to the above we support a -Dmodules command line option
>>> which is a comma separated list of module names (ie. common, core,
>>> ...)
>>>
>>> -dain
>>>
>>> --
>>> Dain Sundstrom
>>> Chief Architect
>>> Gluecode Software
>>> 310.536.8355, ext. 26
>>>
>
Re: Proposed new multiproject build
Posted by Dain Sundstrom <ds...@gluecode.com>.
This is caused when you don't have all of the modules checked out yet.
I believe that if you drop your current checkout and checkout again
with m:co, m:update will start working for you.
BTW I have been using m:update on my mac laptop and a windows desktop,
which is checking out anonymously, all day. I did reproduce this bug
by doing a clean checkout and runing m:update without m:co.
I'll add some jelly to not try to update modules you don't have checked
out.
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Oct 6, 2004, at 11:51 AM, David Jencks wrote:
> m:update doesn't work for me. Geronimo and activemq are updated, then
> it tries to update geronimo using cvs.
>
> BUILD FAILED
> File...... /Users/david/geronimo/geronimo/svn/geronimo/trunk/maven.xml
> Element... ant:cvs
> Line...... 205
> Column.... 15
> cvs exited with error code 1
> Command line was [Executing 'cvs' with arguments:
> 'update'
> '-P'
> '-d'
>
> The ' characters around the executable and arguments are
> not part of the command.
>
>
> environment:
>
> MANPATH=/sw/share/man:/usr/share/man:/usr/X11R6/man
> SSH_AGENT_PID=6483
> TERM_PROGRAM=Apple_Terminal
> SHELL=/bin/bash
> TERM=xterm-color
> PERL5LIB=/sw/lib/perl5:/sw/lib/perl5
> TERM_PROGRAM_VERSION=100
> USER=david
> SSH_AUTH_SOCK=/tmp/ssh-QTULRgs2/agent.6482
> __CF_USER_TEXT_ENCODING=0x1F5:0:0
> MAVEN_OPTS=-Xmx625m
>
> PATH=/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/Users/david/java/
> maven/1.0binary/maven-1.0/bin:/usr/X11R6/bin
> MAVEN_HOME=/Users/david/java/maven/1.0binary/maven-1.0
> PWD=/Users/david/geronimo/geronimo/svn/geronimo/trunk
> CVSIGNORE=target *.iml *.ipr *.log junit*.properties
> HOME=/Users/david
> SHLVL=2
> LOGNAME=david
> INFOPATH=/sw/share/info:/sw/info:/usr/share/info
> SECURITYSESSIONID=20f3c0
>
> _=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/
> Home/bin/java
> JAVA_MAIN_CLASS_16297=com.werken.forehead.Forehead
> CVS_PASSFILE=/Users/david/.cvspass
> CVS_RSH=ssh]
> Total time: 21 seconds
> Finished at: Wed Oct 06 11:46:43 PDT 2004
>
>
> (I think it is trying to update geronimo with cvs due to the PWD env
> var)
>
> thanks
> david jencks
>
>
> On Oct 5, 2004, at 7:53 PM, Dain Sundstrom wrote:
>
>> I have rewritten our multiproject build to add support for windows.
>> The new goals all start with m: so as to not disrupt our current
>> stuff. Assuming everyone is happy, I would like to remove the
>> current multiproject and reactor goals (and drop the m: prefix).
>> This is only a proposal, so if people don't like it I can just delete
>> or refactor the goals.
>>
>> Before I get to the new goals, there are a few weirdism. I disabled
>> the activemq tests as they take for ever (like 30 minutes) and
>> eventually fail. This is a hard coded disable, as maven 1 would not
>> let me do it in a more elegant way. I also disabled the openejb
>> itests as they fail every time. This failure is due to something
>> outside of the multiproject build (i.e. it happens in standalone
>> openejb). I also had to disable the geronimo itests as they use some
>> artifacts from the openejb itests. Hopefully these problems can be
>> worked out and all of the test reenabled. I have verified that the
>> current goals work on Mac OS X and Windows. Anyway, on the the new
>> goals....
>>
>>
>> The main goals for the new multiproject build are:
>>
>> m:default or m:build
>> Executes default build for all available project modules
>>
>> m:clean
>> Deletes the 'target' directory in all available project modules
>>
>> m:clean-repo
>> Deletes the local repository artifacts of ActiveMQ, Geronimo,
>> HOWL, OpenEJB, and TranQL. NOTE: This may cause problem is you do
>> not have the source for the all of the other projects available.
>>
>> m:rebuild
>> Same as m:clean m:default
>>
>> m:rebuild-all
>> Same as m:clean m:clean-repo m:default and it includes
>> geronimo-spec modules
>>
>> m:checkout or m:co
>> Checks out ActiveMQ, HOWL, OpenEJB, and TranQL
>>
>> m:update
>> Updates ActiveMQ, Geronimo, HOWL, OpenEJB, and TranQL from
>> cvs/svn HEAD
>>
>> m:fresh-checkout
>> BE CAREFUL: Deletes checkout of ActiveMQ, HOWL, OpenEJB, and
>> TranQL and checks them out again
>>
>>
>> In addition to the above we support a -Dmodules command line option
>> which is a comma separated list of module names (ie. common, core,
>> ...)
>>
>> -dain
>>
>> --
>> Dain Sundstrom
>> Chief Architect
>> Gluecode Software
>> 310.536.8355, ext. 26
>>
Re: Proposed new multiproject build
Posted by David Jencks <dj...@gluecode.com>.
m:update doesn't work for me. Geronimo and activemq are updated, then
it tries to update geronimo using cvs.
BUILD FAILED
File...... /Users/david/geronimo/geronimo/svn/geronimo/trunk/maven.xml
Element... ant:cvs
Line...... 205
Column.... 15
cvs exited with error code 1
Command line was [Executing 'cvs' with arguments:
'update'
'-P'
'-d'
The ' characters around the executable and arguments are
not part of the command.
environment:
MANPATH=/sw/share/man:/usr/share/man:/usr/X11R6/man
SSH_AGENT_PID=6483
TERM_PROGRAM=Apple_Terminal
SHELL=/bin/bash
TERM=xterm-color
PERL5LIB=/sw/lib/perl5:/sw/lib/perl5
TERM_PROGRAM_VERSION=100
USER=david
SSH_AUTH_SOCK=/tmp/ssh-QTULRgs2/agent.6482
__CF_USER_TEXT_ENCODING=0x1F5:0:0
MAVEN_OPTS=-Xmx625m
PATH=/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/Users/david/java/
maven/1.0binary/maven-1.0/bin:/usr/X11R6/bin
MAVEN_HOME=/Users/david/java/maven/1.0binary/maven-1.0
PWD=/Users/david/geronimo/geronimo/svn/geronimo/trunk
CVSIGNORE=target *.iml *.ipr *.log junit*.properties
HOME=/Users/david
SHLVL=2
LOGNAME=david
INFOPATH=/sw/share/info:/sw/info:/usr/share/info
SECURITYSESSIONID=20f3c0
_=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/
bin/java
JAVA_MAIN_CLASS_16297=com.werken.forehead.Forehead
CVS_PASSFILE=/Users/david/.cvspass
CVS_RSH=ssh]
Total time: 21 seconds
Finished at: Wed Oct 06 11:46:43 PDT 2004
(I think it is trying to update geronimo with cvs due to the PWD env
var)
thanks
david jencks
On Oct 5, 2004, at 7:53 PM, Dain Sundstrom wrote:
> I have rewritten our multiproject build to add support for windows.
> The new goals all start with m: so as to not disrupt our current
> stuff. Assuming everyone is happy, I would like to remove the current
> multiproject and reactor goals (and drop the m: prefix). This is only
> a proposal, so if people don't like it I can just delete or refactor
> the goals.
>
> Before I get to the new goals, there are a few weirdism. I disabled
> the activemq tests as they take for ever (like 30 minutes) and
> eventually fail. This is a hard coded disable, as maven 1 would not
> let me do it in a more elegant way. I also disabled the openejb
> itests as they fail every time. This failure is due to something
> outside of the multiproject build (i.e. it happens in standalone
> openejb). I also had to disable the geronimo itests as they use some
> artifacts from the openejb itests. Hopefully these problems can be
> worked out and all of the test reenabled. I have verified that the
> current goals work on Mac OS X and Windows. Anyway, on the the new
> goals....
>
>
> The main goals for the new multiproject build are:
>
> m:default or m:build
> Executes default build for all available project modules
>
> m:clean
> Deletes the 'target' directory in all available project modules
>
> m:clean-repo
> Deletes the local repository artifacts of ActiveMQ, Geronimo,
> HOWL, OpenEJB, and TranQL. NOTE: This may cause problem is you do not
> have the source for the all of the other projects available.
>
> m:rebuild
> Same as m:clean m:default
>
> m:rebuild-all
> Same as m:clean m:clean-repo m:default and it includes
> geronimo-spec modules
>
> m:checkout or m:co
> Checks out ActiveMQ, HOWL, OpenEJB, and TranQL
>
> m:update
> Updates ActiveMQ, Geronimo, HOWL, OpenEJB, and TranQL from cvs/svn
> HEAD
>
> m:fresh-checkout
> BE CAREFUL: Deletes checkout of ActiveMQ, HOWL, OpenEJB, and
> TranQL and checks them out again
>
>
> In addition to the above we support a -Dmodules command line option
> which is a comma separated list of module names (ie. common, core,
> ...)
>
> -dain
>
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
>
Re: Proposed new multiproject build
Posted by Dain Sundstrom <ds...@gluecode.com>.
After some thinking, I don't think this can be done directly with
maven... let me explain.
I thought we could simple do a standard reactor build (the thing that
executes maven for each sub-module) with a do nothing target such as
build:start. This would cause maven to download the dependencies or
each module but would not execute anything. The problem is maven would
attempt to download all intermodule dependencies (i.e., all geronimo,
openejb, tranql, activmq and howl jars).
I think the best approach would be to transform our version-info.ent
file into a project.xml file that only had the external dependencies.
Then we would just execute it with maven and viola all the dependencies
would download. Anyway, it is a bunch of work, so I won't be able to
get to it for a while.
-dain
On Oct 7, 2004, at 7:21 AM, Aaron Mulder wrote:
> Yuo might be interested in GERONIMO-364 in JIRA -- which is to
> provide a build target to do all the downloads in one shot so the rest
> of
> the build can be run quickly in offline mode. Dain was going to look
> into
> it in his copious free time... :)
>
> Aaron
>
> On Fri, 8 Oct 2004 sissonj@insession.com wrote:
>> It worked for me... but..
>>
>> A bit off topic, as my problems don't have anything to do with Dain's
>> changes, but I have some questions on the build processing.
>>
>> I tried the following (without cleaning my repository but with an
>> empty
>> geronimo directory):
>>
>> maven m:co
>> maven m:build
>>
>> I then got impatient because it was attempting to download artifacts
>> from
>> ibiblio over and over and also started running tests, so I cancelled
>> the
>> build and tried:
>>
>> maven m:build -o
>>
>> This then failed because I didn't have the correct version of the
>> jetty
>> jar in my repository.
>>
>> So I then tried
>>
>> maven m:build -Dmaven.test.skip=true -Dmaven.itest.skip=true
>>
>> and the build was getting plenty of timeout or connection reset errors
>> (something between ibiblio and myself having problems, as the ibiblio
>> website was timing out often also):
>>
>> Attempting to download openejb-core-2.0-SNAPSHOT.jar.
>> Error retrieving artifact from [
>> http://www.ibiblio.org/maven/openejb/jars/openejb-core-2.0-
>> SNAPSHOT.jar]:
>> java.net.ConnectException: Connection timed out: connect
>>
>> and the build finally completed in the lightening fast time of:
>>
>> BUILD SUCCESSFUL
>> Total time: 54 minutes 35 seconds
>> Finished at: Thu Oct 07 22:02:19 EST 2004
>>
>> A few questions...
>>
>> If I want to do a build of Geronimo and related projects (ActiveMQ,
>> OpenEJB, TranQL) the first two steps sound right to me:
>> maven m:co
>> maven m:build
>>
>> But when I build Geronimo (using maven m:build) I think I only want
>> it to
>> attempt to download dependencies (e.g. jetty, tomcat, xerces) from the
>> maven central repository (ibiblio) and not keep attempting to
>> download JAR
>> files for geronimo (the code I am building) such as
>> geronimo-system-1.0-SNAPSHOT.jar.
>>
>> Is there some chicken and egg situation as to why the code needs to
>> download the geronimo SNAPSHOT jars when building geronimo? If not,
>> is
>> there a way we can prevent the build from downloading the geronimo
>> SNAPSHOT jars, but download the other dependencies such as jetty?
>>
>> If we have a situation where the build is broken, is there an easy
>> way to
>> build Geronimo using all the versions of the files (svn and CVS) of
>> the
>> last successful nightly build? Am I dreaming :-) ?
>>
>> Thanks,
>>
>> John
>>
>> Dain Sundstrom <ds...@gluecode.com> wrote on 10/06/2004 12:53:43
>> PM:
>>
>>> I have rewritten our multiproject build to add support for windows.
>>> The new goals all start with m: so as to not disrupt our current
>>> stuff.
>>> Assuming everyone is happy, I would like to remove the current
>>> multiproject and reactor goals (and drop the m: prefix). This is
>>> only
>>> a proposal, so if people don't like it I can just delete or refactor
>>> the goals.
>>>
>>> Before I get to the new goals, there are a few weirdism. I disabled
>>> the activemq tests as they take for ever (like 30 minutes) and
>>> eventually fail. This is a hard coded disable, as maven 1 would not
>>> let me do it in a more elegant way. I also disabled the openejb
>>> itests
>>> as they fail every time. This failure is due to something outside of
>>> the multiproject build (i.e. it happens in standalone openejb). I
>>> also
>>> had to disable the geronimo itests as they use some artifacts from
>>> the
>>> openejb itests. Hopefully these problems can be worked out and all
>>> of
>>> the test reenabled. I have verified that the current goals work on
>>> Mac
>>> OS X and Windows. Anyway, on the the new goals....
>>>
>>>
>>> The main goals for the new multiproject build are:
>>>
>>> m:default or m:build
>>> Executes default build for all available project modules
>>>
>>> m:clean
>>> Deletes the 'target' directory in all available project modules
>>>
>>> m:clean-repo
>>> Deletes the local repository artifacts of ActiveMQ, Geronimo,
>>> HOWL,
>>
>>> OpenEJB, and TranQL. NOTE: This may cause problem is you do not have
>>> the source for the all of the other projects available.
>>>
>>> m:rebuild
>>> Same as m:clean m:default
>>>
>>> m:rebuild-all
>>> Same as m:clean m:clean-repo m:default and it includes
>>> geronimo-spec modules
>>>
>>> m:checkout or m:co
>>> Checks out ActiveMQ, HOWL, OpenEJB, and TranQL
>>>
>>> m:update
>>> Updates ActiveMQ, Geronimo, HOWL, OpenEJB, and TranQL from
>>> cvs/svn
>>> HEAD
>>>
>>> m:fresh-checkout
>>> BE CAREFUL: Deletes checkout of ActiveMQ, HOWL, OpenEJB, and
>>> TranQL
>>
>>> and checks them out again
>>>
>>>
>>> In addition to the above we support a -Dmodules command line option
>>> which is a comma separated list of module names (ie. common, core,
>>> ...)
>>>
>>> -dain
>>>
>>> --
>>> Dain Sundstrom
>>> Chief Architect
>>> Gluecode Software
>>> 310.536.8355, ext. 26
>>>
>>
>>
Re: Proposed new multiproject build
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Yuo might be interested in GERONIMO-364 in JIRA -- which is to
provide a build target to do all the downloads in one shot so the rest of
the build can be run quickly in offline mode. Dain was going to look into
it in his copious free time... :)
Aaron
On Fri, 8 Oct 2004 sissonj@insession.com wrote:
> It worked for me... but..
>
> A bit off topic, as my problems don't have anything to do with Dain's
> changes, but I have some questions on the build processing.
>
> I tried the following (without cleaning my repository but with an empty
> geronimo directory):
>
> maven m:co
> maven m:build
>
> I then got impatient because it was attempting to download artifacts from
> ibiblio over and over and also started running tests, so I cancelled the
> build and tried:
>
> maven m:build -o
>
> This then failed because I didn't have the correct version of the jetty
> jar in my repository.
>
> So I then tried
>
> maven m:build -Dmaven.test.skip=true -Dmaven.itest.skip=true
>
> and the build was getting plenty of timeout or connection reset errors
> (something between ibiblio and myself having problems, as the ibiblio
> website was timing out often also):
>
> Attempting to download openejb-core-2.0-SNAPSHOT.jar.
> Error retrieving artifact from [
> http://www.ibiblio.org/maven/openejb/jars/openejb-core-2.0-SNAPSHOT.jar]:
> java.net.ConnectException: Connection timed out: connect
>
> and the build finally completed in the lightening fast time of:
>
> BUILD SUCCESSFUL
> Total time: 54 minutes 35 seconds
> Finished at: Thu Oct 07 22:02:19 EST 2004
>
> A few questions...
>
> If I want to do a build of Geronimo and related projects (ActiveMQ,
> OpenEJB, TranQL) the first two steps sound right to me:
> maven m:co
> maven m:build
>
> But when I build Geronimo (using maven m:build) I think I only want it to
> attempt to download dependencies (e.g. jetty, tomcat, xerces) from the
> maven central repository (ibiblio) and not keep attempting to download JAR
> files for geronimo (the code I am building) such as
> geronimo-system-1.0-SNAPSHOT.jar.
>
> Is there some chicken and egg situation as to why the code needs to
> download the geronimo SNAPSHOT jars when building geronimo? If not, is
> there a way we can prevent the build from downloading the geronimo
> SNAPSHOT jars, but download the other dependencies such as jetty?
>
> If we have a situation where the build is broken, is there an easy way to
> build Geronimo using all the versions of the files (svn and CVS) of the
> last successful nightly build? Am I dreaming :-) ?
>
> Thanks,
>
> John
>
> Dain Sundstrom <ds...@gluecode.com> wrote on 10/06/2004 12:53:43 PM:
>
> > I have rewritten our multiproject build to add support for windows.
> > The new goals all start with m: so as to not disrupt our current stuff.
> > Assuming everyone is happy, I would like to remove the current
> > multiproject and reactor goals (and drop the m: prefix). This is only
> > a proposal, so if people don't like it I can just delete or refactor
> > the goals.
> >
> > Before I get to the new goals, there are a few weirdism. I disabled
> > the activemq tests as they take for ever (like 30 minutes) and
> > eventually fail. This is a hard coded disable, as maven 1 would not
> > let me do it in a more elegant way. I also disabled the openejb itests
> > as they fail every time. This failure is due to something outside of
> > the multiproject build (i.e. it happens in standalone openejb). I also
> > had to disable the geronimo itests as they use some artifacts from the
> > openejb itests. Hopefully these problems can be worked out and all of
> > the test reenabled. I have verified that the current goals work on Mac
> > OS X and Windows. Anyway, on the the new goals....
> >
> >
> > The main goals for the new multiproject build are:
> >
> > m:default or m:build
> > Executes default build for all available project modules
> >
> > m:clean
> > Deletes the 'target' directory in all available project modules
> >
> > m:clean-repo
> > Deletes the local repository artifacts of ActiveMQ, Geronimo, HOWL,
>
> > OpenEJB, and TranQL. NOTE: This may cause problem is you do not have
> > the source for the all of the other projects available.
> >
> > m:rebuild
> > Same as m:clean m:default
> >
> > m:rebuild-all
> > Same as m:clean m:clean-repo m:default and it includes
> > geronimo-spec modules
> >
> > m:checkout or m:co
> > Checks out ActiveMQ, HOWL, OpenEJB, and TranQL
> >
> > m:update
> > Updates ActiveMQ, Geronimo, HOWL, OpenEJB, and TranQL from cvs/svn
> > HEAD
> >
> > m:fresh-checkout
> > BE CAREFUL: Deletes checkout of ActiveMQ, HOWL, OpenEJB, and TranQL
>
> > and checks them out again
> >
> >
> > In addition to the above we support a -Dmodules command line option
> > which is a comma separated list of module names (ie. common, core, ...)
> >
> > -dain
> >
> > --
> > Dain Sundstrom
> > Chief Architect
> > Gluecode Software
> > 310.536.8355, ext. 26
> >
>
>
Re: Proposed new multiproject build
Posted by si...@insession.com.
It worked for me... but..
A bit off topic, as my problems don't have anything to do with Dain's
changes, but I have some questions on the build processing.
I tried the following (without cleaning my repository but with an empty
geronimo directory):
maven m:co
maven m:build
I then got impatient because it was attempting to download artifacts from
ibiblio over and over and also started running tests, so I cancelled the
build and tried:
maven m:build -o
This then failed because I didn't have the correct version of the jetty
jar in my repository.
So I then tried
maven m:build -Dmaven.test.skip=true -Dmaven.itest.skip=true
and the build was getting plenty of timeout or connection reset errors
(something between ibiblio and myself having problems, as the ibiblio
website was timing out often also):
Attempting to download openejb-core-2.0-SNAPSHOT.jar.
Error retrieving artifact from [
http://www.ibiblio.org/maven/openejb/jars/openejb-core-2.0-SNAPSHOT.jar]:
java.net.ConnectException: Connection timed out: connect
and the build finally completed in the lightening fast time of:
BUILD SUCCESSFUL
Total time: 54 minutes 35 seconds
Finished at: Thu Oct 07 22:02:19 EST 2004
A few questions...
If I want to do a build of Geronimo and related projects (ActiveMQ,
OpenEJB, TranQL) the first two steps sound right to me:
maven m:co
maven m:build
But when I build Geronimo (using maven m:build) I think I only want it to
attempt to download dependencies (e.g. jetty, tomcat, xerces) from the
maven central repository (ibiblio) and not keep attempting to download JAR
files for geronimo (the code I am building) such as
geronimo-system-1.0-SNAPSHOT.jar.
Is there some chicken and egg situation as to why the code needs to
download the geronimo SNAPSHOT jars when building geronimo? If not, is
there a way we can prevent the build from downloading the geronimo
SNAPSHOT jars, but download the other dependencies such as jetty?
If we have a situation where the build is broken, is there an easy way to
build Geronimo using all the versions of the files (svn and CVS) of the
last successful nightly build? Am I dreaming :-) ?
Thanks,
John
Dain Sundstrom <ds...@gluecode.com> wrote on 10/06/2004 12:53:43 PM:
> I have rewritten our multiproject build to add support for windows.
> The new goals all start with m: so as to not disrupt our current stuff.
> Assuming everyone is happy, I would like to remove the current
> multiproject and reactor goals (and drop the m: prefix). This is only
> a proposal, so if people don't like it I can just delete or refactor
> the goals.
>
> Before I get to the new goals, there are a few weirdism. I disabled
> the activemq tests as they take for ever (like 30 minutes) and
> eventually fail. This is a hard coded disable, as maven 1 would not
> let me do it in a more elegant way. I also disabled the openejb itests
> as they fail every time. This failure is due to something outside of
> the multiproject build (i.e. it happens in standalone openejb). I also
> had to disable the geronimo itests as they use some artifacts from the
> openejb itests. Hopefully these problems can be worked out and all of
> the test reenabled. I have verified that the current goals work on Mac
> OS X and Windows. Anyway, on the the new goals....
>
>
> The main goals for the new multiproject build are:
>
> m:default or m:build
> Executes default build for all available project modules
>
> m:clean
> Deletes the 'target' directory in all available project modules
>
> m:clean-repo
> Deletes the local repository artifacts of ActiveMQ, Geronimo, HOWL,
> OpenEJB, and TranQL. NOTE: This may cause problem is you do not have
> the source for the all of the other projects available.
>
> m:rebuild
> Same as m:clean m:default
>
> m:rebuild-all
> Same as m:clean m:clean-repo m:default and it includes
> geronimo-spec modules
>
> m:checkout or m:co
> Checks out ActiveMQ, HOWL, OpenEJB, and TranQL
>
> m:update
> Updates ActiveMQ, Geronimo, HOWL, OpenEJB, and TranQL from cvs/svn
> HEAD
>
> m:fresh-checkout
> BE CAREFUL: Deletes checkout of ActiveMQ, HOWL, OpenEJB, and TranQL
> and checks them out again
>
>
> In addition to the above we support a -Dmodules command line option
> which is a comma separated list of module names (ie. common, core, ...)
>
> -dain
>
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
>