geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anita kulshreshtha <>
Subject Re: M2 Issues and Actions
Date Fri, 30 Jun 2006 12:09:37 GMT

--- Jason Dillon <> 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 ( 
> 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?

> --jason

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

View raw message