inline.. --- Jason Dillon <[EMAIL PROTECTED]> wrote:
> > 2. Spec Jars - > > The geronimo spec jars need to be published along with the poms. > > This was supposed to happen soon after the 1.1 release. And it has happened. Thanks! > > Are there any issues with this? > > Does this have any relation to the proposed reorg of the specs into > multiple trunks? > > > > 4. Maven does not allow building a plugin and a module if the > module > > uses the plugin in the same build. As a result the first time build > is > > a 3 step process. Jason suggested "IMO we should have a completely > > separate tree for our build support tools. And once the plugins > are > > stable we release them, until they are stable we make regular > > snaps, so > > that the main tree(s) can just build w/o having to worry about > > building > > plugins first." > > I'm not sure how easy this is going to be... > > We many need to introduce a bootstrap phase to build a few modules > and a plugin or two and then run through the full build. > > Not terribly ideal IMO, but probably the easiest way to get the m2 > build functional in the least amount of time. I hope that we can > eventually eliminate the need for the bootstrap, but from what I > understand so far this is not going to be something we can do easily > > in a short amount of time (defs not with the RTC muck). > > > > We should start publishing SNAPSHOTs ASAP to solve this > problem, > > This is very user friendly. Once we have assembled our first full > > server, we can start thinking of reorganizing the source tree. > > While this may work most of the time, it is not ideal as when making > > changes to plugins, users will be mystified when those changes are > not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. > > I'd prefer to minimize the utilization of remote maven > repositories... not increase them. IMO remote repository is growing > > to become more and more of a build anit-pattern. > > > > 5. checking out openejb - In M1 we could define goals like m:co, it > is > > not possible to do this in M2. There is no way to specify > > executions in > > the top level pom that are not inherited by the children. And we > must > > resort to checking out each module and building it! > > There are a few more options here. A module that exists to solely > check out openejb and then run the openejb build as a part of our > build. This can be easily facilitated with antrun and some well > placed dependencies. > > Or use svn:externals ( http://svnbook.red-bean.com/nightly/en/svn- > book.html#svn.advanced.externals ) to force SVN to check out the > openejb tree when Geronimo is checked out. Would need to have users > > svn up in the openejb tree from time to time though, as last I > checked svn:externals are ignored when the local working space is > updated. Jacek is working on this. Thanks Jacek! > > > > Currently we ask the user to use svn command to checkout openejb. > > What are those exact commands that we ask them to use? http://cwiki.apache.org/confluence/display/GMOxDEV/Building+Apache+Geronimo+with+Maven+2 Thanks Anita > > --jason > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
