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
Please ignore this.. (hit send accidentally)
Anita
--- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
>
>
> --- Jason Dillon <[EMAIL PROTECTED]> wrote:
>
> > What "user friendliness" are you talking about?
> >
> > --jason
> >
> >
> > On Jul 5, 2006, at 2:25 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 buil
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 buil
--- 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
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
Jason Dillon updated GERONIMO-2161:
---
Attachment: GERONIMO-2161-v5.patch
v5 _trivial_ update, includes:
* Reduces duplicate configuration for config modules
* Improves error handling and
John, if the ultimate goal of RTC is to ensure quality then I think
the restart guidelines sound reasonable since they guarantee that the
exact code being committed has been inspected multiple times and by
independent sources. But if the goal of RTC is really just to ensure
that "the left hand k
On 7/4/06, John Sisson <[EMAIL PROTECTED]> wrote:
IMO, a vote for a patch would be need to be restarted if the changes
between the previous patch and the newer version of the patch are not
trivial. Trival meaning:
* documentation changes
* non-controversial non-semantic style changes such as f
On 7/4/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
If we tried to follow this, then almost everyday the latest patch
needs to be reapplied and re-approved by everyone. Its been hard
enough to get people to apply any version of the patch. I do not
think, for this work, that requiring folks to r
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
--- Dav
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 w
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
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 w
On 7/3/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
I don't really consider this work experimental... gshell is
experimental, but the m2 work that I am doing is just the application
of experience with this system and other build systems for the past
years (and years).
Here's my take: before you
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.
Sinc
I think in general you are correct John. Although, from what I've seen the people that are
reviewing the patches are working with the submitter and then when they're happy give they're +1. I
believe the spirit of RTC is being met through the current process. Personally I'd prefer to not
incre
On Jul 3, 2006, at 10:27 PM, John Sisson wrote:
IMO, a vote for a patch would be need to be restarted if the
changes between the previous patch and the newer version of the
patch are not trivial. Trival meaning:
* documentation changes
* non-controversial non-semantic style changes such as
On Jul 3, 2006, at 10:26 PM, John Sisson wrote:
Have you narrowed down what the diff/patch problems were caused by
so we
can avoid it in the future?
Negative... still a mystery.
It might be worthwhile to add a "Creating and Applying Patches Best
Practices" wiki page that discusses the
iss
Jason Dillon wrote:
So far 2+ days, several patches... one PMC +1, one non-PMC +1 (with
caveat to ping JVZ)... now crazy problems with diff/patch.. which I'm
not exactly sure how that affects the current votes... or does adding
a new version of the patch negate anything else voted upon.
IMO, a
O-2161) [RTC] Remove Geronimo modules from
dependencyManagement in root pom.xml)".
All for work that took about an hour. I've spent much more time
trying to get folks to look at it and then hack up scripts to make the
build work most of the time. I don't know how much time
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
Jason Dillon updated GERONIMO-2161:
---
Attachment: GERONIMO-2161-v4.patch
Adding GERONIMO-2161-v4; This patch supersedes all other patches. Includes
packaging plugin changes which will har
I think there's a solution to RTC and having a place for experiments
like this where nothing's known ahead - a branch. With a branch you
can do whatever you want and no RTC rules apply there. I think it
would help us all. Interested? Count me in! ;-)
I don't really consider this work experimenta
NOTE... the m2 build in trunk is already broken... this patches help
FIX MANY OF THOSE PROBLEMS!
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 a
Jacek Laskowski wrote:
On 7/3/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
I'm not following your line of thought when you mention experiments.
Can you provide more detail?
(It turns out that I'm a victim of my own English, and I can't express
my mind clearly.)
What I meant was to refer to
On 7/3/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
I'm not following your line of thought when you mention experiments.
Can you provide more detail?
(It turns out that I'm a victim of my own English, and I can't express
my mind clearly.)
What I meant was to refer to our m2 efforts when it
Jacek Laskowski wrote:
On 7/3/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
So far 2+ days, several patches... one PMC +1, one non-PMC +1 (with
caveat to ping JVZ)... now crazy problems with diff/patch.. which I'm
not exactly sure how that affects the current votes... or does adding
a new version
On 7/3/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
So far 2+ days, several patches... one PMC +1, one non-PMC +1 (with
caveat to ping JVZ)... now crazy problems with diff/patch.. which I'm
not exactly sure how that affects the current votes... or does adding
a new version of the patch negate anyt
So far 2+ days, several patches... one PMC +1, one non-PMC +1 (with
caveat to ping JVZ)... now crazy problems with diff/patch.. which I'm
not exactly sure how that affects the current votes... or does adding
a new version of the patch negate anything else voted upon.
All for work that took
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
Jason Dillon updated GERONIMO-2161:
---
Attachment: GERONIMO-2161-v3.patch
GERONIMO-2161-v3.patch is the same as v2 minus the changes to the packaging
plugin. This applied cleanly (spat out
FYI, I nuked the old comment in favor of the new one with better
formatting.
--jason
On Jul 2, 2006, at 5:12 PM, Jason Dillon (JIRA) wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
Jason Dillon updated GERONIMO-2161:
---
Comm
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
Jason Dillon updated GERONIMO-2161:
---
Comment: was deleted
> [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
> --
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
Jason Dillon updated GERONIMO-2161:
---
Attachment: GERONIMO-2161-v2.patch
Here is the latest patch... which includes several other fixes.
{noformat}
rm -rf ~/.m2/repository
{noformat}
Buil
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
David Jencks updated GERONIMO-2161:
---
Attachment: GERONIMO-2161-configs-v1.1.sub.patch
This is a patch on just configs (apply from root) that updates the openejb
groupId to org.openejb and
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
Jason Dillon updated GERONIMO-2161:
---
Attachment: GERONIMO-2161-v1.patch
GERONIMO-2161-v1 patch removed the mentioned bits from the root pom.xml and
adds the required bits to to child poms
34 matches
Mail list logo
