subject:"\[jira\] Updated\: \(GERONIMO\-2161\) \[RTC\] Remove Geronimo modules from dependencyManagement in root pom.xml"

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:
> > 
> > >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 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

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

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

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

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml



--- 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

[jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-05 Thread Jason Dillon (JIRA)

 [ 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 logging output for packaging plugin

> [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
> ---
>
>  Key: GERONIMO-2161
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2161
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: buildsystem
> Reporter: Jason Dillon
> Assignee: Jason Dillon
>  Fix For: 1.2
>  Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch, 
> GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch, GERONIMO-2161-v4.patch, 
> GERONIMO-2161-v5.patch
>
> As I have mentioned before, I believe we should remove the Geronimo modules 
> that are currently listed in the root pom.xml:
> This reduces the configuration of the pom by *~500 lines*.
> Modules that reference these as dependencies will need their pom's adjusted 
> to include ${pom.version} and car for the 
> configs.  But in many places version already exists with the 
> ${geronimoVersion} property... which kinda negates the purpose of the 
> dependencyManagement section anyways.
> I believe that it is more work to keep track of every module in the root pom 
> than it is to specify the additonal elements (mostly just 
> ${pom.version}) in child poms.  There is no additional 
> maintenance, as the new elements never need to be changed.
> Net effect if this change is less configuration to maintain and thus a less 
> brittle build that can adapt to change easier.
> Specifically these should be removed:
> {code:xml}
> 
> org.apache.geronimo.modules
> ge-activemq-rar
> ${geronimoVersion}
> rar
> 
> 
> org.apache.geronimo.modules
> geronimo-activation
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-client
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-client-builder
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-common
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-connector
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-connector-builder
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-converter
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-core
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-deploy-config
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-deploy-jsr88
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-deploy-tool
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-deployment
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-derby
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-directory
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-javamail-transport
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-j2ee
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-j2ee-builder
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-j2ee-schema
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-kernel
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-jetty
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-jetty-builder
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-jmx-remoting
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-mail
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-management
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-naming
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-naming-builder
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-security
> ${geronimoVersion}
> 
>

Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)

2006-07-05 Thread Paul McMahan

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 knows what the right hand is doing" then we may
benefit from relaxing the definition of trivial to mean those changes
which don't affect the core flow of the reviewed code.  e.g. changes
which improve readability, address minor oversights, or address edge
cases would fall into this category.

Actually, now that I think about it I wonder if allowing these types
of changes to go in without restarting the review might actually
improve quality because the contributor would otherwise be hesitant to
make them.  For example, if 3 PMC members review the code and two
provide a +1 but a third suggests some "trivial" changes then the
contributor is less likely to make them if it means restarting the
review.

Paul

On 7/4/06, John Sisson <[EMAIL PROTECTED]> wrote:

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 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 fixing
indentation and adding comments.

Trivial changes do not include code changes or changes that affect the
operation of the build.

To make it easier for reviewers when a new version of a patch is
generated, it would be worthwhile adding a comment on what has changed
since the previous patch.

Do the above patch vote negation guidelines sound reasonable to everyone?

Thanks,

John

Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)


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 fixing
indentation and adding comments.

Trivial changes do not include code changes or changes that affect the
operation of the build.

To make it easier for reviewers when a new version of a patch is
generated, it would be worthwhile adding a comment on what has changed
since the previous patch.

Do the above patch vote negation guidelines sound reasonable to everyone?


+1


John


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)


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 reapply/revalidate for
every revision for the RTC to complete is going to be effective.

I am making significant progress on the m2 build and I really would
rather not wait for (days, weeks) for one patch to get approved
before continuing to work on the next steps.  I can also not really
split up these into incremental patches.

I might have a different opinion of this entire situation if there
were more PMC members that were actually looking at these patches...
say one a day.  If I pump out an average of 1/2+ a patch a day, then...

After 2 days, 2 PMC would have reviewed (and lets just say were +1),
but I have gotten further and have a new version of the patch now, so
now they need to do it again... and probably won't until tomorrow.

After 3 days, the 3rd PMC got to the v2 patch and +1

After 4 days, another PMC + 1, but another version is out... so
scratch the votes and start over.

The only chance in this example is for 1-2 PMC members to review
apply each day.  If 1 on the first, then must be 2 on the second or
visa-versa.  Given the current PMC member activity, I don't believe
it will ever be possible (following this example) to every get
anything approved.


