You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Alan D. Cabrera" <li...@toolazydogs.com> on 2006/07/04 00:54:52 UTC
Geronimo specs pre-RTC
We had talked about breaking out the Geronimo specs so that they don't
share the same root pom. There seemed to be a consensus that this was
a good idea. John Sisson mentioned that we might need separate Jiras
for each. I think that that might be excessive given how the specs jars
are unlikely to change.
The nature of this change is that it will not be possible to make a
patch to reflect the changes that need to be done. What I can do is to
concretely express the changes that need to be made in an RTC. Thoughts?
Regards,
Alan
Re: Geronimo specs pre-RTC
Posted by Jason Dillon <ja...@planet57.com>.
On Jul 5, 2006, at 11:30 AM, Alan D. Cabrera wrote:
>> There is a bunch of shared config... like maven-one-plugin, ci,
>> jira, deployment (ssh), plugin repositories, distro mgmgnt. About
>> 80 lines from the current pom.xml for specs is going to be the
>> same across all specs modules. Which minus spaces is about 1/3 of
>> the pom.xml. Its about 1/2 of the pom when the bulk
>> dependencyManagement is removed (since it won't be needed to
>> resolve all specs in every module).
>
> Ok, so if we update a spec, say javamail, the version of this
> shared config stays the same? If that's the case, then I'm warming
> up to it.
Yup. The version of the shared config pom is independent from the
javamail spec (or any other spec). The version of the shared config
pom only changes when we need to change that shared config, which
will not be very often.
--jason
Re: Geronimo specs pre-RTC
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Jason Dillon wrote:
> On Jul 3, 2006, at 4:54 PM, Alan D. Cabrera wrote:
>>> I think it is still a good idea to have them all extend from a
>>> parent pom... there is still stuff that would be good to centralize,
>>> but the parent and the child do not need to exists within the same
>>> tree and do not need to share the same version.
>> I see no reason for there to be a parent POM. What stuff needs to be
>> centralized? Can you explain what the phrase "the parent and the
>> child do not need to exists within the same tree and do not need to
>> share the same version" means?
>
> There is a bunch of shared config... like maven-one-plugin, ci, jira,
> deployment (ssh), plugin repositories, distro mgmgnt. About 80 lines
> from the current pom.xml for specs is going to be the same across all
> specs modules. Which minus spaces is about 1/3 of the pom.xml. Its
> about 1/2 of the pom when the bulk dependencyManagement is removed
> (since it won't be needed to resolve all specs in every module).
Ok, so if we update a spec, say javamail, the version of this shared
config stays the same? If that's the case, then I'm warming up to it.
Regards,
Alan
Re: Geronimo specs pre-RTC
Posted by Jason Dillon <ja...@planet57.com>.
On Jul 3, 2006, at 4:54 PM, Alan D. Cabrera wrote:
>> I think it is still a good idea to have them all extend from a
>> parent pom... there is still stuff that would be good to
>> centralize, but the parent and the child do not need to exists
>> within the same tree and do not need to share the same version.
> I see no reason for there to be a parent POM. What stuff needs to
> be centralized? Can you explain what the phrase "the parent and
> the child do not need to exists within the same tree and do not
> need to share the same version" means?
There is a bunch of shared config... like maven-one-plugin, ci, jira,
deployment (ssh), plugin repositories, distro mgmgnt. About 80 lines
from the current pom.xml for specs is going to be the same across all
specs modules. Which minus spaces is about 1/3 of the pom.xml. Its
about 1/2 of the pom when the bulk dependencyManagement is removed
(since it won't be needed to resolve all specs in every module).
>> I recommend creating a top-level spec-config/trunk/pom.xml that
>> has all of the common pom configuration... then release it a 1.0,
>> and have each of the spec pom's extend from that. Spec config
>> will almost never change (unless we have to change project urls or
>> repos)... but when we do, its easier to manage in a central place.
> The whole point of this change is to get *rid* of the root POM.
I thought the point was to allow the life-cycle and version of specs
to be independent from each other.
>> I think we eventually need a general project-config module that we
>> can share with all sub-projects. That module would be part of a
>> build-support project where our independent custom modules and
>> build configuration lives.
> Why?
Because it is easier to manage shared configuration in this manner.
--jason
Re: Geronimo specs pre-RTC
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Jason Dillon wrote:
> I think it is more work than it is worth to try and create patches and
> have separate issues for this.
Patches don't work for moving dirs, IIUC.
>
> * * *
>
> This will generally move individual modules from
> http://svn.apache.org/repos/asf/geronimo/specs/trunk/XXX to
> http://svn.apache.org/repos/asf/geronimo/specs/XXX/trunk and then
> clean up the pom's right?
Yep.
>
> I think it is still a good idea to have them all extend from a parent
> pom... there is still stuff that would be good to centralize, but the
> parent and the child do not need to exists within the same tree and do
> not need to share the same version.
I see no reason for there to be a parent POM. What stuff needs to be
centralized? Can you explain what the phrase "the parent and the child
do not need to exists within the same tree and do not need to share the
same version" means?
> I recommend creating a top-level spec-config/trunk/pom.xml that has
> all of the common pom configuration... then release it a 1.0, and have
> each of the spec pom's extend from that. Spec config will almost
> never change (unless we have to change project urls or repos)... but
> when we do, its easier to manage in a central place.
The whole point of this change is to get *rid* of the root POM.
> I think we eventually need a general project-config module that we can
> share with all sub-projects. That module would be part of a
> build-support project where our independent custom modules and build
> configuration lives.
Why?
Regards,
Alan
>
> --jason
>
>
> On Jul 3, 2006, at 3:54 PM, Alan D. Cabrera wrote:
>
>> We had talked about breaking out the Geronimo specs so that they
>> don't share the same root pom. There seemed to be a consensus that
>> this was a good idea. John Sisson mentioned that we might need
>> separate Jiras for each. I think that that might be excessive given
>> how the specs jars are unlikely to change.
>>
>> The nature of this change is that it will not be possible to make a
>> patch to reflect the changes that need to be done. What I can do is
>> to concretely express the changes that need to be made in an RTC.
>> Thoughts?
>>
>>
>> Regards,
>> Alan
>>
>>
>
Re: Geronimo specs pre-RTC
Posted by Jason Dillon <ja...@planet57.com>.
I think it is more work than it is worth to try and create patches
and have separate issues for this.
* * *
This will generally move individual modules from http://
svn.apache.org/repos/asf/geronimo/specs/trunk/XXX to http://
svn.apache.org/repos/asf/geronimo/specs/XXX/trunk and then clean up
the pom's right?
I think it is still a good idea to have them all extend from a parent
pom... there is still stuff that would be good to centralize, but the
parent and the child do not need to exists within the same tree and
do not need to share the same version.
I recommend creating a top-level spec-config/trunk/pom.xml that has
all of the common pom configuration... then release it a 1.0, and
have each of the spec pom's extend from that. Spec config will
almost never change (unless we have to change project urls or
repos)... but when we do, its easier to manage in a central place.
I think we eventually need a general project-config module that we
can share with all sub-projects. That module would be part of a
build-support project where our independent custom modules and build
configuration lives.
--jason
On Jul 3, 2006, at 3:54 PM, Alan D. Cabrera wrote:
> We had talked about breaking out the Geronimo specs so that they
> don't share the same root pom. There seemed to be a consensus
> that this was a good idea. John Sisson mentioned that we might
> need separate Jiras for each. I think that that might be excessive
> given how the specs jars are unlikely to change.
>
> The nature of this change is that it will not be possible to make a
> patch to reflect the changes that need to be done. What I can do
> is to concretely express the changes that need to be made in an
> RTC. Thoughts?
>
>
> Regards,
> Alan
>
>
Re: Geronimo specs pre-RTC
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Jacek Laskowski wrote:
> On 7/6/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> I had an "ah ha" experience after my fourth beer, before my third
>> hamburger, yesterday. One word, branch.
>>
>> I'll cook something up in geronimo/specs/branch. I'll include Jason's
>> suggestions.
>
> Yeah, it happened to me as well, but it was way faster than after the
> proverbial fourth beer - I couldn't survive after the second not
> mentioning the following ones ;-)
>
> May I read it as you being a not-yet-but-soon proponent of using
> branches before a commit to trunk with RTC? That would be great to
> hear a friendly soul nearby. ;-)
I think that branches are great for RTC. I think that the case for m2
conversion is uniquely different.
Regards,
Alan
Re: Geronimo specs pre-RTC
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/6/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> I had an "ah ha" experience after my fourth beer, before my third
> hamburger, yesterday. One word, branch.
>
> I'll cook something up in geronimo/specs/branch. I'll include Jason's
> suggestions.
Yeah, it happened to me as well, but it was way faster than after the
proverbial fourth beer - I couldn't survive after the second not
mentioning the following ones ;-)
May I read it as you being a not-yet-but-soon proponent of using
branches before a commit to trunk with RTC? That would be great to
hear a friendly soul nearby. ;-)
> Alan
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: Geronimo specs pre-RTC
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
I had an "ah ha" experience after my fourth beer, before my third
hamburger, yesterday. One word, branch.
I'll cook something up in geronimo/specs/branch. I'll include Jason's
suggestions.
Regards.
Alan
Matt Hogstrom wrote:
> Alan,
>
> This was the situation I described in an earlier e-mail about not
> providing a patch for an RTC. I think generally describing the
> activities and getting the votes should be adequate.
>
> Alan D. Cabrera wrote:
>> We had talked about breaking out the Geronimo specs so that they
>> don't share the same root pom. There seemed to be a consensus that
>> this was a good idea. John Sisson mentioned that we might need
>> separate Jiras for each. I think that that might be excessive given
>> how the specs jars are unlikely to change.
>>
>> The nature of this change is that it will not be possible to make a
>> patch to reflect the changes that need to be done. What I can do is
>> to concretely express the changes that need to be made in an RTC.
>> Thoughts?
>>
>>
>> Regards,
>> Alan
>>
>>
>>
>>
>>
Re: Geronimo specs pre-RTC
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Alan,
This was the situation I described in an earlier e-mail about not providing a patch for an RTC. I
think generally describing the activities and getting the votes should be adequate.
Alan D. Cabrera wrote:
> We had talked about breaking out the Geronimo specs so that they don't
> share the same root pom. There seemed to be a consensus that this was
> a good idea. John Sisson mentioned that we might need separate Jiras
> for each. I think that that might be excessive given how the specs jars
> are unlikely to change.
>
> The nature of this change is that it will not be possible to make a
> patch to reflect the changes that need to be done. What I can do is to
> concretely express the changes that need to be made in an RTC. Thoughts?
>
>
> Regards,
> Alan
>
>
>
>
>