The existing commands to build are -
cd modules, mvn clean
cd ..\m2-plugins, mvn
and After this as long as you do not wipe out the plugin, one can use
just mvn from the top directory to get a full build.
Did these not work for you (after you had the right xmlbeans
plugin)?
The new build (GERONIMO-2161) uses 2 step process -
mvn -Dstaqge=bootstrap
mvn -Dstage=assemble
The bootstrap stage still builds all the modules! The assemble stage
does not build them. User will be forced to always use 2 commannds -
clean repo or not. Which I think is not very user firendly.
Hiding building modules and plugins in a bootstrap phase is more
user friendly. Because the users will not be exposed to the shortcoming
of maven.
Thanks
Anita
--- Jason Dillon <[EMAIL PROTECTED]> wrote:
> What "user friendliness" are you talking about?
>
> --jason
>
>
> On Jul 5, 2006, at 2:25 AM, anita kulshreshtha wrote:
>
> > I would also prefer to see any changes to improve the
> > maintainability and user friendliness of M2 build be held off
> until
> > the server assembly is functional.
> >
> > Thanks
> > Anita
> >
> > --- David Jencks <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> On Jul 5, 2006, at 12:25 AM, John Sisson wrote:
> >>
> >>> Jacek Laskowski wrote:
> >>>> On 7/3/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
> >>>>> NOTE... the m2 build in trunk is already broken... this patches
> >> help
> >>>>> FIX MANY OF THOSE PROBLEMS!
> >>>>
> >>>> NOTED, but... it's not broken. it has never worked so we can
> >> pretend
> >>>> to call it broken. It's a small, but important point we cannot
> >>>> dismiss.
> >>>>
> >>>>> Since the official build is still m1 and this will not affect
> the
> >> m1
> >>>>> build, I don't see why your point about breakage is applicable
> at
> >>
> >>>>> all.
> >>>> ...
> >>>>> When I first created the m1 build for Geronimo years ago there
> >> were
> >>>>> certainly a few moments of breakage due to build changes, but
> >> since
> >>>>> there was no commit by committee junk going on then it was easy
> >> to
> >>>>> just fix when things happened to get a bit askew.
> >>>>>
> >>>>> The branch idea was just to make it easier to actually make
> >>>>> progress,
> >>>>> as I am move on this stuff way way faster than the lot of you
> can
> >>>>> react to emails and JIRAs which often (as this one did) need
> >> several
> >>>>> sets of emails to clarify.
> >>>>
> >>>> That's the point in RTC - discussing, discussing, over and over
> >>>> again.
> >>>> I'm not in favour of RTC, but some of its rules are fine. It
> >> fosters
> >>>> discussions we lacked. That's the main point of RTC. Isn't it
> >> funny
> >>>> that you've mentioned it as an argument against RTC?
> >>>>
> >>>> What's wrong with committing changes made in the branch back to
> >> trunk
> >>>> once they've been tested? My proposal is not to wait until the
> >>>> migration is done, but rather apply it in small portions,
> >> gradually.
> >>>> It should work, shouldn't it? I'd greatly appreciate your
> comment
> >> on
> >>>> it as I guess I don't see the whole picture and keep thinking
> the
> >>>> branch might help when others have already seen it would fall
> >> short.
> >>>>
> >>> Can we avoid the concerns that have been aired regarding svn
> >>> merging issues when directories are reorganised by leaving the
> >>> reorganization of directories as a last phase of the m2
> migration?
> >>>
> >>> I would have thought that we could move further along with the
> >>> migration without reorganizing directories (AFAIK, maven should
> be
> >>
> >>> able to work with existing directory structures, although doing
> so
> >>
> >>> may incur more work). We would also need to coordinate the
> >>> reorganization of directories with the owners of other branches
> >>> from trunk, to minimize the impact on them.
> >>
> >> I would prefer to wait to reorganize the directories until after
> the
> >>
> >> work in the dead-1.2 branch is merged with trunk. I plan to go
> back
> >>
> >> to this activity now. Other committers may wish to note that
> merging
> >>
> >> the work in dead-1.2 should not need RTC as it is already part of
> a
> >> main development line.
> >>
> >> thanks
> >> david jencks
> >>
> >>>
> >>> John
> >>>>> --jason
> >>>>
> >>>> Jacek
> >>>>
> >>>
> >>
> >>
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