How do you think our non-committers work? I think it's time to think
about it and come up with a solution that would help them and us. Do
you think it is the reason why there's so few contributions? I don't
really have any idea how to improve it, really.

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-05 Thread Jason Dillon


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

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-05 Thread anita kulshreshtha

   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

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-05 Thread David Jencks



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

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-05 Thread John Sisson


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.


John

--jason


Jacek

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml


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 stepped in, we've got our own vision of how
it might work. It turned out we missed the point and tried to convert
m1 project into m2 one without careful thinking about how much time it
would eventually take. I think noone knew how it would turn out as we
all learned M2. It's turned out that we should be more radical and
refactor our directory structure or problems are just behind the
corner. You made it clear to us. Before then, I think I wouldn't have
agreed with anyone calling m2 experimental, either, but don't take it
so literally. I'll appreciate your work and that I can learn so much
from what you're doing, but is it bad to call it experimental until
it's done? If it is, please accept my appologizes and I'll never say
it wrt your work wrt m2 migration.


But... lets see what others have to say.


Definitelly!


Though... even with a branch, we would have to RTC to merge back to
trunk, which may take several weeks... which is not acceptable IMO.


Nope. We can go on with the work in the branch while keeping truck of
where we're at with applying them to trunk. It's us who care to commit
the work to trunk so wouldn't you mind if you worked so hard and your
changes wouldn't be committed? I would. So, although it's much more
work to do, doing it incrementally with help of JIRA is doable. The
benefit is to encourage others to step up and join. It might be that
some mailboxes will grow too fast, and their owners won't be able to
resist to help us with the migration or their mailboxes blow up ;-)


--jason


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml


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.


--jason


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)

2006-07-04 Thread Matt Hogstrom

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
increase the bureaucracy unless there is concern that the current process is being abused.

Jason Dillon wrote:

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 fixing
indentation and adding comments.
Trivial changes do not include code changes or changes that affect the
operation of the build.

In general I agree with you... but I'm not sure that this should apply
to what is going on for m2 work (or other similar types of work).

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 reapply/revalidate for every revision for
the RTC to complete is going to be effective.

I am making significant progress on the m2 build and I really would
rather not wait for (days, weeks) for one patch to get approved before
continuing to work on the next steps. I can also not really split up
these into incremental patches.

I might have a different opinion of this entire situation if there were
more PMC members that were actually looking at these patches... say one
a day. If I pump out an average of 1/2+ a patch a day, then...

After 2 days, 2 PMC would have reviewed (and lets just say were +1), but
I have gotten further and have a new version of the patch now, so now
they need to do it again... and probably won't until tomorrow.

After 3 days, the 3rd PMC got to the v2 patch and +1

After 4 days, another PMC + 1, but another version is out... so scratch
the votes and start over.

The only chance in this example is for 1-2 PMC members to review apply
each day. If 1 on the first, then must be 2 on the second or
visa-versa. Given the current PMC member activity, I don't believe it
will ever be possible (following this example) to every get anything
approved.

* * *

How on earth is this going to work? In this example I was being
optimistic about one +1 per day by a PMC member, but based on the
current status of GERONIMO-2161 it looks more like one +1 every 2 or 3
days.

The alternative is to slow down... make less changes, waiting the time
for PMC members to vote on a single revision. So, one +1 every 2 or 3
days turns into 6 to 9 days of idle time waiting for PMC members to
review/vote. And since I have made 2 (almost 3 from todays work)
significant additions to the patch, that means about 18 to 27 days to
get the *additional* changes I have made in the past few days voted in
to be committed.

The end result is a month+ has gone by, very little progress was
actually committed to the codebase to migrate to Maven 2. At that rate,
maybe by this time next year we will have something ready. Or, lets say
that the numbers are off... by 50% or so... well then it will only take
more months to implement the transition to m2.

So if it takes 6mo to a year to transition to a new build system... how
long is it going to take to actually build features that are users
want?! I'm not including any of the time spent so far with the m2
conversion... but from what I gather its already been in progress for
several months. This is work that should be easily completed in a week
or so, given that there are people actively working on it.

* * *

Maybe I have been smoking too much crack or popped one to many crazy
pills, but this really seems like a whacked-out impossible situation...

