Re: M2 Issues and Actions

[Jason Dillon]

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.

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.

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.


Currently we ask the user to use svn command to checkout openejb.

What are those exact commands that we ask them to use?

--jason