RE: versioning of maven-model drops
-Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 7:11 PM To: Maven Developers List Subject: Re: versioning of maven-model drops On Wed, 2004-12-01 at 00:27, Michal Maczka wrote: Brett Porter wrote: I am just trying to propose something simpler as I am afraid that there will be way too many converters and parsers. The whole point in trying to stabilize the v4 POM is so that there will not be a proliferation of parsers and converters. For the v4.x there will only ever be additions. Period. If we much something up then we can replace the bad elements with something better but leave the mistakes and deprecate them over years. That being the case there won't be any converters because it will all be additions. And because we will only be dealing with additions any subsequent versions of the generate model tools will know how to deal with past versions. Moving from v3 - v4 is the only real chore we have to deal with. It will be simple because we're only going to do additions. And we can only do additions to the model as it's the only way we're going to have long-term stability. That's exactly what I was saying in that thread :) So to respond to yor initial question: What we are doing now is generating the most current version of the model is generated without versioning in the package name, so it's something like: org.apache.maven.model.* But we can optionally have versioning in the package name: org.apache.maven.model.v301.* We have used the versionless variant in the maven-core so that we don't have the wrangle version names when we upgrade the model which I like but if we are going to make separate utility drops should we release them with versioning in the package name? This would be for general use like the fellow wants to do on the user list. As we all agree that v4 model is not going to change radically (in case it will we can have v5 in the far away future) We can use using something like: org.apache.maven.model.v3 org.apache.maven.model.v4 as we won't ever need to have to flip packages names to org.apache.maven.model.v401 org.apache.maven.model.v402 etc when model will be envolving. The latest parser which we will deliver will support all possible mutation of v4 model. So I'm thinking we can always generate releases with versioning in the package name and generate the versionless package name for our use in maven-core. I guess that brings up the question of how to name the artifacts but that's the general notions. Once we figure this out I would like to cut a release of maven-model and let folks try it out. Thoughts? Most of the m2 plugins will not be using model directly. But some will. It will be nice if m2 and other tools were using exactly the same liblary (jar) and package names. So somebody can for example take some particular m2 mojo which uses m2 model and m2 model and execute it without a help of m2 runtime and m2-core jars. I suppose that dual packaging of the same classes will be confusing and we should avoid it. The only exception here should be made in case of m1 where both core and some plugins expects model v3 in certain package. Still tools like continum can use the parser which uses org.apache.maven.model.v3 for keeping model. So really the only difficulty which we will ever need to deal with is the differnces between version v3 and v4. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
Not sure what that means. It's easy now to change the name of package. ... The model was updated to the new format. I'm sure it's not quite right but not a lot of work to update. Yep, just needs to be verified. I haven't tried it in 1.1 since. All fine except for the xerces generated parser. I'd rather put the effort into making the xpp3 parser do entities and encodings. This is definitely a good idea anyway, and also my preference/ I want to avoid xerces like the plague. I understand, especially due to its speed and size, but it would be nice to have a works like it used to option in Maven 1.1. Let's rename that goal to plugin to generate a SAX parser. I don't think spitting out a SAX parser in modello (not specifically xerces) would be too difficult, and people who absolutely have to have feature X from parser Y can do so. By no means am I suggesting xerces would be the default, or even distributed with later versions of Maven. WDYT? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: versioning of maven-model drops
-Original Message- From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 9:40 AM To: Maven Developers List Subject: Re: versioning of maven-model drops [...] So I'm thinking we can always generate releases with versioning in the package name and generate the versionless package name for our use in maven-core. I guess that brings up the question of how to name the artifacts but that's the general notions. Once we figure this out I would like to cut a release of maven-model and let folks try it out. Thoughts? +1 for releasing it. So the SNAPSHOT version will be without versioned packages and the released version will be with versions? I don't think that this is linked with snapshots. Snapshot word in version is used for underlining the work in progress but once the release is made it should be (almost) identical to the last snapshot. --general comment-- I think that we are making this whole thing more complicated then it needs to be. There are probably two issues related to numbering of pom versions: At the moment we have two major versions of POMs: 3 and 4. Those versions are incompatible. Then within major version we have (can have) minor versions like 4.0.0, 4.0.1 etc. The changes introduced by minor version should be no breaking - it means that we can possibly add new tags or deprecate tags but all existing tags should be supported. Which means that in m2 which currently supports pom v4.0 we can simply put POM model into o.a.m.model.v4.* as this is not going to change anytime soon. The latest parser for each major version of POM should be able to parse all sub-versions of that version (4.0.0. 4.0.1, 4.0.2) Note that POM is quite stable and the changes are going to be quite rare. This is not something which is going to change every week. We should just not officialy release final version of POM v4.0.0 until we are happy with all use cases which we want address in m2 (until we will reaach beta version). Everybody willing to be an early adopter of m2 when it is still in alpha stage should be prepered that things might not be stable and API and POM can change. And I think it is quite acceptable. I would also propose to re-think our numbering of POM versions and use the following: v3 - maven 1.0.X v4 - maven 1.1.X v5 - maven 2.0.X For m1 we indeed need to generate model to o.a.m.project.* package. The same model and parser for it can be generated to o.a.m.model.v3 and used in m2, continuum etc. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
I don't think that this is linked with snapshots. Snapshot word in version is used for underlining the work in progress but once the release is made it should be (almost) identical to the last snapshot. agreed. --general comment-- I think that we are making this whole thing more complicated then it needs to be. Don't agree. It's actually quite simple as it is. Read on... There are probably two issues related to numbering of pom versions: At the moment we have two major versions of POMs: 3 and 4. Those versions are incompatible. Then within major version we have (can have) minor versions like 4.0.0, 4.0.1 etc. The changes introduced by minor version should be no breaking - it means that we can possibly add new tags or deprecate tags but all existing tags should be supported. agree to this. Which means that in m2 which currently supports pom v4.0 we can simply put POM model into o.a.m.model.v4.* as this is not going to change anytime soon. This is just a bit ugly, and does require an overhaul when you do a major version upgrade. Keeping latest in o.a.m.model.* works quite well. The latest parser for each major version of POM should be able to parse all sub-versions of that version (4.0.0. 4.0.1, 4.0.2) This will still work - you should be able to drop in maven-model-4.0.1 and it still works with code that expected 4. Converters, which care more about any version differences, will need to access v400 and v401. We should just not officialy release final version of POM v4.0.0 until we are happy with all use cases which we want address in m2 (until we will reaach beta version). This is exactly the plan. I would also propose to re-think our numbering of POM versions and use the following: v3 - maven 1.0.X v4 - maven 1.1.X v5 - maven 2.0.X I currently intend: v3.1.0 - Maven 1.1: non breaking additions. v4.0.0 - Maven 2.0: essentially starting from scratch, and transitive dependency enabled For m1 we indeed need to generate model to o.a.m.project.* package. The same model and parser for it can be generated to o.a.m.model.v3 and used in m2, continuum etc. exactly... Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: versioning of maven-model drops
-Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 2:10 PM To: Maven Developers List Subject: Re: versioning of maven-model drops [...] This will still work - you should be able to drop in maven-model-4.0.1 and it still works with code that expected 4. Converters, which care more about any version differences, will need to access v400 and v401. That's why I think it is more complicated then it needs to be. The first question is what kind of converters do you imagine here? Do you imagine that we will have converters between v400 and v401?. And for example between v400 and v405? How such converters will be implemented? Will we have converters between all version pairs possible? Chained converters (v400-v401-v402--...-v405)? I am not keen at all about having such converters as both scenarios are quite complex. I hope that once we are ready with pom v4 it will be almost never radically changed. Fundamental changes will go to v500 and m3 :) And as v405 will be backward compatible with v400 and we won't really need a converter between them - just a parser which supports both v400 and v405 in the same time. Next question is what we can really do with converters between major versions of POMs: e.g. between v3 and v4 and where and how such converter will be used? POMs v3 is fundamentaly different the POMv4 and conversion between those two versions can be partially automated but some information e.g. releated to inheriatnce, plugin configuration, preGoal, postGoals used in the project is not really easy to transform. It will be easier if we had a tool which will help to do this outside of m2 but I doubt that m2 will be able to directly support all v3 POMs and perform the required conversion is reliable way at the runtime. Do I miss something about converters or I misunderstood them completely? We should just not officialy release final version of POM v4.0.0 until we are happy with all use cases which we want address in m2 (until we will reaach beta version). This is exactly the plan. I would also propose to re-think our numbering of POM versions and use the following: v3 - maven 1.0.X v4 - maven 1.1.X v5 - maven 2.0.X I currently intend: v3.1.0 - Maven 1.1: non breaking additions. Haven't we been planning to use new way of declaring project inheritance in 1.1 with help of groupId and artifactId versions tags (like in m)? Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
Next question is what we can really do with converters between major versions of POMs: e.g. between v3 and v4 and where and how such converter will be used? I believe Trygvis has already implemented one for continuum. Correct, it is only partially automated, but it can warn on ignored info, fail on missing info. It can easily handle the different names in scm and connection, for example. It's been decided writing small converters (and if the changes are compatible, they should be trivial to write) is better than trying to get the model to do some form of inheritence. Minor versions might introduce deprecations on elements, for example - which makes the model different. Is there any reason where this is actually going to cause you a problem? Haven't we been planning to use new way of declaring project inheritance in 1.1 with help of groupId and artifactId versions tags (like in m)? Yes, but optionally. extend/ will still be there. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
Brett Porter wrote: [...] It's been decided writing small converters (and if the changes are compatible, they should be trivial to write) is better than trying to get the model to do some form of inheritence. Minor versions might introduce deprecations on elements, for example - which makes the model different. Is there any reason where this is actually going to cause you a problem? I am just trying to propose something simpler as I am afraid that there will be way too many converters and parsers. It could be that I don't get correctly what is the responsibility of converter in that solution. Say that the latest POM version supported by m2 is v402 - how many packages with different model versions and how many converters we will need to distribute to support v400, v401? I imagined that there will be always one parser in m2 for all possible released pom v4 variants and it will hide all the complexivity related to changes in POM structure. Exactly like it used to be for m1 where for example we had dual support for id and groupId/artifactId' tags in dependency. So if we will have something like maven2-model-v4-1.0.2.jar - it will contain the only parser which users/developers want to use to parse all known variants of pom v4. Once we will have pom v403 we will release maven2-model-v4-1.0.3.jar which support all previous versions and this new version. Isn't it simple enough? Michal -- Nudzisz sie? Zagraj sobie! http://link.interia.pl/f183d - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
Brett Porter wrote: Next question is what we can really do with converters between major versions of POMs: e.g. between v3 and v4 and where and how such converter will be used? I believe Trygvis has already implemented one for continuum. Correct, it is only partially automated, but it can warn on ignored info, fail on missing info. It can easily handle the different names in scm and connection, for example. As far I know Trygvis' tool converts poms in the repository. The biggest problem here is not that pom structure is different but that in case of m1 poms were splitted into 3 files (project.xml, project.properties, maven.xml) And we will just have one of them (project.xml) in the repository. Michal -- Ponad 400 tysiecy facetow czeka na Ciebie http://link.interia.pl/f183a - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
On Wed, 2004-12-01 at 00:27, Michal Maczka wrote: Brett Porter wrote: I am just trying to propose something simpler as I am afraid that there will be way too many converters and parsers. The whole point in trying to stabilize the v4 POM is so that there will not be a proliferation of parsers and converters. For the v4.x there will only ever be additions. Period. If we much something up then we can replace the bad elements with something better but leave the mistakes and deprecate them over years. That being the case there won't be any converters because it will all be additions. And because we will only be dealing with additions any subsequent versions of the generate model tools will know how to deal with past versions. Moving from v3 - v4 is the only real chore we have to deal with. It will be simple because we're only going to do additions. And we can only do additions to the model as it's the only way we're going to have long-term stability. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
Quoting Michal Maczka [EMAIL PROTECTED]: I imagined that there will be always one parser in m2 for all possible released pom v4 variants and it will hide all the complexivity related to changes in POM structure. Exactly like it used to be for m1 where for example we had dual support for id and groupId/artifactId' tags in dependency. So if we will have something like maven2-model-v4-1.0.2.jar - it will contain the only parser which users/developers want to use to parse all known variants of pom v4. Once we will have pom v403 we will release maven2-model-v4-1.0.3.jar which support all previous versions and this new version. Isn't it simple enough? Sorry if I confused the issue. As Jason said, if there are just additions, converters won't be needed and upgrading a JAR will just work. So exactly what you are saying is how it works currently. However, the artifact ID would be maven-model-4.0.0, maven-model-4.0.1, etc. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: versioning of maven-model drops
I don't know how this affects your question, but my immediate use case for maven-model is to load up a POM for a project, and then attempt to load up each dependencies POM. I'd like to be able to generate a report that lets me know that I am using the latest and greatest versioned artifact of each dependency, and so on up the line. Does maven-model transparently handle differing versions of the POM? I guess it would have to be versioned somehow in the package name in order to support that? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
Hi Jason, I thought the best was that the current one was always o.a.m.model.*, and all the historical ones were included with package name. ie in maven-model-4.0.0, there is just o.a.m.model; in maven-model-4.0.1 there is o.a.m.model.* and o.a.m.model.v400.*. An exception is for the v3.0.0 series. I'd like to use o.a.m.project as it requires fewer breaking changes to Maven 1.x. That is what is in maven-model-1.1-SNAPSHOT at the moment (which should really be renamed maven-model-3.0.0). Here is my last post to m2-dev about this, which outlines what I think needs to be done for a release: - changes to modello so we can use the .project package instead of hacking it at release time as I have done - verify current mdo still works - the one used on HEAD was pre-modello refactoring - verify the bugs have been fixed WRT properties - be able to build it with Maven 1.x (ie, revive the jelly modello plugin, or wrap the mojo in some way) - generate a parser that uses Xerces so entities and encodings can work if people choose the slower parser - ensure generated documentation can be used in m1 - release it as maven-model-3.0.0 instead of 1.1-SNAPSHOT as I have, then we can do 3.1.0 for 1.1 as I wanted to make some changes as we've previously discussed. Cheers, Brett Jason van Zyl wrote: Howdy, There was a post on the user list about some fellow wanting to read in a POM so I figured it would be a good opportunity to prepare some examples for a maven-model release. What we are doing now is generating the most current version of the model is generated without versioning in the package name, so it's something like: org.apache.maven.model.* But we can optionally have versioning in the package name: org.apache.maven.model.v301.* We have used the versionless variant in the maven-core so that we don't have the wrangle version names when we upgrade the model which I like but if we are going to make separate utility drops should we release them with versioning in the package name? This would be for general use like the fellow wants to do on the user list. So I'm thinking we can always generate releases with versioning in the package name and generate the versionless package name for our use in maven-core. I guess that brings up the question of how to name the artifacts but that's the general notions. Once we figure this out I would like to cut a release of maven-model and let folks try it out. Thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: versioning of maven-model drops
On Mon, 2004-11-29 at 14:32, Eric Pugh wrote: I don't know how this affects your question, but my immediate use case for maven-model is to load up a POM for a project, and then attempt to load up each dependencies POM. I'd like to be able to generate a report that lets me know that I am using the latest and greatest versioned artifact of each dependency, and so on up the line. Does maven-model transparently handle differing versions of the POM? I guess it would have to be versioned somehow in the package name in order to support that? The maven-model package is strictly for reading in the POM so it deals with straight data transfer and that's it. It does one thing and does it well. All the voodoo we do in m2 is in the project build which uses the maven-model package to read in POMs but all the inheritance and interpolation is done in the project builder. The maven-model package is meant to be as simple as possible and do one thing only so you could theoretcially use it for anything you like. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
On Mon, 2004-11-29 at 14:49, Brett Porter wrote: Hi Jason, I thought the best was that the current one was always o.a.m.model.*, and all the historical ones were included with package name. ie in maven-model-4.0.0, there is just o.a.m.model; in maven-model-4.0.1 there is o.a.m.model.* and o.a.m.model.v400.*. Right, that's the plan. An exception is for the v3.0.0 series. I'd like to use o.a.m.project as it requires fewer breaking changes to Maven 1.x. That is what is in maven-model-1.1-SNAPSHOT at the moment (which should really be renamed maven-model-3.0.0). That's cool. It's easy in modello now to control the package naming. Here is my last post to m2-dev about this, which outlines what I think needs to be done for a release: - changes to modello so we can use the .project package instead of hacking it at release time as I have done Not sure what that means. It's easy now to change the name of package. - verify current mdo still works - the one used on HEAD was pre-modello refactoring The model was updated to the new format. I'm sure it's not quite right but not a lot of work to update. - verify the bugs have been fixed WRT properties - be able to build it with Maven 1.x (ie, revive the jelly modello plugin, or wrap the mojo in some way) - generate a parser that uses Xerces so entities and encodings can work if people choose the slower parser - ensure generated documentation can be used in m1 - release it as maven-model-3.0.0 instead of 1.1-SNAPSHOT as I have, then we can do 3.1.0 for 1.1 as I wanted to make some changes as we've previously discussed. All fine except for the xerces generated parser. I'd rather put the effort into making the xpp3 parser do entities and encodings. I want to avoid xerces like the plague. Cheers, Brett Jason van Zyl wrote: Howdy, There was a post on the user list about some fellow wanting to read in a POM so I figured it would be a good opportunity to prepare some examples for a maven-model release. What we are doing now is generating the most current version of the model is generated without versioning in the package name, so it's something like: org.apache.maven.model.* But we can optionally have versioning in the package name: org.apache.maven.model.v301.* We have used the versionless variant in the maven-core so that we don't have the wrangle version names when we upgrade the model which I like but if we are going to make separate utility drops should we release them with versioning in the package name? This would be for general use like the fellow wants to do on the user list. So I'm thinking we can always generate releases with versioning in the package name and generate the versionless package name for our use in maven-core. I guess that brings up the question of how to name the artifacts but that's the general notions. Once we figure this out I would like to cut a release of maven-model and let folks try it out. Thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