--jason

Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)


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 fixing  
indentation and adding comments.
Trivial changes do not include code changes or changes that affect  
the operation of the build.


In general I agree with you... but I'm not sure that this should  
apply to what is going on for m2 work (or other similar types of work).


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 reapply/revalidate for  
every revision for the RTC to complete is going to be effective.


I am making significant progress on the m2 build and I really would  
rather not wait for (days, weeks) for one patch to get approved  
before continuing to work on the next steps.  I can also not really  
split up these into incremental patches.


I might have a different opinion of this entire situation if there  
were more PMC members that were actually looking at these patches...  
say one a day.  If I pump out an average of 1/2+ a patch a day, then...


After 2 days, 2 PMC would have reviewed (and lets just say were +1),  
but I have gotten further and have a new version of the patch now, so  
now they need to do it again... and probably won't until tomorrow.


After 3 days, the 3rd PMC got to the v2 patch and +1

After 4 days, another PMC + 1, but another version is out... so  
scratch the votes and start over.


The only chance in this example is for 1-2 PMC members to review  
apply each day.  If 1 on the first, then must be 2 on the second or  
visa-versa.  Given the current PMC member activity, I don't believe  
it will ever be possible (following this example) to every get  
anything approved.


 * * *

How on earth is this going to work?  In this example I was being  
optimistic about one +1 per day by a PMC member, but based on the  
current status of GERONIMO-2161 it looks more like one +1 every 2 or  
3 days.


The alternative is to slow down... make less changes, waiting the  
time for PMC members to vote on a single revision.  So, one +1 every  
2 or 3 days turns into 6 to 9 days of idle time waiting for PMC  
members to review/vote.  And since I have made 2 (almost 3 from  
todays work) significant additions to the patch, that means about 18  
to 27 days to get the *additional* changes I have made in the past  
few days voted in to be committed.


The end result is a month+ has gone by, very little progress was  
actually committed to the codebase to migrate to Maven 2.  At that  
rate, maybe by this time next year we will have something ready.  Or,  
lets say that the numbers are off... by 50% or so... well then it  
will only take more months to implement the transition to m2.


So if it takes 6mo to a year to transition to a new build system...  
how long is it going to take to actually build features that are  
users want?!  I'm not including any of the time spent so far with the  
m2 conversion... but from what I gather its already been in progress  
for several months.  This is work that should be easily completed in  
a week or so, given that there are people actively working on it.


 * * *

Maybe I have been smoking too much crack or popped one to many crazy  
pills, but this really seems like a whacked-out impossible situation...


--jason

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml


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
issues you encountered and how they can be avoided.  The following  
mail

might be a good seed for the initial content of the page:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200603.mbox/% 
[EMAIL PROTECTED]


+1



It has highlighted some issues, so it hasn't been a complete waste of
time.  I think it would be worthwhile gaining a better  
understanding of

the diff/patch issue as patches aren't only used during RTC.


Agreed... though I don't even know where to dig anymore.  I spent  
several hours looking into this and I'm still mystified.


--jason

[DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)

2006-07-03 Thread John Sisson


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 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 fixing 
indentation and adding comments. 

Trivial changes do not include code changes or changes that affect the 
operation of the build.


To make it easier for reviewers when a new version of a patch is 
generated, it would be worthwhile adding a comment on what has changed 
since the previous patch.


Do the above patch vote negation guidelines sound reasonable to everyone?

Thanks,

John

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-03 Thread John Sisson


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.

Have you narrowed down what the diff/patch problems were caused by so we
can avoid it in the future?  It might be worthwhile to add a "Creating
and Applying Patches Best Practices" wiki page that discusses the
issues you encountered and how they can be avoided.  The following mail
might be a good seed for the initial content of the page:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200603.mbox/[EMAIL 
PROTECTED]

