FYI, with the latest patch, you can just:
./build
But, this also needs openejb2 to be built with m2 first.
You can also create an uber-clean build with:
./bootstrap
* * *
I'm happy to tidy some of this stuff up post commit, but right now I
am not going to make any more cosmetic or friendliness changes until
this has been vote in.
--jason
On Jul 6, 2006, at 4:32 AM, anita kulshreshtha wrote:
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
