Re: POM construction specification
Mine below. On Dec 16, 2008, at 10:36 PM, Shane Isbell wrote: Comments in line On Tue, Dec 16, 2008 at 12:58 AM, Ralph Goers >wrote: On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: This is for the general population but I'm nudging you Ralph because I know that you want to make some changes for not requiring the version in the parent element. You should have warned me to have a glass of wine before attempting to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of use who haven't had a math class in the last 25 years. The funny thing is, I have a B.S. in Physics. Man it has been a long time. :-( Comments: 2.1 & 2.2 Is all this simply stating that the closest definition wins and when two or more are equally close then the first one wins? 2.1 covers the high level processing starting with the transformation from the original model (XML) to the canonical model and going through interpolation and other rules. 2.2 does cover which property wins for: singletons, collections and sets. OK. As I read 2.2 it basically only says the first definition wins. 2.1 talks about a collection of models, but it doesn't say anything about dependency resolution, either directly or in its references to section 3. In other words, I don't see anything that describes how the version of an artifact is determined when that artifact occurs in several places in the dependency tree. 2.4 The only "definition" of mixin is "The only difference between a parent pro ject and a mixin is that the mixin is abstract (not a complete model)". That sure leaves a lot to the imagination. And what exactly makes a model "incomplete"? Isn't a pom with just a dependencyManagement complete? I also found myself wondering that even though it might be possible to support extending multiple parents, should we? I could see allowing only one parent but multiple mixins. A mixin wouldn't be required to have things like project.version or project.groupId. This makes the model abstract. From the framework's perspective, it's all just a linear set of complete or incomplete models Whether it's considered multiple parents or a chains of inherited parents, it's all processed the same. My take is that if it's a complete model, it's actually just another parent. We are really just dealing with definitions here, it doesn't change processing. We can discuss more on what the definitions should be. I guess I really have no clue what functionality a mixin is supposed to provide or how it would be retrieved without a version or groupid. Is it being suggested they would be stored in the repo without that? I'd need a lot of convincing before I could buy off on that. 3.4 Why can't the groupId be inherited from its parent (or at least be set from project.parent.groupIdt)? Technically, it isn't inherited from the parent. If groupId is not defined, the project.parent.groupId is used (footnote 1). Personally, I think that including them in this list is just misleading. The effect is exactly the same. 3.4 The footnote says the artifactId can be inherited from the parent. That makes no sense to me. Every pom should represent a unique artifact or at least a unique pom. I'll change the spec doc. But when we throw in mixins, it's not exactly clear whether things like artifactId shouldn't be inherited. This will be one area we will need to discuss as we move toward mixins. I think you should start another thread to explain what the concept of mixins is. You referenced it once as the "solution" for importing managed dependencies. Some concrete examples would be nice. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
On 17-Dec-08, at 1:27 AM, Brett Porter wrote: I fixed some typos - is it ok to regenerate the PDF? (mine comes out slightly different on the Mac but it's all there AFAICT). Just to add to what Brian and Ralph have already said: 3.1 - I think we have to knock multiple inheritance out at this stage, even if it is noted as a possibility for general model building, I don't think it's appropriate for the Maven rules. 3.2 - We should just define this by the current behaviour IMO, then look at how we fix it going forward (See below on versioning) That' s all we're doing. The general mechanism is built into the builder for multiple inheritance the our constrained use only uses the super pom, but mixins are also inherited models. It was hard enough to sift backward and try and capture what it does and as I mentioned before I don't see any real changes being made to behavior until at least alpha-3. 3.3 - I had the same confusion as Brian. Why are collections not joined? Some more things: 1.1 - mentioned this before, but should be use a valid URI that perhaps matches the POM namespace? http://maven.apache.org/POM/... 2.2 - I didn't see anything that says that in a set, a property should overwrite a previous one if it already exists (and define how equality is measured)? 2.2 - I think map handling needs to be defined for the same reason so that duplicate keys can be merged 3.6.2 - why is the parent artifact ID listed in the (1-3) section? 3.6.2 - are join, nop and delete in a different order to the following bullets? 3.8 - how are properties represented by XML elements in the current schema handled in the URI? the "combine" technique is listed as a property, but is the attribute actually recognised as something different? 4.1 - refers to 3.4, but I think it means 3.6 4.1 - how is plugin configuration handled? it only details the combination of the artifact portion. Should executions be explicitly forbidden in the management just for clarity? 5.1.1 - timestamp format should be described? 5.1.1 - is the basedir absolute? 5.1.2 - this seems too "implementation specific" 5.1.4 - this is a self-referential definition. I don't think the difference between types of properties is clear enough - maybe defining system as dominant and environment as recessive is more descriptive 5.2.2 - need to list what the build directory elements are 5.3 - profiles are not addressed elsewhere - should their processing as an additional form of inheritance be described? Versioning... I really would like to understand how this is going to work. My impression is the following: - this document would be locked down to current behaviour as 4.0.0 (warts and all) - a new version of the document would make addition and changes, and would be a completely new rule set - the URIs would be the same, not including a version. - to operate on two versions of the model, the older would be upgraded to the new one first by a mapping of properties from one to the other. If the mapping was complicated it might need to be handled by an external converter - but the inheritance should always operate on two models of the same version. The problem here is that you can no longer honour some of the older rules from inherited POMs - but that may not be a serious consequence. Is this what you expect? BTW, should we now delete the wiki page that held basically the same info? Cheers, Brett On 17/12/2008, at 3:32 PM, Brian E. Fox wrote: "The only difference between a parent project and a mixin is that the mixin is abstract (not a complete model)." Is that really true? A Mixin should be deployed to the repository, which essentially means it needs to be complete enough to id and thus a complete model. It should be deployed as a classified artifact though to avoid mixing in the instructions for building/ deploying from those that are intended to be mixed in. (ie the mixin's pom is separate) 3.1: what about multiple parents? I assume it's the first one, but should be explicit in the spec. 3.2: section is blank but contentious based on current behavior and the in-ability to use properties and inheritance together. 3.3: I don't understand this statement. A child always overrides the parent or joins with it. Are you saying that the parent wins here? Also pluginRepositories is going away soon. In general why can't the things listed here be extended? 3.4 shouldn't project.distMgt.relocation be inherited if the relocation lists the group? (group/artifact/version ones should be skipped, but if you're relocating everything in a group, it would make sense to do this at the top of that group tree pom) 3.5 I agree with Ralph here that Final is the wrong term. Private is more appropriate. I started this in the morning and didn't finish yet so sending what I have. -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Tuesday,
Re: POM construction specification
On 16-Dec-08, at 3:58 AM, Ralph Goers wrote: On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: This is for the general population but I'm nudging you Ralph because I know that you want to make some changes for not requiring the version in the parent element. You should have warned me to have a glass of wine before attempting to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of use who haven't had a math class in the last 25 years. The funny thing is, I have a B.S. in Physics. Man it has been a long time. :-( Comments: 1.1 Mentions there are 465 model properties. An appendix should list them. Specifically, I'd like to see "provides" listed along with the project's groupId, artifactId and version and "requires" in the dependency declaration - or whatever other way that kind of metadata will be added. We should definitely add them to the appendix. If you actually look at the implementation the parsers are domain specific and they produce the set of model properties. I think Shane did what was correct in that he focused on a concrete implementation and got it working. So right now the domain specific parser is hand-written. There is no reason that this parser cannot be generated with modello and when we do that we can use the descriptions in the modello model to generate an appendix with a description of each property. 2.1 & 2.2 Is all this simply stating that the closest definition wins and when two or more are equally close then the first one wins? Let me add actual examples with POMs and I think it will be more clear. 2.4 The only "definition" of mixin is "The only difference between a parent pro ject and a mixin is that the mixin is abstract (not a complete model)". That sure leaves a lot to the imagination. And what exactly makes a model "incomplete"? Isn't a pom with just a dependencyManagement complete? I also found myself wondering that even though it might be possible to support extending multiple parents, should we? I could see allowing only one parent but multiple mixins. 3.1 Even though may be obvious, it should explicitly state that artifactId is always required. 3.4 Why can't the groupId be inherited from its parent (or at least be set from project.parent.groupIdt)? It can be. The Maven POMs exhibit this property and it works fine so I'll fix that. 3.4 The footnote says the artifactId can be inherited from the parent. That makes no sense to me. Every pom should represent a unique artifact or at least a unique pom. Yup. 3.5 I found the statement This will mark the container as final, thus preventing inheritance:" as misleading. In java terms this would mean a child pom attempting to define the same plugin would fail. The setting of "inherited" to false in the sample indicates to me the opposite, the plugin definition in the parent is invisible to the child. Here is a question though. If A overrides a plugin defined in the super pom and has inherited true, then B extends A and overrides the plugin and sets inherited to false, what will C which extends from B get? It should see the definition in A. Or does this whole section mean that the plugin definition in B inherits nothing from A? 3.8 "the element will be inherited." Unless the parent definition has false ? I don't see anything in here about being able to locate a parent without having to know its version. Within the scope of the purpose of this document it may not be relevant, but at the very least somewhere in section 3 it should state that if a parent is specified than which elements are required. I think if it has anything to do with POM construction then we need to include it in this document. I hope this was the kind of feedback you were looking for. This is great feedback. I'll get this converted into Confluence by the end of the week and then it will be easier to collaborate. Shane also reversed engineered the rules because nothing was ever documented as it grew organically. I think a few rounds of doing this where we clarify and the rules and we'll be in a lot better shape. I have started a POM construction test suite which will act as a validation for the specification which will be complete by alpha-2. For alpha-1 I had the goal of some specific builds working to get the ball rolling. The rigor will start after alpha-2 which combined with some of the integration testing tools we have I think will ensure we go forward and never backward again. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com ---
Re: POM construction specification
Comments in line On Tue, Dec 16, 2008 at 12:58 AM, Ralph Goers wrote: > > On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: > > This is for the general population but I'm nudging you Ralph because I >> know that you want to make some changes for not requiring the version in the >> parent element. >> >> > > You should have warned me to have a glass of wine before attempting to read > all these math notations. :-) Or put a link to > http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of > use who haven't had a math class in the last 25 years. The funny thing is, I > have a B.S. in Physics. Man it has been a long time. :-( > > Comments: > 2.1 & 2.2 Is all this simply stating that the closest definition wins and > when two or more are equally close then the first one wins? 2.1 covers the high level processing starting with the transformation from the original model (XML) to the canonical model and going through interpolation and other rules. 2.2 does cover which property wins for: singletons, collections and sets. > 2.4 The only "definition" of mixin is "The only difference between a parent > pro ject and a mixin is that the mixin is > abstract (not a complete model)". That sure leaves a lot to the > imagination. And what exactly makes a model "incomplete"? Isn't a pom with > just a dependencyManagement complete? I also found myself wondering that > even though it might be possible to support extending multiple parents, > should we? I could see allowing only one parent but multiple mixins. A mixin wouldn't be required to have things like project.version or project.groupId. This makes the model abstract. From the framework's perspective, it's all just a linear set of complete or incomplete models Whether it's considered multiple parents or a chains of inherited parents, it's all processed the same. My take is that if it's a complete model, it's actually just another parent. We are really just dealing with definitions here, it doesn't change processing. We can discuss more on what the definitions should be. > > 3.4 Why can't the groupId be inherited from its parent (or at least be set > from project.parent.groupIdt)? Technically, it isn't inherited from the parent. If groupId is not defined, the project.parent.groupId is used (footnote 1). > > 3.4 The footnote says the artifactId can be inherited from the parent. That > makes no sense to me. Every pom should represent a unique artifact or at > least a unique pom. I'll change the spec doc. But when we throw in mixins, it's not exactly clear whether things like artifactId shouldn't be inherited. This will be one area we will need to discuss as we move toward mixins. > > 3.5 I found the statement This will mark the container as final, thus > preventing inheritance:" as misleading. In java terms this would mean a > child pom attempting to define the same plugin would fail. The setting of > "inherited" to false in the sample indicates to me the opposite, the plugin > definition in the parent is invisible to the child. Here is a question > though. If A overrides a plugin defined in the super pom and has inherited > true, then B extends A and overrides the plugin and sets inherited to false, > what will C which extends from B get? It should see the definition in A. Or > does this whole section mean that the plugin definition in B inherits > nothing from A? You raise some good points. I was struggling a bit with the terms here. I'll give it some more thought. > > 3.8 "the element will be inherited." Unless the parent definition has > false ? > > I don't see anything in here about being able to locate a parent without > having to know its version. Within the scope of the purpose of this document > it may not be relevant, but at the very least somewhere in section 3 it > should state that if a parent is specified than which elements are required. Locating parents fell a bit outside of this original spec, but I think it's worth adding something about how this is to be handled. We would need some rule that says a parent.version is not required. And also how to cover the situation where project.parent.version and project.version are both missing. Thanks, Shane
Re: POM construction specification
I fixed some typos - is it ok to regenerate the PDF? (mine comes out slightly different on the Mac but it's all there AFAICT). Just to add to what Brian and Ralph have already said: 3.1 - I think we have to knock multiple inheritance out at this stage, even if it is noted as a possibility for general model building, I don't think it's appropriate for the Maven rules. 3.2 - We should just define this by the current behaviour IMO, then look at how we fix it going forward (See below on versioning) 3.3 - I had the same confusion as Brian. Why are collections not joined? Some more things: 1.1 - mentioned this before, but should be use a valid URI that perhaps matches the POM namespace? http://maven.apache.org/POM/... 2.2 - I didn't see anything that says that in a set, a property should overwrite a previous one if it already exists (and define how equality is measured)? 2.2 - I think map handling needs to be defined for the same reason so that duplicate keys can be merged 3.6.2 - why is the parent artifact ID listed in the (1-3) section? 3.6.2 - are join, nop and delete in a different order to the following bullets? 3.8 - how are properties represented by XML elements in the current schema handled in the URI? the "combine" technique is listed as a property, but is the attribute actually recognised as something different? 4.1 - refers to 3.4, but I think it means 3.6 4.1 - how is plugin configuration handled? it only details the combination of the artifact portion. Should executions be explicitly forbidden in the management just for clarity? 5.1.1 - timestamp format should be described? 5.1.1 - is the basedir absolute? 5.1.2 - this seems too "implementation specific" 5.1.4 - this is a self-referential definition. I don't think the difference between types of properties is clear enough - maybe defining system as dominant and environment as recessive is more descriptive 5.2.2 - need to list what the build directory elements are 5.3 - profiles are not addressed elsewhere - should their processing as an additional form of inheritance be described? Versioning... I really would like to understand how this is going to work. My impression is the following: - this document would be locked down to current behaviour as 4.0.0 (warts and all) - a new version of the document would make addition and changes, and would be a completely new rule set - the URIs would be the same, not including a version. - to operate on two versions of the model, the older would be upgraded to the new one first by a mapping of properties from one to the other. If the mapping was complicated it might need to be handled by an external converter - but the inheritance should always operate on two models of the same version. The problem here is that you can no longer honour some of the older rules from inherited POMs - but that may not be a serious consequence. Is this what you expect? BTW, should we now delete the wiki page that held basically the same info? Cheers, Brett On 17/12/2008, at 3:32 PM, Brian E. Fox wrote: "The only difference between a parent project and a mixin is that the mixin is abstract (not a complete model)." Is that really true? A Mixin should be deployed to the repository, which essentially means it needs to be complete enough to id and thus a complete model. It should be deployed as a classified artifact though to avoid mixing in the instructions for building/ deploying from those that are intended to be mixed in. (ie the mixin's pom is separate) 3.1: what about multiple parents? I assume it's the first one, but should be explicit in the spec. 3.2: section is blank but contentious based on current behavior and the in-ability to use properties and inheritance together. 3.3: I don't understand this statement. A child always overrides the parent or joins with it. Are you saying that the parent wins here? Also pluginRepositories is going away soon. In general why can't the things listed here be extended? 3.4 shouldn't project.distMgt.relocation be inherited if the relocation lists the group? (group/artifact/version ones should be skipped, but if you're relocating everything in a group, it would make sense to do this at the top of that group tree pom) 3.5 I agree with Ralph here that Final is the wrong term. Private is more appropriate. I started this in the morning and didn't finish yet so sending what I have. -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Tuesday, December 16, 2008 3:59 AM To: Maven Developers List Subject: Re: POM construction specification On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: This is for the general population but I'm nudging you Ralph because I know that you want to make some changes for not requiring the version in the parent element. You should have warned me to have a glass of wine before attempting to read all these math notations. :
Re: POM construction specification
The way I read 3.4 the parent does not win. The child declaration simply overrides the parent. Consider project developers. If specified in a child then only those developers participate in this subproject. developers specified in the parent are ignored. Whether it makes sense to do it that way is a different question. Ralph On Dec 16, 2008, at 8:32 PM, Brian E. Fox wrote: "The only difference between a parent project and a mixin is that the mixin is abstract (not a complete model)." Is that really true? A Mixin should be deployed to the repository, which essentially means it needs to be complete enough to id and thus a complete model. It should be deployed as a classified artifact though to avoid mixing in the instructions for building/ deploying from those that are intended to be mixed in. (ie the mixin's pom is separate) 3.1: what about multiple parents? I assume it's the first one, but should be explicit in the spec. 3.2: section is blank but contentious based on current behavior and the in-ability to use properties and inheritance together. 3.3: I don't understand this statement. A child always overrides the parent or joins with it. Are you saying that the parent wins here? Also pluginRepositories is going away soon. In general why can't the things listed here be extended? 3.4 shouldn't project.distMgt.relocation be inherited if the relocation lists the group? (group/artifact/version ones should be skipped, but if you're relocating everything in a group, it would make sense to do this at the top of that group tree pom) 3.5 I agree with Ralph here that Final is the wrong term. Private is more appropriate. I started this in the morning and didn't finish yet so sending what I have. -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Tuesday, December 16, 2008 3:59 AM To: Maven Developers List Subject: Re: POM construction specification On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: This is for the general population but I'm nudging you Ralph because I know that you want to make some changes for not requiring the version in the parent element. You should have warned me to have a glass of wine before attempting to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of use who haven't had a math class in the last 25 years. The funny thing is, I have a B.S. in Physics. Man it has been a long time. :-( Comments: 1.1 Mentions there are 465 model properties. An appendix should list them. Specifically, I'd like to see "provides" listed along with the project's groupId, artifactId and version and "requires" in the dependency declaration - or whatever other way that kind of metadata will be added. 2.1 & 2.2 Is all this simply stating that the closest definition wins and when two or more are equally close then the first one wins? 2.4 The only "definition" of mixin is "The only difference between a parent pro ject and a mixin is that the mixin is abstract (not a complete model)". That sure leaves a lot to the imagination. And what exactly makes a model "incomplete"? Isn't a pom with just a dependencyManagement complete? I also found myself wondering that even though it might be possible to support extending multiple parents, should we? I could see allowing only one parent but multiple mixins. 3.1 Even though may be obvious, it should explicitly state that artifactId is always required. 3.4 Why can't the groupId be inherited from its parent (or at least be set from project.parent.groupIdt)? 3.4 The footnote says the artifactId can be inherited from the parent. That makes no sense to me. Every pom should represent a unique artifact or at least a unique pom. 3.5 I found the statement This will mark the container as final, thus preventing inheritance:" as misleading. In java terms this would mean a child pom attempting to define the same plugin would fail. The setting of "inherited" to false in the sample indicates to me the opposite, the plugin definition in the parent is invisible to the child. Here is a question though. If A overrides a plugin defined in the super pom and has inherited true, then B extends A and overrides the plugin and sets inherited to false, what will C which extends from B get? It should see the definition in A. Or does this whole section mean that the plugin definition in B inherits nothing from A? 3.8 "the element will be inherited." Unless the parent definition has false ? I don't see anything in here about being able to locate a parent without having to know its version. Within the scope of the purpose of this document it may not be relevant, but at the very least somewhere in section 3 it should state that if a parent is specified than which elements are required. I hope this was the kind of feedback you were looking for. Ralph - To unsubscribe, e-mai
Re: Problem using velocity component
If you jar up your plugin project I'll take a look. Create a JIRA issue and attach the project and I'll see it. On 16-Dec-08, at 6:34 PM, Alfie Kirkpatrick wrote: Hi, I am attempting to write a plugin that uses Velocity to template some config files. I have been developing the plugin using m2eclipse embedded maven runtime and it works fine. But it gives a NPE when I run it in maven standalone, even with the 2.1M1 release. I have the following in my class: /** * @component */ protected VelocityComponent velocityComponent; The line giving the NPE is: Template template = velocityComponent.getEngine().getTemplate("/"+templateName+".vm"); When running standalone the velocityComponent is initialised with a DefaultVelocityComponent but with a null engine, so getTemplate gives the NPE. Am struggling to understand if I'm doing this correctly and why it should work in maven embedder (in m2eclipse) but not standalone? As an aside, my class implements org.codehaus.plexus.logging.LogEnabled and running with maven embedder, the enableLogging method is called with a PlexusLoggerAdapter, but running standalone this method is not called. Can't help feeling this is related... Any help much appreciated! Regards, Alfie. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Problem using velocity component
Hi, I am attempting to write a plugin that uses Velocity to template some config files. I have been developing the plugin using m2eclipse embedded maven runtime and it works fine. But it gives a NPE when I run it in maven standalone, even with the 2.1M1 release. I have the following in my class: /** * @component */ protected VelocityComponent velocityComponent; The line giving the NPE is: Template template = velocityComponent.getEngine().getTemplate("/"+templateName+".vm"); When running standalone the velocityComponent is initialised with a DefaultVelocityComponent but with a null engine, so getTemplate gives the NPE. Am struggling to understand if I'm doing this correctly and why it should work in maven embedder (in m2eclipse) but not standalone? As an aside, my class implements org.codehaus.plexus.logging.LogEnabled and running with maven embedder, the enableLogging method is called with a PlexusLoggerAdapter, but running standalone this method is not called. Can't help feeling this is related... Any help much appreciated! Regards, Alfie.
[2.0.10 RC6] please test
Hello, Thanks everyone for sticking with us this far. I have high hopes of this being the last RC. This RC fixes MNG-3898 and updates the default plugin versions in the super pom. You can see the changes to the super pom and specific versions used here: http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.10-RC/m aven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml?r 1=708789&r2=726765&diff_format=h Here's the list of issues fixed in 2.0.10 (updated to remove the wagon fixes that were rolled back): http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14112&styleName =Html&projectId=10500&Create=Create And I've staged RC-6 here: http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.10-RC6/ Please try it out and see if we have any remaining regressions over 2.0.9. Thanks, Brian -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
mng-3898 in 2.0.10?
Herve, I was just in the process of staging 2.0.10 when I noticed that you bumped the Modello version from alpha-13 to alpha-22. I didn't see this raised as an issue in any of the RCs and it concerns me to make such a jump this late in the game. Once we start the RCs we should only be fixing regressions reported against the RCs...it looks like this was a regression and thus qualifies but some discussion about the relative merits of the fix vs any potential destabilizing should take place. I'll roll back the stage and produce another RC for this. --Brian
RE: POM construction specification
"The only difference between a parent project and a mixin is that the mixin is abstract (not a complete model)." Is that really true? A Mixin should be deployed to the repository, which essentially means it needs to be complete enough to id and thus a complete model. It should be deployed as a classified artifact though to avoid mixing in the instructions for building/deploying from those that are intended to be mixed in. (ie the mixin's pom is separate) 3.1: what about multiple parents? I assume it's the first one, but should be explicit in the spec. 3.2: section is blank but contentious based on current behavior and the in-ability to use properties and inheritance together. 3.3: I don't understand this statement. A child always overrides the parent or joins with it. Are you saying that the parent wins here? Also pluginRepositories is going away soon. In general why can't the things listed here be extended? 3.4 shouldn't project.distMgt.relocation be inherited if the relocation lists the group? (group/artifact/version ones should be skipped, but if you're relocating everything in a group, it would make sense to do this at the top of that group tree pom) 3.5 I agree with Ralph here that Final is the wrong term. Private is more appropriate. I started this in the morning and didn't finish yet so sending what I have. -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Tuesday, December 16, 2008 3:59 AM To: Maven Developers List Subject: Re: POM construction specification On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: > This is for the general population but I'm nudging you Ralph because > I know that you want to make some changes for not requiring the > version in the parent element. > You should have warned me to have a glass of wine before attempting to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of use who haven't had a math class in the last 25 years. The funny thing is, I have a B.S. in Physics. Man it has been a long time. :-( Comments: 1.1 Mentions there are 465 model properties. An appendix should list them. Specifically, I'd like to see "provides" listed along with the project's groupId, artifactId and version and "requires" in the dependency declaration - or whatever other way that kind of metadata will be added. 2.1 & 2.2 Is all this simply stating that the closest definition wins and when two or more are equally close then the first one wins? 2.4 The only "definition" of mixin is "The only difference between a parent pro ject and a mixin is that the mixin is abstract (not a complete model)". That sure leaves a lot to the imagination. And what exactly makes a model "incomplete"? Isn't a pom with just a dependencyManagement complete? I also found myself wondering that even though it might be possible to support extending multiple parents, should we? I could see allowing only one parent but multiple mixins. 3.1 Even though may be obvious, it should explicitly state that artifactId is always required. 3.4 Why can't the groupId be inherited from its parent (or at least be set from project.parent.groupIdt)? 3.4 The footnote says the artifactId can be inherited from the parent. That makes no sense to me. Every pom should represent a unique artifact or at least a unique pom. 3.5 I found the statement This will mark the container as final, thus preventing inheritance:" as misleading. In java terms this would mean a child pom attempting to define the same plugin would fail. The setting of "inherited" to false in the sample indicates to me the opposite, the plugin definition in the parent is invisible to the child. Here is a question though. If A overrides a plugin defined in the super pom and has inherited true, then B extends A and overrides the plugin and sets inherited to false, what will C which extends from B get? It should see the definition in A. Or does this whole section mean that the plugin definition in B inherits nothing from A? 3.8 "the element will be inherited." Unless the parent definition has false ? I don't see anything in here about being able to locate a parent without having to know its version. Within the scope of the purpose of this document it may not be relevant, but at the very least somewhere in section 3 it should state that if a parent is specified than which elements are required. I hope this was the kind of feedback you were looking for. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Improving CI & ITs
On 17/12/2008, at 1:59 PM, Brian E. Fox wrote: - we have deployment of the IT plugins to a repository even as snapshots, though I thought it was required to be pre-installed based on the bits below? Everything is ready now for them to be deployed as releases to a repo that is separate from Central to avoid the clashes that people saw before. Great. I wonder, is the test still valuable enough if we kick off a Jetty instance and host the repo locally rather than relying on an external resource being up/accessible? Upsides: that would also help with avoiding repo manager interference in the results, tests would be faster Downsides: a bit more complicated test set up. If it were started from the POM, it disadvantages IDE running, if it were started from the tests it adds a bit of complication in there. WDYT? John and I came up with this solution because it was frustrating always trying to chase either the maven snapshot or the it snapshot when things were committed. By putting it into the bootstrap, we now have a single execution that builds both Maven and the Its and then run them together. A single atomic unit. I still see some value in the unpack-and-run approach personally but I also think having multiple ways to run Its is annoying to explain to new users. I think the bootstrap one is easy. It might be nice to investigate a CI plugin that can always keep those builds together and take another look in the future. There are still some things that make me a bit uneasy about it: - the "dummy" POM (2.0.x)... seems like this should be functionality right in the top level POM or a "proper" module. - it seems awkward to work on , you'd need to revert to running mvn from your working directory for the IT instead since you have to commit for the other changes to take, or reconfigure itDir - it's sad that the main way to build Maven is not with Maven :) I also think it makes sense to release the integration tests that were used to verify a particular release of Maven so we always have that locked in. Otherwise as the ITs change, we have a different measure of what worked in 2.0.x and what didn't. The runner approach is much better suited to this rather than checking it out from a tag each time. Agreed. Cool. I see this change still supports that through a tagged checkout. Will we release the ITs for 2.0.10, or is that too soon? Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: sometimes too much help is not helping - r725533
Oleg and I sorted out the misunderstanding offline. It's all good. - Brett On 17/12/2008, at 2:19 PM, Oleg Gusakov wrote: Brett, Trust me, I don't enjoy this discussion no more that you, but I have to respond. Brett Porter wrote: I'm sorry you lost some time investigating it, but I made every attempt to do this properly. At the time I made the change, I cleaned out the checkout and did a build without getting any test errors. This was confirmed by the grid: https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/ It appears your change to test using compilation was only checked in afterwards. I'm afraid I'm still working on my ability to predict the future :) This statement suggests that I am a dumb coder, who submits tons of jars to SVN for the pleasure of just having them there. I admit that I did not commit the tests using those jars right away. But give me some credit: everything has a reason. And if this reason is not clear - ask, don't assume you know everything and can improve without knowing. I did acknowledge your suggestion about the size of test repo, and started fixing it. If you would have just suggested the solution, provided a script in jira - that would only raise a lot of gratitude. But hindering a pre-alpha quality project by assuming things and changing still unstable data, this is simply not fair. Losing a day over such a trivial matter - I simply did not expect anyone to do such a thing. I apologize if this sounds harsh, but believe me - the sole purpose is to improve our process, make sure that this does not happen in the future. So the proposal is: change the rules to say the following: "if you don't work on an actively developed project - don't start modifying it without consulting the team, working on it. If you do find a bug or improvement - communicate with developers via issue tracking system and other means" This is not predicting the future - just common sense. Thanks, Oleg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: sometimes too much help is not helping - r725533
Brett, Trust me, I don't enjoy this discussion no more that you, but I have to respond. Brett Porter wrote: I'm sorry you lost some time investigating it, but I made every attempt to do this properly. At the time I made the change, I cleaned out the checkout and did a build without getting any test errors. This was confirmed by the grid: https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/ It appears your change to test using compilation was only checked in afterwards. I'm afraid I'm still working on my ability to predict the future :) This statement suggests that I am a dumb coder, who submits tons of jars to SVN for the pleasure of just having them there. I admit that I did not commit the tests using those jars right away. But give me some credit: everything has a reason. And if this reason is not clear - ask, don't assume you know everything and can improve without knowing. I did acknowledge your suggestion about the size of test repo, and started fixing it. If you would have just suggested the solution, provided a script in jira - that would only raise a lot of gratitude. But hindering a pre-alpha quality project by assuming things and changing still unstable data, this is simply not fair. Losing a day over such a trivial matter - I simply did not expect anyone to do such a thing. I apologize if this sounds harsh, but believe me - the sole purpose is to improve our process, make sure that this does not happen in the future. So the proposal is: change the rules to say the following: "if you don't work on an actively developed project - don't start modifying it without consulting the team, working on it. If you do find a bug or improvement - communicate with developers via issue tracking system and other means" This is not predicting the future - just common sense. Thanks, Oleg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: svn commit: r726848 - /maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml
The snapshots are coming from CI. The releases will as well. Once Apache gets LDAP setup, hopefully we can tap into it to make it easier. The current security model isn't very scalable. -Original Message- From: Brett Porter [mailto:br...@porterclan.net] Sent: Tuesday, December 16, 2008 6:26 PM To: dev@maven.apache.org Subject: Re: svn commit: r726848 - /maven/core-integration-testing/trunk/core-it-support/core-it-plugins/po m.xml Er, I can't deploy there :) Is that setting necessary? It should be inherited from the parent so any CI process that wants to deploy elsewhere can just override distMgmtSnapshotsUrl from the command line, which I thought was how it was being done for everything else. Cheers, Brett 2008/12/16 > Author: brianf > Date: Mon Dec 15 14:20:54 2008 > New Revision: 726848 > > URL: http://svn.apache.org/viewvc?rev=726848&view=rev > Log: > deploy the plugins to a repo > > Modified: > > maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom .xml > > Modified: > maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom .xml > URL: > http://svn.apache.org/viewvc/maven/core-integration-testing/trunk/core-i t-support/core-it-plugins/pom.xml?rev=726848&r1=726847&r2=726848&view=di ff > > == > --- > maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom .xml > (original) > +++ > maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom .xml > Mon Dec 15 14:20:54 2008 > @@ -64,6 +64,23 @@ > scm:svn: > https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/co re-it-support/core-it-plugins > > > http://svn.apache.org/viewvc/maven/core-integration-testing/trunk/core-i t-support/core-it-plugins > > > + > + > + maven.it > + Apache Maven Integration Testing Repository > + > http://repository.sonatype.org/content/repositories/maven-it-plugins > + > + > + maven.it > + ${distMgmtSnapshotsName} > + ${distMgmtSnapshotsUrl} > + > + > + > + > +Apache Maven Integration Testing Snapshot > Repository > + > http://repository.sonatype.org/content/repositories/maven-it-plugin-snap shots > > + > > > > > > -- Brett Porter http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Improving CI & ITs
>- we have deployment of the IT plugins to a repository even as >snapshots, though I thought it was required to be pre-installed based >on the bits below? Everything is ready now for them to be deployed as releases to a repo that is separate from Central to avoid the clashes that people saw before. >but I'd >like to understand the technical reasons for choosing the bootstrap, >etc. over the unpack-and-run approach of maven-core-it-runner before >it disappears completely. The only one I've heard described was the >possibility of the IT artifacts in the repo being out of date, but >that's irrelevant in a CI situation and they seem to be getting >deployed above anyway. John and I came up with this solution because it was frustrating always trying to chase either the maven snapshot or the it snapshot when things were committed. By putting it into the bootstrap, we now have a single execution that builds both Maven and the Its and then run them together. A single atomic unit. I still see some value in the unpack-and-run approach personally but I also think having multiple ways to run Its is annoying to explain to new users. I think the bootstrap one is easy. >I also think it makes sense to release the integration tests that were >used to verify a particular release of Maven so we always have that >locked in. Otherwise as the ITs change, we have a different measure of >what worked in 2.0.x and what didn't. The runner approach is much >better suited to this rather than checking it out from a tag each time. Agreed. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: sometimes too much help is not helping - r725533
On 17/12/2008, at 11:03 AM, Oleg Gusakov wrote: Brett, Please don't change the code you don't understand without, at least, consulting people who work on it. I did try... http://markmail.org/message/ifkbjf3rb24z3wvb I have a good understanding of how the code works. Outside of the Jetty client, I think I may be the only person (with the possible exception of Jason) that has given it a decent look over at this point. I'm still seeking you're enlightenment on the pieces I didn't understand: http://markmail.org/message/tibxv4f7di2caj2y, and am still looking forward to your response. I lost entire day between yesterday and today, trying to understand why my unit tests suddenly stopped working. They traced to your commit r725533 which emptied jar files in mercury-ant-tasks! Unit tests were using those jars to compile test code. I'm sorry you lost some time investigating it, but I made every attempt to do this properly. At the time I made the change, I cleaned out the checkout and did a build without getting any test errors. This was confirmed by the grid: https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/ It appears your change to test using compilation was only checked in afterwards. I'm afraid I'm still working on my ability to predict the future :) Certainly if it had been a functional change I'd have spent more time in consultation as you suggested. The example you gave from Benjamin is certainly a good way for things to work. We all need to tread lightly in unfamiliar territory, and I understand that. I have no desire to look like an idiot through inexperience if I can avoid it. Anyway, thanks for fixing up the size of the test repo even in the "reversion". I do appreciate it. - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
sometimes too much help is not helping - r725533
Brett, Please don't change the code you don't understand without, at least, consulting people who work on it. I lost entire day between yesterday and today, trying to understand why my unit tests suddenly stopped working. They traced to your commit r725533 which emptied jar files in mercury-ant-tasks! Unit tests were using those jars to compile test code. I appreciate the help, but help that adds value to the project, not hinders it. Take, for example, Ben - he found a bug and posted the solution in jira, because he was not sure that it can break tests. It did break them, but together we found the solution (btw - he was right). Our team is very responsive, and posting problem in jira usually gets them resolved. Thanks, Oleg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r726848 - /maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml
Er, I can't deploy there :) Is that setting necessary? It should be inherited from the parent so any CI process that wants to deploy elsewhere can just override distMgmtSnapshotsUrl from the command line, which I thought was how it was being done for everything else. Cheers, Brett 2008/12/16 > Author: brianf > Date: Mon Dec 15 14:20:54 2008 > New Revision: 726848 > > URL: http://svn.apache.org/viewvc?rev=726848&view=rev > Log: > deploy the plugins to a repo > > Modified: > > maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml > > Modified: > maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml > URL: > http://svn.apache.org/viewvc/maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml?rev=726848&r1=726847&r2=726848&view=diff > > == > --- > maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml > (original) > +++ > maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml > Mon Dec 15 14:20:54 2008 > @@ -64,6 +64,23 @@ > scm:svn: > https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-it-support/core-it-plugins > > > http://svn.apache.org/viewvc/maven/core-integration-testing/trunk/core-it-support/core-it-plugins > > > + > + > + maven.it > + Apache Maven Integration Testing Repository > + > http://repository.sonatype.org/content/repositories/maven-it-plugins > + > + > + maven.it > + ${distMgmtSnapshotsName} > + ${distMgmtSnapshotsUrl} > + > + > + > + > +Apache Maven Integration Testing Snapshot > Repository > + > http://repository.sonatype.org/content/repositories/maven-it-plugin-snapshots > > + > > > > > > -- Brett Porter http://blogs.exist.com/bporter/
Re: Maven Shaded Jars + Netbeans = confused Netbeans?
Hello, Any ideas what could cause it? Any hints, workarounds, anything? Greetings, L Lilianne E. Blaze wrote: > Hello, > (I already tried on users- list) > > I'm trying to make a jar containing x dependencies to be used as a > single dependency, using Shade with the following options: > > true > true > true > > It seems ok, looks ok, works ok. _But_ - Netbeans doesn't seem to > recognize it - code completion fails with "package/class/symbol does not > exist" errors all over the place. Now I'm pretty much stuck. It could be > a problem with Maven, could be with Netbeans, could be my (complete or > partial) mistake with understanding how Maven makes / handles Shaded jars. > > I already submitted a report at > http://www.netbeans.org/issues/show_bug.cgi?id=155091 , along with a > simple project (3 projects, 2 classes) to demonstrate it. > > Greetings, thanks in advance, Lilianne > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
I don't believe the doc covered pre-/post- lifecycle operations, just the @aggregator changes that were the initial discussion. They'd probably need a new proposal. Perhaps something hooking into the model builder listening from the new work on trunk (just taking a wild stab in the dark, haven't looked at it since they were introduced). - Brett On 15/12/2008, at 8:11 PM, Stephen Connolly wrote: 2008/12/15 Brett Porter On 12/12/2008, at 6:57 AM, Barrie Treloar wrote: On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox > wrote: I think most of these ideas are already covered in the lifecycle proposal out there that john wrote. Can you paste the link in please? http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning There are two linked docs at the bottom that are probably more relevant. It's not clear to me from that proposal, how we could accommodate plugins that need to update the pom... For example, I'd like that versions-maven-plugin could work preemptively for goals like update-parent... Perhaps some mojos will need a way to run outside the lifecycle, or at least signal that they could affect build plan determination somewhat... for example, if I update the parent of some modules to a newer version, that newer version may add/remove profiles, add/remove plugins, etc. Perhaps that is covered in the Wiki, but it's just not clear to me -Stephen - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: external components was: svn commit: r726521
+1 It's too difficult to follow what it is done in 2.0.X, 2.X and 3.X in the same time without working on it every day. Arnaud On Tue, Dec 16, 2008 at 9:50 AM, Ralph Goers wrote: > > On Dec 15, 2008, at 7:41 AM, Jason van Zyl wrote: > >> >> >> Also in the course of 6 months of development of the model-builder we have >> not had a single contribution from anyone else. Zero interest. So yes, it is >> easier to release elsewhere and that has allowed me to patch, test, release >> in rapid succession to try and get the alpha-1 to the point of release. >> >> > I wouldn't say "zero interest". I simply have found it impossible to keep > up with all the svn commits in all the various branches. Furthermore, a lot > of stuff was being worked on in somewhat private branches. Unless they ask > for collaboration I'm not going to go review stuff in someone's private > sandbox until they call out and say it is ready for review before merging. > > Ralph > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- .. Arnaud HERITIER 12 guidelines to boost your productivity with a Java software factory - http://tinyurl.com/56s9tw .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: Improving CI & ITs
On 16/12/2008, at 11:51 AM, Jason van Zyl wrote: By layering I think that a canonical system should be picked, say Ubuntu, and that should be a fast compile-only smoke test to look for breakages. If that works trigger the tests, if that works propagate to the grid, do the build and run the ITs. Then layer in plugin tests maybe daily. That may not be the perfect workflow and we should put this in the wiki. +1, something like this sounds good. Tom/John, I don't know how long it will take to finish the maven integration testing plugin and get all the nodes updated. But I can do the dirty trick that I did before which was the let the bootstrap feed into a predefined Maven installation location. I just want to get the ITs triggered correctly using the version of Maven built by the bootstrap. I still don't quite get the approaches being used here. Can someone clear up all the pieces for me? - we have deployment of the IT plugins to a repository even as snapshots, though I thought it was required to be pre-installed based on the bits below? - maven-integration-tests checks out the ITs from trunk but how does that integrate with Hudson's existing SCM checks? - Hudson plugins are meant to coordinate running with a version instead of requiring the above? I agree there needs to be one standard way to do these things, but I'd like to understand the technical reasons for choosing the bootstrap, etc. over the unpack-and-run approach of maven-core-it-runner before it disappears completely. The only one I've heard described was the possibility of the IT artifacts in the repo being out of date, but that's irrelevant in a CI situation and they seem to be getting deployed above anyway. To me, the approach is much more Maven-y by reusing the repository and ordering, and it's easy to understand. Where did it not address the needs in setting this up? I also think it makes sense to release the integration tests that were used to verify a particular release of Maven so we always have that locked in. Otherwise as the ITs change, we have a different measure of what worked in 2.0.x and what didn't. The runner approach is much better suited to this rather than checking it out from a tag each time. Benjamin, you've basically done all the work for the ITs so far. You think you might sketch out in the wiki what you think would be ideal? At this point I think we defer to you as you've been working on them so long. Benjamin++ :) Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: external components was: svn commit: r726521
On 16/12/2008, at 7:50 PM, Ralph Goers wrote: On Dec 15, 2008, at 7:41 AM, Jason van Zyl wrote: Also in the course of 6 months of development of the model-builder we have not had a single contribution from anyone else. Zero interest. So yes, it is easier to release elsewhere and that has allowed me to patch, test, release in rapid succession to try and get the alpha-1 to the point of release. I wouldn't say "zero interest". I simply have found it impossible to keep up with all the svn commits in all the various branches. Furthermore, a lot of stuff was being worked on in somewhat private branches. Unless they ask for collaboration I'm not going to go review stuff in someone's private sandbox until they call out and say it is ready for review before merging. Yes, exactly. I don't particularly care if the code is put somewhere else. The license allows it and I'm not particularly attached to my single trivial commit. I do care if we start introducing dependencies from external sources without setting a higher barrier. If it were anything like Woodstox where it was pretty much baked and clear what to do if you have a problem then it'd be fine. But if it's going to be outside the project (particularly where some people don't have commit access) we can't chase snapshots. The situation with Modello and Plexus is not an ideal way to continue doing things given the chance to change, no matter how easy it is to get commit or how easy it is to get the whole chain of dependencies up in an IDE. Even if the code of the model-builder is completely stable, it needs more work: - there's no site or documentation to go with it (from what I can tell, all the documentation is in the PDF which is now in Maven) - there's no issue tracker to report problems to (I found SPICE though it's not listed in the POM, but it doesn't have a component) - there's no way to find out where it is going next or ask questions. That's either going to happen here (in which case, why move?), or need to be done privately with Shane (which is not scalable). The fact that it was released (as 1.0) like that, without changing the packages or the license made it look to me like it was the right thing done at the wrong time for the wrong reasons. Given that, it was just hard to tell what was going on - though it is helpful that it has been made clear that nothing else is going to be moved now. Thanks, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.x
Agreed. I would like that we simplify our notifications I we could remove them from hud...@apache and continuum if we don't use them anymore. Arnaud On Tue, Dec 16, 2008 at 9:40 PM, Brett Porter wrote: > On 16/12/2008, at 1:42 AM, Jason van Zyl wrote: > > I think before the alpha-1 I don't think everyone is interested in getting >> spammed, but once the release is cut the goal is to keep the build on the >> grid machines in a perpetual working state so standard notification at that >> point should be fine. >> > > With them up and running now I'd expect that the objective is already to > keep them in a perpetual working state, so changing the notifications over > would be helpful. There are some people changing the ITs even if they aren't > changing trunk (for 2.0.10, f.e.) and it'd be good to know the effect that > has. > > Thanks, > > Brett > > -- > Brett Porter > br...@apache.org > http://blogs.exist.com/bporter/ > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- .. Arnaud HERITIER 12 guidelines to boost your productivity with a Java software factory - http://tinyurl.com/56s9tw .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: Maven 3.x
On 16/12/2008, at 1:42 AM, Jason van Zyl wrote: I think before the alpha-1 I don't think everyone is interested in getting spammed, but once the release is cut the goal is to keep the build on the grid machines in a perpetual working state so standard notification at that point should be fine. With them up and running now I'd expect that the objective is already to keep them in a perpetual working state, so changing the notifications over would be helpful. There are some people changing the ITs even if they aren't changing trunk (for 2.0.10, f.e.) and it'd be good to know the effect that has. Thanks, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r726880 - in /maven/mercury/trunk: mercury-ant/mercury-ant-tasks/ mercury-ant/mercury-ant-tasks/src/main/java/org/apache/maven/mercury/ant/tasks/ mercury-ant/mercury-ant-tasks/src/main
Recorded in http://jira.codehaus.org/browse/MERCURY-59, will comply asahp Benjamin Bentmann wrote: Hi Oleg, Author: ogusakov Date: Mon Dec 15 16:04:14 2008 New Revision: 726880 URL: http://svn.apache.org/viewvc?rev=726880&view=rev Log: [MERCURY-56] verification configuration for mercury ant tasks done, PGP unit test works on osx. Need test keyrings for other platforms. [...] @@ -30,7 +40,7 @@ public class Config extends AbstractDataType { - private static final Language LANG = new DefaultLanguage( Config.class ); + private static final Language _lang = new DefaultLanguage( Config.class ); Collection _repos; @@ -178,6 +123,22 @@ String _authid; String _proxyauthid; +boolean _readable = true; +boolean _writeable = false; ++List _writeVerifiers; +List _readVerifiers; + +public void setReadable( boolean readable ) +{ + this._readable = readable; +} + +@@ -207,6 +168,135 @@ { return _dir != null; } ++public Verify createVerifywrite() +{ + if( _writeVerifiers == null ) +_writeVerifiers = new ArrayList(2); Please adopt our community conventions for Java code style [0, 1] which is usually as easy as importing the provided formatter configs into the IDE. A consistent formatting eases reading/reviewing the code and more importantly simplifies contributing/patching. Thanks Benjamin [0] http://maven.apache.org/developers/committer-environment.html#Maven_Code_Style [1] http://maven.apache.org/developers/conventions/code.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r726880 - in /maven/mercury/trunk: mercury-ant/mercury-ant-tasks/ mercury-ant/mercury-ant-tasks/src/main/java/org/apache/maven/mercury/ant/tasks/ mercury-ant/mercury-ant-tasks/src/main
Ben, Benjamin Bentmann wrote: Hi Oleg, Author: ogusakov Date: Mon Dec 15 16:04:14 2008 New Revision: 726880 URL: http://svn.apache.org/viewvc?rev=726880&view=rev Log: [MERCURY-56] verification configuration for mercury ant tasks done, PGP unit test works on osx. Need test keyrings for other platforms. [...] @@ -30,7 +40,7 @@ public class Config extends AbstractDataType { - private static final Language LANG = new DefaultLanguage( Config.class ); + private static final Language _lang = new DefaultLanguage( Config.class ); Collection _repos; @@ -178,6 +123,22 @@ String _authid; String _proxyauthid; +boolean _readable = true; +boolean _writeable = false; ++List _writeVerifiers; +List _readVerifiers; + +public void setReadable( boolean readable ) +{ + this._readable = readable; +} + +@@ -207,6 +168,135 @@ { return _dir != null; } ++public Verify createVerifywrite() +{ + if( _writeVerifiers == null ) +_writeVerifiers = new ArrayList(2); Please adopt our community conventions for Java code style [0, 1] which is usually as easy as importing the provided formatter configs into the IDE. A consistent formatting eases reading/reviewing the code and more importantly simplifies contributing/patching. Please don't make mass changes without talking. I am still doing a lot of modifications and having inconsistent code base - a lot of svn conflicts - impedes the process. Record them as a jira for now. Thanks, Oleg Thanks Benjamin [0] http://maven.apache.org/developers/committer-environment.html#Maven_Code_Style [1] http://maven.apache.org/developers/conventions/code.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven ant task
Hello, I'm having problem setting ant attributes with a property passed from pom file. Here is the pom part where I call ant target: Here is the ant file: ${shared-repo} I'm interested in using ${shared-repo} parameter, but although echo prints the correct value of this parameter, it doesn't set localRepository path (and default is used instead). Hope my problem is clear and not too stupid :). Any help would be appreciated. Thanks -- View this message in context: http://www.nabble.com/maven-ant-task-tp21037680p21037680.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r726880 - in /maven/mercury/trunk: mercury-ant/mercury-ant-tasks/ mercury-ant/mercury-ant-tasks/src/main/java/org/apache/maven/mercury/ant/tasks/ mercury-ant/mercury-ant-tasks/src/main
Hey Ben, Benjamin Bentmann wrote: Hi Oleg, Author: ogusakov Date: Mon Dec 15 16:04:14 2008 New Revision: 726880 URL: http://svn.apache.org/viewvc?rev=726880&view=rev Log: [MERCURY-56] verification configuration for mercury ant tasks done, PGP unit test works on osx. Need test keyrings for other platforms. Modified: maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java URL: http://svn.apache.org/viewvc/maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java?rev=726880&r1=726879&r2=726880&view=diff == --- maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java (original) +++ maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java Mon Dec 15 16:04:14 2008 @@ -593,35 +595,35 @@ public static void main( String[] args ) throws IOException, StreamObserverException { It looks odd for a utility class to have main() method. If it serves a production purpose, wouldn't it be better to move the main() out into a dedicated class, say in the default package with a descriptive name for easy invocation from CLI? If it's only for testing, src/main/java is definitively the wrong place. Maybe ... Likewise, RepositoryUpdateIntervalPolicy from the mercury-repo-api contains a main() method which pretty much looks like test code that should be deleted/moved out. This one - agree, I missed it when cleaning //--- + public static InputStream toStream( String resource ) + throws MalformedURLException, IOException + { +if( Util.isEmpty( resource ) ) + return null; ++if( resource.startsWith( "file://" ) +|| resource.startsWith( "http://"; ) +) + return new URL(resource).openStream(); + +return new FileInputStream( new File(resource) ); + } RFC 2396 [0], section 3.1, "Scheme Component" suggests to treat upper case letters as equivalent to lower case in scheme names (e.g., allow "HTTP" as well as "http") Also, can you elaborate what motivates the selection of only "file://" and "http://"; as protocols? For instance, whereever HTTP is used the option of HTTPS isn't that far. FTP? Would it maybe better match your intention to just always call URL.openStream() and fallback to the FileInputStream in the case the former method threw an exception ("unknown protocol")? I will sure enhance it in the future, for now I only needed a specific protocol and ability to blend files and URLs. I don't want to enlarge the footprint, so ftp is not gonna make it :) Thanks, Oleg Benjamin [0] http://www.faqs.org/rfcs/rfc2396.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r726880 - in /maven/mercury/trunk: mercury-ant/mercury-ant-tasks/ mercury-ant/mercury-ant-tasks/src/main/java/org/apache/maven/mercury/ant/tasks/ mercury-ant/mercury-ant-tasks/src/main
Hi Oleg, Author: ogusakov Date: Mon Dec 15 16:04:14 2008 New Revision: 726880 URL: http://svn.apache.org/viewvc?rev=726880&view=rev Log: [MERCURY-56] verification configuration for mercury ant tasks done, PGP unit test works on osx. Need test keyrings for other platforms. Modified: maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java URL: http://svn.apache.org/viewvc/maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java?rev=726880&r1=726879&r2=726880&view=diff == --- maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java (original) +++ maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java Mon Dec 15 16:04:14 2008 @@ -593,35 +595,35 @@ public static void main( String[] args ) throws IOException, StreamObserverException { It looks odd for a utility class to have main() method. If it serves a production purpose, wouldn't it be better to move the main() out into a dedicated class, say in the default package with a descriptive name for easy invocation from CLI? If it's only for testing, src/main/java is definitively the wrong place. Likewise, RepositoryUpdateIntervalPolicy from the mercury-repo-api contains a main() method which pretty much looks like test code that should be deleted/moved out. //--- + public static InputStream toStream( String resource ) + throws MalformedURLException, IOException + { +if( Util.isEmpty( resource ) ) + return null; + +if( resource.startsWith( "file://" ) +|| resource.startsWith( "http://"; ) +) + return new URL(resource).openStream(); + +return new FileInputStream( new File(resource) ); + } RFC 2396 [0], section 3.1, "Scheme Component" suggests to treat upper case letters as equivalent to lower case in scheme names (e.g., allow "HTTP" as well as "http") Also, can you elaborate what motivates the selection of only "file://" and "http://"; as protocols? For instance, whereever HTTP is used the option of HTTPS isn't that far. FTP? Would it maybe better match your intention to just always call URL.openStream() and fallback to the FileInputStream in the case the former method threw an exception ("unknown protocol")? Benjamin [0] http://www.faqs.org/rfcs/rfc2396.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r726880 - in /maven/mercury/trunk: mercury-ant/mercury-ant-tasks/ mercury-ant/mercury-ant-tasks/src/main/java/org/apache/maven/mercury/ant/tasks/ mercury-ant/mercury-ant-tasks/src/main
Hi Oleg, Author: ogusakov Date: Mon Dec 15 16:04:14 2008 New Revision: 726880 URL: http://svn.apache.org/viewvc?rev=726880&view=rev Log: [MERCURY-56] verification configuration for mercury ant tasks done, PGP unit test works on osx. Need test keyrings for other platforms. [...] @@ -30,7 +40,7 @@ public class Config extends AbstractDataType { - private static final Language LANG = new DefaultLanguage( Config.class ); + private static final Language _lang = new DefaultLanguage( Config.class ); Collection _repos; @@ -178,6 +123,22 @@ String _authid; String _proxyauthid; +boolean _readable = true; +boolean _writeable = false; + +List _writeVerifiers; +List _readVerifiers; + +public void setReadable( boolean readable ) +{ + this._readable = readable; +} + + @@ -207,6 +168,135 @@ { return _dir != null; } + +public Verify createVerifywrite() +{ + if( _writeVerifiers == null ) +_writeVerifiers = new ArrayList(2); Please adopt our community conventions for Java code style [0, 1] which is usually as easy as importing the provided formatter configs into the IDE. A consistent formatting eases reading/reviewing the code and more importantly simplifies contributing/patching. Thanks Benjamin [0] http://maven.apache.org/developers/committer-environment.html#Maven_Code_Style [1] http://maven.apache.org/developers/conventions/code.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: This is for the general population but I'm nudging you Ralph because I know that you want to make some changes for not requiring the version in the parent element. You should have warned me to have a glass of wine before attempting to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of use who haven't had a math class in the last 25 years. The funny thing is, I have a B.S. in Physics. Man it has been a long time. :-( Comments: 1.1 Mentions there are 465 model properties. An appendix should list them. Specifically, I'd like to see "provides" listed along with the project's groupId, artifactId and version and "requires" in the dependency declaration - or whatever other way that kind of metadata will be added. 2.1 & 2.2 Is all this simply stating that the closest definition wins and when two or more are equally close then the first one wins? 2.4 The only "definition" of mixin is "The only difference between a parent pro ject and a mixin is that the mixin is abstract (not a complete model)". That sure leaves a lot to the imagination. And what exactly makes a model "incomplete"? Isn't a pom with just a dependencyManagement complete? I also found myself wondering that even though it might be possible to support extending multiple parents, should we? I could see allowing only one parent but multiple mixins. 3.1 Even though may be obvious, it should explicitly state that artifactId is always required. 3.4 Why can't the groupId be inherited from its parent (or at least be set from project.parent.groupIdt)? 3.4 The footnote says the artifactId can be inherited from the parent. That makes no sense to me. Every pom should represent a unique artifact or at least a unique pom. 3.5 I found the statement This will mark the container as final, thus preventing inheritance:" as misleading. In java terms this would mean a child pom attempting to define the same plugin would fail. The setting of "inherited" to false in the sample indicates to me the opposite, the plugin definition in the parent is invisible to the child. Here is a question though. If A overrides a plugin defined in the super pom and has inherited true, then B extends A and overrides the plugin and sets inherited to false, what will C which extends from B get? It should see the definition in A. Or does this whole section mean that the plugin definition in B inherits nothing from A? 3.8 "the element will be inherited." Unless the parent definition has false ? I don't see anything in here about being able to locate a parent without having to know its version. Within the scope of the purpose of this document it may not be relevant, but at the very least somewhere in section 3 it should state that if a parent is specified than which elements are required. I hope this was the kind of feedback you were looking for. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: external components was: svn commit: r726521
On Dec 15, 2008, at 7:41 AM, Jason van Zyl wrote: Also in the course of 6 months of development of the model-builder we have not had a single contribution from anyone else. Zero interest. So yes, it is easier to release elsewhere and that has allowed me to patch, test, release in rapid succession to try and get the alpha-1 to the point of release. I wouldn't say "zero interest". I simply have found it impossible to keep up with all the svn commits in all the various branches. Furthermore, a lot of stuff was being worked on in somewhat private branches. Unless they ask for collaboration I'm not going to go review stuff in someone's private sandbox until they call out and say it is ready for review before merging. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org