In regards to whether a vote needs to be restarted, I have started a new
thread "[PROPOSAL] Patch vote restart guidelines (was Re: [jira]
Updated: (GERONIMO-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 other folks 
have put in... but I'm guessing that collectively we have *wasted* 
many hours on this one single minor change RTC.

It has highlighted some issues, so it hasn't been a complete waste of
time.  I think it would be worthwhile gaining a better understanding of
the diff/patch issue as patches aren't only used during RTC.



Folks, development like this will not scale... it does not scale!
I'm trying to play along... but really if it is going to take this 
much effort for relatively minor changes that are aimed at helping to 
fix issues we have and move forward with projects that have been 
lagging for months (the m2 migration in this case) then I'm not sure 
how we will ever get anything done.


I don't think we will attract many new committers into this type of 
environment.  Its already resulted in several folks who had been 
active before switching focus to other tasks/projects.  I hope they 
come back at some point, but I can see why they might want to apply 
their time in more rewarding ways.

Hopefully those people will speak up for themselves.

John


--jason



On Jul 3, 2006, at 2:01 AM, Jason Dillon (JIRA) wrote:


 [ 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 nothing with the -s 
flag) on a fresh checkout of trunk with:


{noformat}
patch -p0 -s < GERONIMO-2161-v3.patch
{noformat}

The packaging changes are not directly related to the changes that 
this issue is tracking, its additional clean up work... as well as 
build debugging bits to add better logging.


I believe that the icky script foo above should produce the same 
results (sans the logging output) as the v2 patch.


*NOTE:* I do not believe that it is needed to reapply v3 if you 
already believe that v2 is acceptable.



[RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
---

 Key: GERONIMO-2161
 URL: http://issues.apache.org/jira/browse/GERONIMO-2161
 Project: Geronimo
Type: Task
Security: public(Regular issues)
  Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
 Fix For: 1.2
 Attachments: GERONIMO-2161-configs-v1.1.sub.patch, 
GERONIMO-2161-v1.patch, GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch


As I have mentioned before, I believe we should remove the Geronimo 
modules that are currently listed in the root pom.xml:

This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's 
adjusted to include ${pom.version} and 
car for the configs.  But in many places version 
already exists with the ${geronimoVersion} property... which kinda 
negates the purpose of the dependencyManagement section anyways.
I believe that it is more work to keep track of every module in the 
root pom than it is to specify the additonal elements (mostly just 
${pom.version}) in child poms.  There is no 
additional maintenance, as the new elements never need to be changed.
Net effect if this change is less configuration to maintain and thus 
a less brittle build that can adapt to change easier.

Specifically these should be removed:
{code:xml}

org.apache.geronimo.modules
ge-activemq-rar
${geronimoVersion}
rar


org.apache.geronimo.modules
geronimo-activation
${geronimoVersion}


org.apache.geronimo.modules
geronimo-client
${geronimoVersion}


org.apache.g

[jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-03 Thread Jason Dillon (JIRA)

 [ 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 harmlessly fail on patching because the 
universe hates me.

This patch:

 * Updates the xmlbeans plugin to 2.0.1-SNAPSHOT which removes the need to 
rebuild so many times.
 * Consolidates the bulk of xmlbeans config into the root pom's 
dependencyManagement.  Same goes for JSPC and WAR.
 * Using ${pom.groupId} for module dependencies
 * Some pom's reordered for consistency
 * Adds a few more dependencies to dependencyManagement to free modules from 
needing to specify version (still a bunch more work to clean this up)
 * Normalized some more pom headers... yada yada

Latest script to make a clean build:

{noformat}
#!/bin/sh

rm -rf ~/.m2/repository

find . -name target -type d -exec rm -rf \{\} \;

mvn -Dstage=bootstrap -Dmaven.test.skip=true

( cd openejb2/modules; mvn clean; mvn -Dmaven.test.skip=true install )

mvn -Dstage=assemble -Dmaven.test.skip=true
{noformat}

This depends on the latest pom's from openejb2 so be sure to update first.

As soon as openejb2's m2 build is published, then the build should function 
with just:

{noformat}
./build -Dmaven.test.skip=true
{noformat}

Still a bunch more clean up that needs to be done...

> [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
> ---
>
>  Key: GERONIMO-2161
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2161
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: buildsystem
> Reporter: Jason Dillon
> Assignee: Jason Dillon
>  Fix For: 1.2
>  Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch, 
> GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch, GERONIMO-2161-v4.patch
>
> As I have mentioned before, I believe we should remove the Geronimo modules 
> that are currently listed in the root pom.xml:
> This reduces the configuration of the pom by *~500 lines*.
> Modules that reference these as dependencies will need their pom's adjusted 
> to include ${pom.version} and car for the 
> configs.  But in many places version already exists with the 
> ${geronimoVersion} property... which kinda negates the purpose of the 
> dependencyManagement section anyways.
> I believe that it is more work to keep track of every module in the root pom 
> than it is to specify the additonal elements (mostly just 
> ${pom.version}) in child poms.  There is no additional 
> maintenance, as the new elements never need to be changed.
> Net effect if this change is less configuration to maintain and thus a less 
> brittle build that can adapt to change easier.
> Specifically these should be removed:
> {code:xml}
> 
> org.apache.geronimo.modules
> ge-activemq-rar
> ${geronimoVersion}
> rar
> 
> 
> org.apache.geronimo.modules
> geronimo-activation
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-client
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-client-builder
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-common
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-connector
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-connector-builder
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-converter
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-core
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-deploy-config
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-deploy-jsr88
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-deploy-tool
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-deployment
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-derby
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-directory
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-javamail-transport
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-j2ee
> ${geronimoVersion}
> 
> 
> org.apache.geronimo.modules
> geronimo-j2ee-builder
> ${geronimoVersion}
> 
> 
>

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml


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 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).


But... lets see what others have to say.

I may create an experimental branch to see how well SVN actually  
handles merges and remerges of an entire (massive) branch.  And if  
that ends up being relatively feasible then I would consider creating  
a branch for the remaining m2 work.


Though... even with a branch, we would have to RTC to merge back to  
trunk, which may take several weeks... which is not acceptable IMO.


--jason

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

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 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.


:-(

--jason


On Jul 3, 2006, at 11:31 AM, 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 our m2 efforts when it works for one and
does not for others and we can't figure out why. As many stated, it's
unacceptable to happen in trunk, which would've had if it'd done in a
conventional manner - CTR. Call it whatever you like - experiments are
what suited best for me, esp. while we're experimenting with m2 build
until we get to the point when it's ready to be applied to the trunk.
Rather than wasting Jason's time and encouraging him to follow RTC
rules, which add nothing but frustration and disgust, we could use a
solution that was indeed mentioned many times - a branch. It's like a
sandbox where we can do everything - experimenting - until we find the
one working solution ready for RTC.

(somehow I feel you read it otherwise, but again it might be that my
English's not working well)


Alan


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-03 Thread Alan D. Cabrera


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 our m2 efforts when it works for one and
does not for others and we can't figure out why. As many stated, it's
unacceptable to happen in trunk, which would've had if it'd done in a
conventional manner - CTR. Call it whatever you like - experiments are
what suited best for me, esp. while we're experimenting with m2 build
until we get to the point when it's ready to be applied to the trunk.
Rather than wasting Jason's time and encouraging him to follow RTC
rules, which add nothing but frustration and disgust, we could use a
solution that was indeed mentioned many times - a branch. It's like a
sandbox where we can do everything - experimenting - until we find the
one working solution ready for RTC.

(somehow I feel you read it otherwise, but again it might be that my
English's not working well)


Cool.  I'll reply to your new post.


Regards,
Alan

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-03 Thread Jacek Laskowski


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 works for one and
does not for others and we can't figure out why. As many stated, it's
unacceptable to happen in trunk, which would've had if it'd done in a
conventional manner - CTR. Call it whatever you like - experiments are
what suited best for me, esp. while we're experimenting with m2 build
until we get to the point when it's ready to be applied to the trunk.
Rather than wasting Jason's time and encouraging him to follow RTC
rules, which add nothing but frustration and disgust, we could use a
solution that was indeed mentioned many times - a branch. It's like a
sandbox where we can do everything - experimenting - until we find the
one working solution ready for RTC.

(somehow I feel you read it otherwise, but again it might be that my
English's not working well)


Alan


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-03 Thread Alan D. Cabrera


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 of the patch negate anything else voted upon.


You're completely right - it doesn't read good. Do you think doing
such experiments on trunk would break it *at least* once? I guess so.
Do you think it matters? Yes.

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! ;-)

If I knew how to create a branch, I'd go for it. m2build would be the
name for it.

Jacek


Jacek,

I'm not following your line of thought when you mention experiments.  
Can you provide more detail?



Regards,
Alan

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-03 Thread Jacek Laskowski


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 anything else voted upon.


You're completely right - it doesn't read good. Do you think doing
such experiments on trunk would break it *at least* once? I guess so.
Do you think it matters? Yes.

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! ;-)

If I knew how to create a branch, I'd go for it. m2build would be the
name for it.

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml