|
|
|
|
Welcome
Guest
| Register
| Login
|
| Index | Recent Threads | Unanswered Threads | Who's Online | User List | Help |
DataNucleus Forum
Development of DataNucleus
General Development
Thread: Maven 2 - 1.2.0-beta-5
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 17
|
|
| Author |
|
jfrantzius
Advanced Member Germany Joined: Jun 18, 2004 Post Count: 405 Status: Offline |
My 2 cents on why a parent pom is useful: 1. new developers (bugfix contributors): the learning curve for initially building datanucleus is very steep if you first have to figure out which plugin-projects there are, what their dependencies are, and in what particular order they need to be built, and then go and build them manually one-by-one in the correct order. That's error-prone and frustrating. Since you Andy are working on datanucleus every day and with total commitment, it may be hard for you to imagine that, but it's an ugly fact for anybody else starting development on datanucleus. If somebody just wants to fix a little bug, chances are he'll give up before he was able to fix anything, since only building the project takes multitudes longer than actually fixing the bug (and you have to build initially before starting with the interesting work). Maven2 parent poms is a very common way of solving these problems, and most people will immediately understand them. Having any other scripts etc. for automation requires additional work to understand what's going on. Given the current SVN layout, those scripts would also face the same problems of how to deal with pluginX/branches/{version}/ vs. pluginX/trunk/ paths. That's of course only to consider if you'd like to see more developers contributing. 2. infrequent developers: if you didn't update and build for a while, it can take a long time until you get up to speed again due to the above reasons, speaking at least from my personal experience 3. Continuous integration: there needs to be a way of building without any manual intervention for continuous integration to work. 4. Reduced redundancy: the parent pom holds dependencies and build settings common to all child modules; a good example is switching the current JDO-API version to build against: with the parent pom, that requires a change only in a single file, as opposed to changing a multitude of files (for every plugin) without parent pom. The flexibility of being able to branch plugins individually to me seems more of a theoretical advantage, even more so as in practice building can become a nightmare, i.e. if you end up building an arbitrary combination of pluginX/branches/{version} paths. To my knowledge, there also hasn't been any need for branching an individual plugin so far? Having a single product to branch would make things very very much more manageable, at the cost of something I haven't yet seen being necessary in practice. |
||
|
|
andy
Expert UK / España Joined: Mar 13, 2004 Post Count: 4882 Status: Offline |
Yes I'm aware of the theoretical benefits of inheritance but, as I said, there are very few deps in common across plugins (you included jdo2.jar but that is *not* required by some plugins so you're imposing on some plugins an additional build restriction by doing that), and that the M2 inheritance model doesn't fit the plugin-product model we have. A script for "accessplatform 1.0", "accessplatform 1.1" would be perfectly capable of building all relevant plugins. Since a product is a collection of plugins at a particular version, then that is the logical way, since M2's inheritance mechanism cannot cope with movement of source trees at branching. When this magical "new developer" appears they can select what they want to build, and run the script. When "analysisplatform 1.0" is released then that can have a script too. I've done ample to cater for aforementioned "new developer" over the last 5 yrs, and whether they get active is their decision at the end of the day. The flexibility of being able to branch plugins individually to me seems more of a theoretical advantage, even more so as in practice building can become a nightmare, i.e. if you end up building an arbitrary combination of pluginX/branches/{version} paths. To my knowledge, there also hasn't been any need for branching an individual plugin so far? core, store.rdbms, java5, store.db4o are branched at 1.0. They will undergo significant changes in 1.1 (for Access Platform 1.1) that are incompatible with Access Platform 1.0, hence they are branched. Having a single product to branch would make things very very much more manageable, at the cost of something I haven't yet seen being necessary in practice. We've already been through that enough - in the Wiki. A plugin has a lifecycle, and an API to deliver. Products are built from a collection of plugins. "analysisplatform", when complete (part of it is in SVN), will need "core", "store.XXX" plugins. You can't have them under a different product for that reason. Change the API that a plugin delivers and it can need branching, which can cause dependents to be branched too (depending on release schedules for the actual products). ---------------------------------------- -Andy   |
||
|
|
erik
Expert Belgium Joined: Mar 12, 2004 Post Count: 3033 Status: Offline |
Parent poms might have its benefit, but I have myself to keep modified versions of maven poms, since I checkout using eclipse, and never use command line, so I dont use parent poms. This is a lot of work to me. ---------------------------------------- Erik Bengtson  |
||
|
|
andy
Expert UK / España Joined: Mar 13, 2004 Post Count: 4882 Status: Offline |
All projects under "platform" now no longer use parent POMs. Consequently they can be branched. Also there are scripts at the platform level build_accessplatform_1_0.sh build_accessplatform_1_1.sh allowing building of AccessPlatform 1.0 and 1.1. They can be improved upon. Somebody on Windows could even write a bat file too? M2 usage is still incomplete. The RAR created by M2 (project jdo.connector) is incorrect, not including the datanucleus-jca.jar. There are test projects with no pom.xml too. So still plenty to do for those people who have said they want full M2 support ... ---------------------------------------- -Andy |
||
|
|
jfrantzius
Advanced Member Germany Joined: Jun 18, 2004 Post Count: 405 Status: Offline |
Yes I'm aware of the theoretical benefits of inheritance but, as I said, there are very few deps in common across plugins (you included jdo2.jar but that is *not* required by some plugins so you're imposing on some plugins an additional build restriction by doing that), and that the M2 inheritance model doesn't fit the plugin-product model we have. You're right about that dependency. I forgot about that other persistence API ;) There is other stuff that you may want to switch on or off when building all of platform, like clover. There are less prominent dependencies (like log4j) that in the future you may want to reference with certain version. I played a bit with SpringDM, and I had to nail log4j down to a different version for all of platform. The flexibility of being able to branch plugins individually to me seems more of a theoretical advantage, even more so as in practice building can become a nightmare, i.e. if you end up building an arbitrary combination of pluginX/branches/{version} paths. To my knowledge, there also hasn't been any need for branching an individual plugin so far? core, store.rdbms, java5, store.db4o are branched at 1.0. They will undergo significant changes in 1.1 (for Access Platform 1.1) that are incompatible with Access Platform 1.0, hence they are branched. I wonder then why not all of platform is branched at once? If you branch core etc. for 1.0, you'll have to branch all that depends on it in Accessplatform 1.0 as well (since it won't work with the changes to come in trunk). So you could simply branch Accessplatform at once? Having a single product to branch would make things very very much more manageable, at the cost of something I haven't yet seen being necessary in practice. We've already been through that enough - in the Wiki. A plugin has a lifecycle, and an API to deliver. Products are built from a collection of plugins. "analysisplatform", when complete (part of it is in SVN), will need "core", "store.XXX" plugins. You can't have them under a different product for that reason. Change the API that a plugin delivers and it can need branching, which can cause dependents to be branched too (depending on release schedules for the actual products). What would be the problem with Analysisplatform if we branch Accessplatform as a whole? When looking at the products picture, it seems that Analysisplatform sits on top of Accessplatform. I can't see a problem here with branching Accessplatform. It occurs to me you'll end up doing exactly the same, only with a lot of different branches folders under platform. I'd see it that way: Analysisplatform is made up from whatever plugins it may add to the codebasis, and it depends on some plugins from Accessplatform, i.e. it doesn't contain them. So if Accessplatform advances in trunk, you simply branch it as a whole, keeping the API contract for Analysisplatform intact. |
||
|
|
andy
Expert UK / España Joined: Mar 13, 2004 Post Count: 4882 Status: Offline |
I wonder then why not all of platform is branched at once? Deja vu? I'm sure the Wiki went through this. So take a step into the future. Why release all plugins when AccessPlatform 1.1 is released for example? when "cache" hasn't changed, and when "store.rdbms.connectionpool" hasn't changed, and when "store.rdbms.spatial" hasn't changed (and who knows what else)? They will stay at their current versions. Releases take time to do, so if only "core" has changed then that gets released, and only that. Nobody else has offered their time to do releases, and I decide how my time is spent (and it certainly isn't in pointless releases of identical plugins). When looking at the products picture, it seems that Analysisplatform sits on top of Accessplatform. But AnalysisPlatform is not "on top of" AccessPlatform. Maybe that figure needs updating (was drawn for convenience to show the side text) ... yes you can offer to do that if you want ... . AnalysisPlatform will use some of the APIs in "core", "store.rdbms", etc (and some APIs may be added/adapted to help it fulfil its role). In the same way AccessPlatform uses some of the APIs in "core", "store.rdbms", etc. Branching is done due to functionality changes/additions in that particular plugin. We could have multiple point releases of "store.rdbms" during the development phase of a product for example. This thread is about getting full M2 support so hopefully people can focus on getting this task completed - after all its you users who want this flexibility; there have been 4 people that have said in the past 2 yrs that they'll give their time to do it ... ---------------------------------------- -Andy |
||
|
|
jfrantzius
Advanced Member Germany Joined: Jun 18, 2004 Post Count: 405 Status: Offline |
I wonder then why not all of platform is branched at once? Deja vu? I'm sure the Wiki went through this. Sure. At least in my head this is not clearly sorted out yet, I must admit. So take a step into the future. Why release all plugins when AccessPlatform 1.1 is released for example? when "cache" hasn't changed, and when "store.rdbms.connectionpool" hasn't changed, and when "store.rdbms.spatial" hasn't changed (and who knows what else)? They will stay at their current versions. Right. But creating a branch does not mean you have to give everything a new version? You can create a branch Accessplatform 1.1 with all of platform in it, containing some plugins that have changed since Accessplatform 1.0, and the rest that didn't. They'll all happily sit in branch 1.1 next to each other, I can't see a problem with that. If Accessplatform 1.1 means only a changed core, there still isn't any problem with branching all of platform for that, instead of only core. It's not that you have to release when you want to branch, it's vice-versa: if you want to release Accessplatform anyway (giving that product a new version number) , then you'll branch platform. I can't see why you'd have more release work with that. [..] In the same way AccessPlatform uses some of the APIs in "core", "store.rdbms", etc. Are there any plugins in platform that you don't consider being part of the AccessPlatform product? To me it seems that AccessPlatform is the plugins under platform, rather than AccessPlatform being something separate and immaterial that "uses" them (however such an immaterial ghost of a product could "use" any material plugins). After all, when you download the AccessPlatform product, you download the platform plugins, and nothing else. Branching is done due to functionality changes/additions in that particular plugin. We could have multiple point releases of "store.rdbms" during the development phase of a product for example. What exactly would be the problem then? "store.rdbms" would advance on trunk, and you'd release the new artifact versions to maven repos at your wish. They wouldn't be part of any released product until you decide to create a full product release. This thread is about getting full M2 support so hopefully people can focus on getting this task completed - after all its you users who want this flexibility; there have been 4 people that have said in the past 2 yrs that they'll give their time to do it ... And I'm sure they did give some of their time. |
||
|
|
|
|
Current timezone is GMT Dec 3, 2008 12:50:17 AM |
