Re: What do we do with beanutils?
On 8 Nov 2004, at 23:58, Brett Porter wrote: I've been meaning to reply to this in kind. If a project splits itself into three, should gump really try and map projects depending on an older version to these? I know you are experimenting with the latest and greatest, but this might be the point where you start maintaining beanutils-1.6.x and beanutils-*-1.7.x in gump and projects can migrate on their own (gump could encourage those left on the old one to do so, but not require it to keep running). this was discussed at the time and the consensus was that the right thing for gump to do was to move everyone onto the new jar's. (unless i've missed something) gump's always aimed at bringing the latest and greatest code together. a primary reason why beanutils was split into a modular jar system was so that gump (and anyone else trying to use the latest versions) would not run into difficulties with the two incompatible series of commons collections releases. at the time, it seemed best to migrate all projects (rather than having rely on nagging messages) and i think that this decision has been proved right. i suppose that the bigger issue is who owns the gump descriptors: the individual projects or gump... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do we do with beanutils?
I've been meaning to reply to this in kind. If a project splits itself into three, should gump really try and map projects depending on an older version to these? I know you are experimenting with the latest and greatest, but this might be the point where you start maintaining beanutils-1.6.x and beanutils-*-1.7.x in gump and projects can migrate on their own (gump could encourage those left on the old one to do so, but not require it to keep running). - Brett On Mon, 8 Nov 2004 20:10:14 +, robert burrell donkin [EMAIL PROTECTED] wrote: (sorry for being a little late to the party) On 2 Nov 2004, at 20:18, Brett Porter wrote: - projects declare any aliases in their gump descriptor (and Maven allows that in the POM so it can generate the descriptor for them). So beanutils-core has an alias of beanutils I understand the part about projects declaring aliases (we may even need to do that on the artifact level IMHO). I don't understand why Maven needs to know about those at all - other than the Gump plugin, maybe. I'm thinking of the case where a project name changes, and the aliases are project metadata. I'm not talking about gump names changing - I'm talking about the artifactID changing over time (as was the case with beanutils). sadly, beanutils is not so simple. the artifact id had to be changed in any case to fit in with the new artifact naming conventions (or so it appeared at the time that the release was cut) but three artifact ids were always going to be needed: two new ones for the modular jar's with simple dependencies and the old one for the combined jar. the gump descriptors were tested then migrated to commons-beanutils-core (it seemed that no other projects used the classes moved into commons-beanutils-collections). however, the route of least resistance seems to be for gump to forget that the combined distribution exists and use a alias. in any case, projects should really be migrating to the new modular jar's (they have much simpler dependencies) when they upgrade their dependencies... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do we do with beanutils?
FWIW, part of Jelly uses commons-beanutils-collections. On Mon, 8 Nov 2004 20:10:14 +, robert burrell donkin [EMAIL PROTECTED] wrote: (sorry for being a little late to the party) On 2 Nov 2004, at 20:18, Brett Porter wrote: - projects declare any aliases in their gump descriptor (and Maven allows that in the POM so it can generate the descriptor for them). So beanutils-core has an alias of beanutils I understand the part about projects declaring aliases (we may even need to do that on the artifact level IMHO). I don't understand why Maven needs to know about those at all - other than the Gump plugin, maybe. I'm thinking of the case where a project name changes, and the aliases are project metadata. I'm not talking about gump names changing - I'm talking about the artifactID changing over time (as was the case with beanutils). sadly, beanutils is not so simple. the artifact id had to be changed in any case to fit in with the new artifact naming conventions (or so it appeared at the time that the release was cut) but three artifact ids were always going to be needed: two new ones for the modular jar's with simple dependencies and the old one for the combined jar. the gump descriptors were tested then migrated to commons-beanutils-core (it seemed that no other projects used the classes moved into commons-beanutils-collections). however, the route of least resistance seems to be for gump to forget that the combined distribution exists and use a alias. in any case, projects should really be migrating to the new modular jar's (they have much simpler dependencies) when they upgrade their dependencies... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What do we do with beanutils?
Brett, It seems like #2 is the cleanest way regardless of how the details of it are implemented. If the POM change is too much, we could just add the various alias names to project.properties. Or, alternatively, say tough luck, you changed your name, Maven can't generate the Gump descriptor. #3 seems like if we are to do that, then the gump plugin should really move to gump CVS so that gump people can maintain this plugin. Or, at least, dynamically pull in the mapping file from Gump's website/cvs. I'd argue that tracking that kind of thing is a useful beyond just Gump anyway and should be in the POM. I have a versions plugin that checks if you have the latest and greatest of an artifact. But, if the artifact changes names, there is no repo for that data. Eric -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 2:58 AM To: Gump code and data Subject: Re: What do we do with beanutils? Ok, we need a solution for when a project changes names. There have been suggestions in the past, let's round them up: - gump has a dummy project beanutils that depends just on beanutils-core. I don't think this works with Maven though. - projects declare any aliases in their gump descriptor (and Maven allows that in the POM so it can generate the descriptor for them). So beanutils-core has an alias of beanutils - we don't do any gump solutions, and we maintain the big mapping file in the maven gump plugin, so it can change the dependencies when converting the gump descriptor. We look to store that mapping file in gump, instead. - we don't do anything. When a project changes name, they accept they are going to break projects and they have to catch up. Possibly, the previous version keeps the name so that projects keep building? (others have more passionate feelings about how gump should behave in this way I think, so I'll leave that to them). Thoughts? (2) seems the best if possible on the gump end. Both (2) and (3) are easy from the maven end. Cheers, Brett On Mon, 01 Nov 2004 20:29:32 -0500, Stefano Mazzocchi [EMAIL PROTECTED] wrote: we call it beanutils-core and maven calls it beanutils. Should I go ahead and unify the two or anybody has a better idea? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do we do with beanutils?
It's been my understanding that right now the artifact id is more important than the project name. Is this wrong? On Tue, 2 Nov 2004, Brett Porter [EMAIL PROTECTED] wrote: - gump has a dummy project beanutils that depends just on beanutils-core. I don't think this works with Maven though. If it works for Maven, then let's just do that since it is the least intrusive. - projects declare any aliases in their gump descriptor (and Maven allows that in the POM so it can generate the descriptor for them). So beanutils-core has an alias of beanutils I understand the part about projects declaring aliases (we may even need to do that on the artifact level IMHO). I don't understand why Maven needs to know about those at all - other than the Gump plugin, maybe. I'm absolutely willing to maintain these aliases on an as-needed basis. - we don't do anything. When a project changes name, they accept they are going to break projects and they have to catch up. But have the projects chosen the name? I mean, is it the project's fault if the name we (Gump) assign to it and the one Maven uses for it are different? Has the project itself any say in either of both? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do we do with beanutils?
- projects declare any aliases in their gump descriptor (and Maven allows that in the POM so it can generate the descriptor for them). So beanutils-core has an alias of beanutils I understand the part about projects declaring aliases (we may even need to do that on the artifact level IMHO). I don't understand why Maven needs to know about those at all - other than the Gump plugin, maybe. I'm thinking of the case where a project name changes, and the aliases are project metadata. I'm not talking about gump names changing - I'm talking about the artifactID changing over time (as was the case with beanutils). I'm absolutely willing to maintain these aliases on an as-needed basis. That sounds like the 3rd solution, however it seems the 1st worked anyway :) - we don't do anything. When a project changes name, they accept they are going to break projects and they have to catch up. But have the projects chosen the name? I mean, is it the project's fault if the name we (Gump) assign to it and the one Maven uses for it are different? Has the project itself any say in either of both? Sorry for mixing up words, Iwas talking about artifactId that the project chooses. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What do we do with beanutils?
we call it beanutils-core and maven calls it beanutils. Should I go ahead and unify the two or anybody has a better idea? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: What do we do with beanutils?
Ok, we need a solution for when a project changes names. There have been suggestions in the past, let's round them up: - gump has a dummy project beanutils that depends just on beanutils-core. I don't think this works with Maven though. - projects declare any aliases in their gump descriptor (and Maven allows that in the POM so it can generate the descriptor for them). So beanutils-core has an alias of beanutils - we don't do any gump solutions, and we maintain the big mapping file in the maven gump plugin, so it can change the dependencies when converting the gump descriptor. We look to store that mapping file in gump, instead. - we don't do anything. When a project changes name, they accept they are going to break projects and they have to catch up. Possibly, the previous version keeps the name so that projects keep building? (others have more passionate feelings about how gump should behave in this way I think, so I'll leave that to them). Thoughts? (2) seems the best if possible on the gump end. Both (2) and (3) are easy from the maven end. Cheers, Brett On Mon, 01 Nov 2004 20:29:32 -0500, Stefano Mazzocchi [EMAIL PROTECTED] wrote: we call it beanutils-core and maven calls it beanutils. Should I go ahead and unify the two or anybody has a better idea? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
