Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?
I like to consider a G:A as being substitutable along the V access... if you change the artifact so that it is not substitutable, then you really need to change the G:A part. Now substitutable does not mean no breaking API changes... it does mean that the package name and at least some of the class names are the same. So a good case in point here is Jackson the JSON serialization library... There are many versions of Jackson, but when a major breaking change to the API was required Tatu changed from org.codehaus.jackson:jackson-core-asl to com.fasterxml.jackson.core:jackson-core and also changed the package name of the classes. This was the correct thing to do, IMHO. They maintained 82 releases of the API without having to refactor in a breaking way. The changes that they needed would break the API, leaving no way for existing code to inter-op As a result, by changing package name and G:A the two versions can co-exist... Now let us consider some other ways that Tatu Co could have handled this: * They could have kept the package name the same and changed the G:A. That would mean that classes in the package name would not be coming from the same jar file, and so with a security manager enabled the same jar origin policy would mean that at run time you end up getting class conflicts all over the place as different classloaders resolve the package name from different jar files depending on which class they reference first and the order of the jars in the classpath... sounds a lot like hell... let's scrap that plan * They could have changed the package name and kept the G:A. That would mean that any fool* using version ranges could now find that their code fails to compile. (*only a fool uses version ranges)... that is self inflicted hell... also dependencyManagement will overrule versions so if somebody uses a dependencyManagement to force a version that will force a single version even though the classpath *should* have two versions... plus how Maven resolves the dependency tree means that it assumes that for any G:A varying the V gives you substitutable artifacts (and if they don't work then either `compile` or `test/verify` will fail the build so that's ok) So the rule of thumb I use is: * every time you change the package name, change the G:A * if you are making breaking API changes that are not substitutable, change the package name # aside Is there a use case for dependencies of the same GA but different V? I think there may be, at least when dealing with non-java resources... and Java 9 / OSGi provides a use case also. For example, you may have a legitimate (if crappy) reason to include two versions of jQuery in your web application... one set of pages may use the older one during a transition for example. So in modelVersion 5.0.0, I do think that we should investigate a means of flagging that certain types of dependency collection require a single unique version resolved for each GA dependency, while other types of dependency collection require the set of versions for each GA dependency On 14 January 2014 00:24, KARR, DAVID dk0...@att.com wrote: I have a situation where it would be convenient for my pom to have two dependencies that are almost identical, only being different by the version. The makeup of the artifact is such that it would be safe (and intended) to use both of them. The Java package used in each is similar, but different. The package will vary along with the version number. Will dependency resolution and the EAR plugin (and any other mechanism that lists dependencies) have any trouble with this? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New logo?
As a homage to Roy's wife, may I present maven-18: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1modificationDate=1389695623134api=v2 On 13 January 2014 15:36, Lyons, Roy roy.ly...@cmegroup.com wrote: I asked my wife on the drive to the train today what animal she thinks fits Maven. Her response made me chuckle. Without hesitation, she said Honey Badger When I asked why, she said that Honey Badgers are part of nature and generally do their thing nicely -- but if you piss it off, things will get really really bad... She said she had the same experience with Maven. It works nicely, but if you try to do something really non-standard, you will feel its wrath :) Heh. Anyhow, I thought it was funny enough to share - not really a serious consideration to make a Honey Badger our mascot. On 1/10/14 1:20 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think the association-work around what maven /is/ is a great way to approach a logo contest elsewhere. I have worked with some great graphic designers in my time, and the kind input the good ones want are typically related around your thoughts/feelings around the product rather than which particular animal you prefer, which is a bit of a secondary kind of input along with all different kinds of other constraints/ideas (the boss prefers blue). When I first encountered maven I had come to the realization that all my ant projects were basically the same, and that there was no reason for customizing what was basically a standard process. So maven gives me associations to a mass-production line at a factory, rather than a tailor making individual processes. Furthermore, the lifecycle amplifies the idea of a conveyor-belt mass-production line; all parts move through the same conveyor belt process, stopping at individual stages to get work done. I would almost be willing to think of a waterfall (Uh-oh...) So it would appear to me that I'm not thinking of an animal at all ! Kristian 2014/1/9 Mark H. Wood mw...@iupui.edu On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote: All of the logos are OK, but none of them really symbolize anything in particular about Maven. IMO the best logos encapsulate the purpose of the project somehow, either overtly, covertly or both. Good point. I was associating with the name Maven, looking for a symbol of in-depth understanding of a specialized field. http://en.wiktionary.org/wiki/maven So, what does Maven do? It passes unique source and object code inputs through a standardized process, guided by an expression of the relationships among those inputs, to assemble a well-specified configuration of runnable code. What does that look like? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New logo?
My wife had a suggestion... why not make the M in maven out of two tee pees... linking in with the Apache theme... So I present maven-19: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1modificationDate=1389695638903api=v2 and finding a use for the feather maven-20: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1modificationDate=1389695654233api=v2 On 14 January 2014 10:35, Stephen Connolly stephen.alan.conno...@gmail.comwrote: As a homage to Roy's wife, may I present maven-18: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1modificationDate=1389695623134api=v2 On 13 January 2014 15:36, Lyons, Roy roy.ly...@cmegroup.com wrote: I asked my wife on the drive to the train today what animal she thinks fits Maven. Her response made me chuckle. Without hesitation, she said Honey Badger When I asked why, she said that Honey Badgers are part of nature and generally do their thing nicely -- but if you piss it off, things will get really really bad... She said she had the same experience with Maven. It works nicely, but if you try to do something really non-standard, you will feel its wrath :) Heh. Anyhow, I thought it was funny enough to share - not really a serious consideration to make a Honey Badger our mascot. On 1/10/14 1:20 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think the association-work around what maven /is/ is a great way to approach a logo contest elsewhere. I have worked with some great graphic designers in my time, and the kind input the good ones want are typically related around your thoughts/feelings around the product rather than which particular animal you prefer, which is a bit of a secondary kind of input along with all different kinds of other constraints/ideas (the boss prefers blue). When I first encountered maven I had come to the realization that all my ant projects were basically the same, and that there was no reason for customizing what was basically a standard process. So maven gives me associations to a mass-production line at a factory, rather than a tailor making individual processes. Furthermore, the lifecycle amplifies the idea of a conveyor-belt mass-production line; all parts move through the same conveyor belt process, stopping at individual stages to get work done. I would almost be willing to think of a waterfall (Uh-oh...) So it would appear to me that I'm not thinking of an animal at all ! Kristian 2014/1/9 Mark H. Wood mw...@iupui.edu On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote: All of the logos are OK, but none of them really symbolize anything in particular about Maven. IMO the best logos encapsulate the purpose of the project somehow, either overtly, covertly or both. Good point. I was associating with the name Maven, looking for a symbol of in-depth understanding of a specialized field. http://en.wiktionary.org/wiki/maven So, what does Maven do? It passes unique source and object code inputs through a standardized process, guided by an expression of the relationships among those inputs, to assemble a well-specified configuration of runnable code. What does that look like? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New logo?
FYI: ndeloof points out http://raven.rubyforge.org/ So I think any logo with a raven in it is well and truly dead in the water On 14 January 2014 10:37, Stephen Connolly stephen.alan.conno...@gmail.comwrote: My wife had a suggestion... why not make the M in maven out of two tee pees... linking in with the Apache theme... So I present maven-19: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1modificationDate=1389695638903api=v2 and finding a use for the feather maven-20: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1modificationDate=1389695654233api=v2 On 14 January 2014 10:35, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As a homage to Roy's wife, may I present maven-18: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1modificationDate=1389695623134api=v2 On 13 January 2014 15:36, Lyons, Roy roy.ly...@cmegroup.com wrote: I asked my wife on the drive to the train today what animal she thinks fits Maven. Her response made me chuckle. Without hesitation, she said Honey Badger When I asked why, she said that Honey Badgers are part of nature and generally do their thing nicely -- but if you piss it off, things will get really really bad... She said she had the same experience with Maven. It works nicely, but if you try to do something really non-standard, you will feel its wrath :) Heh. Anyhow, I thought it was funny enough to share - not really a serious consideration to make a Honey Badger our mascot. On 1/10/14 1:20 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think the association-work around what maven /is/ is a great way to approach a logo contest elsewhere. I have worked with some great graphic designers in my time, and the kind input the good ones want are typically related around your thoughts/feelings around the product rather than which particular animal you prefer, which is a bit of a secondary kind of input along with all different kinds of other constraints/ideas (the boss prefers blue). When I first encountered maven I had come to the realization that all my ant projects were basically the same, and that there was no reason for customizing what was basically a standard process. So maven gives me associations to a mass-production line at a factory, rather than a tailor making individual processes. Furthermore, the lifecycle amplifies the idea of a conveyor-belt mass-production line; all parts move through the same conveyor belt process, stopping at individual stages to get work done. I would almost be willing to think of a waterfall (Uh-oh...) So it would appear to me that I'm not thinking of an animal at all ! Kristian 2014/1/9 Mark H. Wood mw...@iupui.edu On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote: All of the logos are OK, but none of them really symbolize anything in particular about Maven. IMO the best logos encapsulate the purpose of the project somehow, either overtly, covertly or both. Good point. I was associating with the name Maven, looking for a symbol of in-depth understanding of a specialized field. http://en.wiktionary.org/wiki/maven So, what does Maven do? It passes unique source and object code inputs through a standardized process, guided by an expression of the relationships among those inputs, to assemble a well-specified configuration of runnable code. What does that look like? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New logo?
Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png On 14 January 2014 10:37, Stephen Connolly stephen.alan.conno...@gmail.comwrote: My wife had a suggestion... why not make the M in maven out of two tee pees... linking in with the Apache theme... So I present maven-19: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1modificationDate=1389695638903api=v2 and finding a use for the feather maven-20: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1modificationDate=1389695654233api=v2 On 14 January 2014 10:35, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As a homage to Roy's wife, may I present maven-18: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1modificationDate=1389695623134api=v2 On 13 January 2014 15:36, Lyons, Roy roy.ly...@cmegroup.com wrote: I asked my wife on the drive to the train today what animal she thinks fits Maven. Her response made me chuckle. Without hesitation, she said Honey Badger When I asked why, she said that Honey Badgers are part of nature and generally do their thing nicely -- but if you piss it off, things will get really really bad... She said she had the same experience with Maven. It works nicely, but if you try to do something really non-standard, you will feel its wrath :) Heh. Anyhow, I thought it was funny enough to share - not really a serious consideration to make a Honey Badger our mascot. On 1/10/14 1:20 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think the association-work around what maven /is/ is a great way to approach a logo contest elsewhere. I have worked with some great graphic designers in my time, and the kind input the good ones want are typically related around your thoughts/feelings around the product rather than which particular animal you prefer, which is a bit of a secondary kind of input along with all different kinds of other constraints/ideas (the boss prefers blue). When I first encountered maven I had come to the realization that all my ant projects were basically the same, and that there was no reason for customizing what was basically a standard process. So maven gives me associations to a mass-production line at a factory, rather than a tailor making individual processes. Furthermore, the lifecycle amplifies the idea of a conveyor-belt mass-production line; all parts move through the same conveyor belt process, stopping at individual stages to get work done. I would almost be willing to think of a waterfall (Uh-oh...) So it would appear to me that I'm not thinking of an animal at all ! Kristian 2014/1/9 Mark H. Wood mw...@iupui.edu On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote: All of the logos are OK, but none of them really symbolize anything in particular about Maven. IMO the best logos encapsulate the purpose of the project somehow, either overtly, covertly or both. Good point. I was associating with the name Maven, looking for a symbol of in-depth understanding of a specialized field. http://en.wiktionary.org/wiki/maven So, what does Maven do? It passes unique source and object code inputs through a standardized process, guided by an expression of the relationships among those inputs, to assemble a well-specified configuration of runnable code. What does that look like? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to include @inheritDoc from a dependent jar
Hi, We are building a maven site that will contain javadoc for our AppX api ( jar file). AppX depends on a few other jar files ( that we have built using maven) . One dependency jar contain an interface with javadoc and we have a class implementing it, in AppX. AppX has @inheritDoc in in the javadoc so we don't have to rewrite it. When I use the following under report plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.8.1/version /plugin But when I open up the javadoc for my Appx and look at the class implementing the interface there is no javadoc. What am I missing? Br, //mike
Re: New logo?
I thought a hand-drawn font using straight lines only might look good with the teepee maven-21: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-21.png?version=1modificationDate=1389701827196api=v2 On 14 January 2014 12:08, Stephen Connolly stephen.alan.conno...@gmail.comwrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png On 14 January 2014 10:37, Stephen Connolly stephen.alan.conno...@gmail.com wrote: My wife had a suggestion... why not make the M in maven out of two tee pees... linking in with the Apache theme... So I present maven-19: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1modificationDate=1389695638903api=v2 and finding a use for the feather maven-20: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1modificationDate=1389695654233api=v2 On 14 January 2014 10:35, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As a homage to Roy's wife, may I present maven-18: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1modificationDate=1389695623134api=v2 On 13 January 2014 15:36, Lyons, Roy roy.ly...@cmegroup.com wrote: I asked my wife on the drive to the train today what animal she thinks fits Maven. Her response made me chuckle. Without hesitation, she said Honey Badger When I asked why, she said that Honey Badgers are part of nature and generally do their thing nicely -- but if you piss it off, things will get really really bad... She said she had the same experience with Maven. It works nicely, but if you try to do something really non-standard, you will feel its wrath :) Heh. Anyhow, I thought it was funny enough to share - not really a serious consideration to make a Honey Badger our mascot. On 1/10/14 1:20 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think the association-work around what maven /is/ is a great way to approach a logo contest elsewhere. I have worked with some great graphic designers in my time, and the kind input the good ones want are typically related around your thoughts/feelings around the product rather than which particular animal you prefer, which is a bit of a secondary kind of input along with all different kinds of other constraints/ideas (the boss prefers blue). When I first encountered maven I had come to the realization that all my ant projects were basically the same, and that there was no reason for customizing what was basically a standard process. So maven gives me associations to a mass-production line at a factory, rather than a tailor making individual processes. Furthermore, the lifecycle amplifies the idea of a conveyor-belt mass-production line; all parts move through the same conveyor belt process, stopping at individual stages to get work done. I would almost be willing to think of a waterfall (Uh-oh...) So it would appear to me that I'm not thinking of an animal at all ! Kristian 2014/1/9 Mark H. Wood mw...@iupui.edu On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote: All of the logos are OK, but none of them really symbolize anything in particular about Maven. IMO the best logos encapsulate the purpose of the project somehow, either overtly, covertly or both. Good point. I was associating with the name Maven, looking for a symbol of in-depth understanding of a specialized field. http://en.wiktionary.org/wiki/maven So, what does Maven do? It passes unique source and object code inputs through a standardized process, guided by an expression of the relationships among those inputs, to assemble a well-specified configuration of runnable code. What does that look like? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New logo?
That looks really nice (though I do have problems with any North American Indian references). cheers TimP On 14 January 2014 12:08, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png On 14 January 2014 10:37, Stephen Connolly stephen.alan.conno...@gmail.comwrote: My wife had a suggestion... why not make the M in maven out of two tee pees... linking in with the Apache theme... So I present maven-19: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1modificationDate=1389695638903api=v2 and finding a use for the feather maven-20: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1modificationDate=1389695654233api=v2 On 14 January 2014 10:35, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As a homage to Roy's wife, may I present maven-18: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1modificationDate=1389695623134api=v2 On 13 January 2014 15:36, Lyons, Roy roy.ly...@cmegroup.com wrote: I asked my wife on the drive to the train today what animal she thinks fits Maven. Her response made me chuckle. Without hesitation, she said Honey Badger When I asked why, she said that Honey Badgers are part of nature and generally do their thing nicely -- but if you piss it off, things will get really really bad... She said she had the same experience with Maven. It works nicely, but if you try to do something really non-standard, you will feel its wrath :) Heh. Anyhow, I thought it was funny enough to share - not really a serious consideration to make a Honey Badger our mascot. On 1/10/14 1:20 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think the association-work around what maven /is/ is a great way to approach a logo contest elsewhere. I have worked with some great graphic designers in my time, and the kind input the good ones want are typically related around your thoughts/feelings around the product rather than which particular animal you prefer, which is a bit of a secondary kind of input along with all different kinds of other constraints/ideas (the boss prefers blue). When I first encountered maven I had come to the realization that all my ant projects were basically the same, and that there was no reason for customizing what was basically a standard process. So maven gives me associations to a mass-production line at a factory, rather than a tailor making individual processes. Furthermore, the lifecycle amplifies the idea of a conveyor-belt mass-production line; all parts move through the same conveyor belt process, stopping at individual stages to get work done. I would almost be willing to think of a waterfall (Uh-oh...) So it would appear to me that I'm not thinking of an animal at all ! Kristian 2014/1/9 Mark H. Wood mw...@iupui.edu On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote: All of the logos are OK, but none of them really symbolize anything in particular about Maven. IMO the best logos encapsulate the purpose of the project somehow, either overtly, covertly or both. Good point. I was associating with the name Maven, looking for a symbol of in-depth understanding of a specialized field. http://en.wiktionary.org/wiki/maven So, what does Maven do? It passes unique source and object code inputs through a standardized process, guided by an expression of the relationships among those inputs, to assemble a well-specified configuration of runnable code. What does that look like? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Tim Pizey http://pizey.net/~timp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to include @inheritDoc from a dependent jar
From: mikael.petter...@ericsson.com To: users@maven.apache.org Subject: How to include @inheritDoc from a dependent jar Date: Tue, 14 Jan 2014 12:14:21 + Hi, We are building a maven site that will contain javadoc for our AppX api ( jar file). AppX depends on a few other jar files ( that we have built using maven) . One dependency jar contain an interface with javadoc and we have a class implementing it, in AppX. AppX has @inheritDoc in in the javadoc so we don't have to rewrite it. When I use the following under report plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.8.1/version /plugin But when I open up the javadoc for my Appx and look at the class implementing the interface there is no javadoc. What am I missing? MG@Inheritdoc pulls Javadoc comments @comment @author @param @throws @return from Implemented interface MGIf you have none of the Javadoc tags in the corresponding base method of implemented interface MGthen AppX class will not be able to 'inherit' those Javadoc attributes Br, //mike The longest journey is the the journey inwards..Of him who has chosen his dentiny..Who has started upon his quest for the source of his being Dag Hammarskjold
Re: New logo?
We are Apache Maven so there is always going to be that temptation to abuse the Apache link... I would like to hear more about your objections. Keep in mind that ultimately it will come down to a vote... I'm thinking we have two rounds of voting... the first round to select the top 3 and the second round to select the winner... WIth the above scheme I would plan on having a healthy discussion of the top 3 candidates in case any are deemed inappropriate, i.e. the PMC will reserve the right to veto any that it deems inappropriate, substituting with the next most popular. Then the winner will be an open vote from the 3 finalists... Or at least that is my plan So far we have about 8 ideas... * The moose with the internet in his hand * The owl * The assembly line * The honey badger * The two yurts in a native american style * The twin peaks * The fedora as an M (likely too close to redhat... so not counting for now) * A simple lettering with a monochrome feather * A stylized lettering with the feather as a y If we get to about 15-20 ideas and/or there seems to be a stop to the flow of new ideas, then I will probably call the first round of voting... On 14 January 2014 12:19, Tim Pizey t...@paneris.org wrote: That looks really nice (though I do have problems with any North American Indian references). cheers TimP On 14 January 2014 12:08, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png On 14 January 2014 10:37, Stephen Connolly stephen.alan.conno...@gmail.comwrote: My wife had a suggestion... why not make the M in maven out of two tee pees... linking in with the Apache theme... So I present maven-19: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1modificationDate=1389695638903api=v2 and finding a use for the feather maven-20: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1modificationDate=1389695654233api=v2 On 14 January 2014 10:35, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As a homage to Roy's wife, may I present maven-18: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1modificationDate=1389695623134api=v2 On 13 January 2014 15:36, Lyons, Roy roy.ly...@cmegroup.com wrote: I asked my wife on the drive to the train today what animal she thinks fits Maven. Her response made me chuckle. Without hesitation, she said Honey Badger When I asked why, she said that Honey Badgers are part of nature and generally do their thing nicely -- but if you piss it off, things will get really really bad... She said she had the same experience with Maven. It works nicely, but if you try to do something really non-standard, you will feel its wrath :) Heh. Anyhow, I thought it was funny enough to share - not really a serious consideration to make a Honey Badger our mascot. On 1/10/14 1:20 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think the association-work around what maven /is/ is a great way to approach a logo contest elsewhere. I have worked with some great graphic designers in my time, and the kind input the good ones want are typically related around your thoughts/feelings around the product rather than which particular animal you prefer, which is a bit of a secondary kind of input along with all different kinds of other constraints/ideas (the boss prefers blue). When I first encountered maven I had come to the realization that all my ant projects were basically the same, and that there was no reason for customizing what was basically a standard process. So maven gives me associations to a mass-production line at a factory, rather than a tailor making individual processes. Furthermore, the lifecycle amplifies the idea of a conveyor-belt mass-production line; all parts move through the same conveyor belt process, stopping at individual stages to get work done. I would almost be willing to think of a waterfall (Uh-oh...) So it would appear to me that I'm not thinking of an animal at all ! Kristian 2014/1/9 Mark H. Wood mw...@iupui.edu On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote: All of the logos are OK, but none of them really symbolize anything in particular about Maven. IMO the best logos encapsulate the purpose of the project somehow, either overtly, covertly or both. Good point. I was associating with the name Maven, looking for a symbol of in-depth understanding of a specialized field. http://en.wiktionary.org/wiki/maven So, what does Maven do? It passes unique source and object code inputs through a standardized process, guided by an expression
Re: New logo?
How about just using all of this + textual ideas as input for an external logo competiton ? Kristian 2014/1/14 Stephen Connolly stephen.alan.conno...@gmail.com We are Apache Maven so there is always going to be that temptation to abuse the Apache link... I would like to hear more about your objections. Keep in mind that ultimately it will come down to a vote... I'm thinking we have two rounds of voting... the first round to select the top 3 and the second round to select the winner... WIth the above scheme I would plan on having a healthy discussion of the top 3 candidates in case any are deemed inappropriate, i.e. the PMC will reserve the right to veto any that it deems inappropriate, substituting with the next most popular. Then the winner will be an open vote from the 3 finalists... Or at least that is my plan So far we have about 8 ideas... * The moose with the internet in his hand * The owl * The assembly line * The honey badger * The two yurts in a native american style * The twin peaks * The fedora as an M (likely too close to redhat... so not counting for now) * A simple lettering with a monochrome feather * A stylized lettering with the feather as a y If we get to about 15-20 ideas and/or there seems to be a stop to the flow of new ideas, then I will probably call the first round of voting... On 14 January 2014 12:19, Tim Pizey t...@paneris.org wrote: That looks really nice (though I do have problems with any North American Indian references). cheers TimP On 14 January 2014 12:08, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png On 14 January 2014 10:37, Stephen Connolly stephen.alan.conno...@gmail.comwrote: My wife had a suggestion... why not make the M in maven out of two tee pees... linking in with the Apache theme... So I present maven-19: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1modificationDate=1389695638903api=v2 and finding a use for the feather maven-20: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1modificationDate=1389695654233api=v2 On 14 January 2014 10:35, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As a homage to Roy's wife, may I present maven-18: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1modificationDate=1389695623134api=v2 On 13 January 2014 15:36, Lyons, Roy roy.ly...@cmegroup.com wrote: I asked my wife on the drive to the train today what animal she thinks fits Maven. Her response made me chuckle. Without hesitation, she said Honey Badger When I asked why, she said that Honey Badgers are part of nature and generally do their thing nicely -- but if you piss it off, things will get really really bad... She said she had the same experience with Maven. It works nicely, but if you try to do something really non-standard, you will feel its wrath :) Heh. Anyhow, I thought it was funny enough to share - not really a serious consideration to make a Honey Badger our mascot. On 1/10/14 1:20 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think the association-work around what maven /is/ is a great way to approach a logo contest elsewhere. I have worked with some great graphic designers in my time, and the kind input the good ones want are typically related around your thoughts/feelings around the product rather than which particular animal you prefer, which is a bit of a secondary kind of input along with all different kinds of other constraints/ideas (the boss prefers blue). When I first encountered maven I had come to the realization that all my ant projects were basically the same, and that there was no reason for customizing what was basically a standard process. So maven gives me associations to a mass-production line at a factory, rather than a tailor making individual processes. Furthermore, the lifecycle amplifies the idea of a conveyor-belt mass-production line; all parts move through the same conveyor belt process, stopping at individual stages to get work done. I would almost be willing to think of a waterfall (Uh-oh...) So it would appear to me that I'm not thinking of an animal at all ! Kristian 2014/1/9 Mark H. Wood mw...@iupui.edu On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote: All of the logos are OK, but none of them really symbolize anything in particular about Maven. IMO the best logos encapsulate the purpose of the project somehow, either overtly,
Re: New logo?
Does the Apache Foundation of any of its members have any money to engage a graphical designer? I was just thinking that after the voting, you could get a designer to do a proper job on the logo (perhaps producing some variations of the voted on design which could again be voted on further?). I do not mean any offence to everyone that submitted designs, but clearly we are not professional artists ;-) On 14 January 2014 12:40, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We are Apache Maven so there is always going to be that temptation to abuse the Apache link... I would like to hear more about your objections. Keep in mind that ultimately it will come down to a vote... I'm thinking we have two rounds of voting... the first round to select the top 3 and the second round to select the winner... WIth the above scheme I would plan on having a healthy discussion of the top 3 candidates in case any are deemed inappropriate, i.e. the PMC will reserve the right to veto any that it deems inappropriate, substituting with the next most popular. Then the winner will be an open vote from the 3 finalists... Or at least that is my plan So far we have about 8 ideas... * The moose with the internet in his hand * The owl * The assembly line * The honey badger * The two yurts in a native american style * The twin peaks * The fedora as an M (likely too close to redhat... so not counting for now) * A simple lettering with a monochrome feather * A stylized lettering with the feather as a y If we get to about 15-20 ideas and/or there seems to be a stop to the flow of new ideas, then I will probably call the first round of voting... On 14 January 2014 12:19, Tim Pizey t...@paneris.org wrote: That looks really nice (though I do have problems with any North American Indian references). cheers TimP On 14 January 2014 12:08, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png On 14 January 2014 10:37, Stephen Connolly stephen.alan.conno...@gmail.comwrote: My wife had a suggestion... why not make the M in maven out of two tee pees... linking in with the Apache theme... So I present maven-19: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1modificationDate=1389695638903api=v2 and finding a use for the feather maven-20: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1modificationDate=1389695654233api=v2 On 14 January 2014 10:35, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As a homage to Roy's wife, may I present maven-18: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1modificationDate=1389695623134api=v2 On 13 January 2014 15:36, Lyons, Roy roy.ly...@cmegroup.com wrote: I asked my wife on the drive to the train today what animal she thinks fits Maven. Her response made me chuckle. Without hesitation, she said Honey Badger When I asked why, she said that Honey Badgers are part of nature and generally do their thing nicely -- but if you piss it off, things will get really really bad... She said she had the same experience with Maven. It works nicely, but if you try to do something really non-standard, you will feel its wrath :) Heh. Anyhow, I thought it was funny enough to share - not really a serious consideration to make a Honey Badger our mascot. On 1/10/14 1:20 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think the association-work around what maven /is/ is a great way to approach a logo contest elsewhere. I have worked with some great graphic designers in my time, and the kind input the good ones want are typically related around your thoughts/feelings around the product rather than which particular animal you prefer, which is a bit of a secondary kind of input along with all different kinds of other constraints/ideas (the boss prefers blue). When I first encountered maven I had come to the realization that all my ant projects were basically the same, and that there was no reason for customizing what was basically a standard process. So maven gives me associations to a mass-production line at a factory, rather than a tailor making individual processes. Furthermore, the lifecycle amplifies the idea of a conveyor-belt mass-production line; all parts move through the same conveyor belt process, stopping at individual stages to get work done. I would almost be willing to think of a waterfall (Uh-oh...) So it would appear to me that I'm not thinking of an animal at all ! Kristian 2014/1/9 Mark H. Wood mw...@iupui.edu On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote: All of the
RE: How to include @inheritDoc from a dependent jar
Thanks for reply Martin. See my comments below.
Br,
//mike
-Original Message-
From: Martin Gainty [mailto:mgai...@hotmail.com]
Sent: den 14 januari 2014 13:27
To: users@maven.apache.org
Subject: RE: How to include @inheritDoc from a dependent jar
From: mikael.petter...@ericsson.com
To: users@maven.apache.org
Subject: How to include @inheritDoc from a dependent jar
Date: Tue, 14 Jan 2014 12:14:21 +
Hi,
We are building a maven site that will contain javadoc for our AppX api ( jar
file).
AppX depends on a few other jar files ( that we have built using maven) . One
dependency jar contain an interface with javadoc and we have a class
implementing it, in AppX.
AppX has @inheritDoc in in the javadoc so we don't have to rewrite it.
When I use the following under report
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.8.1/version
/plugin
But when I open up the javadoc for my Appx and look at the class implementing
the interface there is no javadoc. What am I missing?
MG@Inheritdoc pulls Javadoc comments @comment @author @param @throws
MG@return from Implemented interface If you have none of the Javadoc
MGtags in the corresponding base method of implemented interface then
MGAppX class will not be able to 'inherit' those Javadoc attributes
I have the following:
Interface in dependency jar javadoc:
/**
* Deletes the object found at the specified location.
*
* @param Object any type of object
* @throws InvalidObjectException lots of text
* @throws NoSuchObjectException lots of text
*/
public void delete (Object object)throws throws InvalidObjectException,
NoSuchObjectException;
Implementing class:
/**
* {@inheritDoc}
*/
@Override
public void delete(Object object) throws InvalidObjectException,
NoSuchObjectException {
//implementation of delete
}
Is this correct or? Since this will not produce any javadoc for
implementation of delete ( last code).
Br,
//mike
The longest journey is the the journey inwards..Of him who has chosen his
dentiny..Who has started upon his quest for the source of his being Dag
Hammarskjold
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: New logo?
I think we would have no issue getting a small amount of funding from the foundation to feed an external logo competition... but I think we would want to have some scope defined for such a competition... so yeah I see no issue with using the top 3 as seed for an external logo competition, e.g. on the site already mentioned on a previous thread... but I think we do need a spec and part of the point of this discussion is to generate such a spec. On 14 January 2014 12:45, Adam Retter adam.ret...@googlemail.com wrote: Does the Apache Foundation of any of its members have any money to engage a graphical designer? I was just thinking that after the voting, you could get a designer to do a proper job on the logo (perhaps producing some variations of the voted on design which could again be voted on further?). I do not mean any offence to everyone that submitted designs, but clearly we are not professional artists ;-) On 14 January 2014 12:40, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We are Apache Maven so there is always going to be that temptation to abuse the Apache link... I would like to hear more about your objections. Keep in mind that ultimately it will come down to a vote... I'm thinking we have two rounds of voting... the first round to select the top 3 and the second round to select the winner... WIth the above scheme I would plan on having a healthy discussion of the top 3 candidates in case any are deemed inappropriate, i.e. the PMC will reserve the right to veto any that it deems inappropriate, substituting with the next most popular. Then the winner will be an open vote from the 3 finalists... Or at least that is my plan So far we have about 8 ideas... * The moose with the internet in his hand * The owl * The assembly line * The honey badger * The two yurts in a native american style * The twin peaks * The fedora as an M (likely too close to redhat... so not counting for now) * A simple lettering with a monochrome feather * A stylized lettering with the feather as a y If we get to about 15-20 ideas and/or there seems to be a stop to the flow of new ideas, then I will probably call the first round of voting... On 14 January 2014 12:19, Tim Pizey t...@paneris.org wrote: That looks really nice (though I do have problems with any North American Indian references). cheers TimP On 14 January 2014 12:08, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png On 14 January 2014 10:37, Stephen Connolly stephen.alan.conno...@gmail.comwrote: My wife had a suggestion... why not make the M in maven out of two tee pees... linking in with the Apache theme... So I present maven-19: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1modificationDate=1389695638903api=v2 and finding a use for the feather maven-20: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1modificationDate=1389695654233api=v2 On 14 January 2014 10:35, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As a homage to Roy's wife, may I present maven-18: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1modificationDate=1389695623134api=v2 On 13 January 2014 15:36, Lyons, Roy roy.ly...@cmegroup.com wrote: I asked my wife on the drive to the train today what animal she thinks fits Maven. Her response made me chuckle. Without hesitation, she said Honey Badger When I asked why, she said that Honey Badgers are part of nature and generally do their thing nicely -- but if you piss it off, things will get really really bad... She said she had the same experience with Maven. It works nicely, but if you try to do something really non-standard, you will feel its wrath :) Heh. Anyhow, I thought it was funny enough to share - not really a serious consideration to make a Honey Badger our mascot. On 1/10/14 1:20 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think the association-work around what maven /is/ is a great way to approach a logo contest elsewhere. I have worked with some great graphic designers in my time, and the kind input the good ones want are typically related around your thoughts/feelings around the product rather than which particular animal you prefer, which is a bit of a secondary kind of input along with all different kinds of other constraints/ideas (the boss prefers blue). When I first encountered maven I had come to the realization that all my ant projects were basically the same, and that there was no reason for
Re: New logo?
maven-21 in context: http://people.apache.org/~stephenc/maven-logo-contest/maven-21-in-context.png On 14 January 2014 12:18, Stephen Connolly stephen.alan.conno...@gmail.comwrote: I thought a hand-drawn font using straight lines only might look good with the teepee maven-21: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-21.png?version=1modificationDate=1389701827196api=v2 On 14 January 2014 12:08, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png On 14 January 2014 10:37, Stephen Connolly stephen.alan.conno...@gmail.com wrote: My wife had a suggestion... why not make the M in maven out of two tee pees... linking in with the Apache theme... So I present maven-19: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1modificationDate=1389695638903api=v2 and finding a use for the feather maven-20: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1modificationDate=1389695654233api=v2 On 14 January 2014 10:35, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As a homage to Roy's wife, may I present maven-18: https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1modificationDate=1389695623134api=v2 On 13 January 2014 15:36, Lyons, Roy roy.ly...@cmegroup.com wrote: I asked my wife on the drive to the train today what animal she thinks fits Maven. Her response made me chuckle. Without hesitation, she said Honey Badger When I asked why, she said that Honey Badgers are part of nature and generally do their thing nicely -- but if you piss it off, things will get really really bad... She said she had the same experience with Maven. It works nicely, but if you try to do something really non-standard, you will feel its wrath :) Heh. Anyhow, I thought it was funny enough to share - not really a serious consideration to make a Honey Badger our mascot. On 1/10/14 1:20 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think the association-work around what maven /is/ is a great way to approach a logo contest elsewhere. I have worked with some great graphic designers in my time, and the kind input the good ones want are typically related around your thoughts/feelings around the product rather than which particular animal you prefer, which is a bit of a secondary kind of input along with all different kinds of other constraints/ideas (the boss prefers blue). When I first encountered maven I had come to the realization that all my ant projects were basically the same, and that there was no reason for customizing what was basically a standard process. So maven gives me associations to a mass-production line at a factory, rather than a tailor making individual processes. Furthermore, the lifecycle amplifies the idea of a conveyor-belt mass-production line; all parts move through the same conveyor belt process, stopping at individual stages to get work done. I would almost be willing to think of a waterfall (Uh-oh...) So it would appear to me that I'm not thinking of an animal at all ! Kristian 2014/1/9 Mark H. Wood mw...@iupui.edu On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote: All of the logos are OK, but none of them really symbolize anything in particular about Maven. IMO the best logos encapsulate the purpose of the project somehow, either overtly, covertly or both. Good point. I was associating with the name Maven, looking for a symbol of in-depth understanding of a specialized field. http://en.wiktionary.org/wiki/maven So, what does Maven do? It passes unique source and object code inputs through a standardized process, guided by an expression of the relationships among those inputs, to assemble a well-specified configuration of runnable code. What does that look like? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to include @inheritDoc from a dependent jar
Hi,
New try :-)
I have the following:
Interface in dependency jar javadoc:
/**
* Deletes the object found at the specified location.
*
* @param Object any type of object
* @throws InvalidObjectException lots of text
* @throws NoSuchObjectException lots of text
*/
public void delete (Object object)throws throws InvalidObjectException,
NoSuchObjectException;
Implementing class:
/**
* {@inheritDoc}
*/
@Override
public void delete(Object object) throws InvalidObjectException,
NoSuchObjectException {
//implementation of delete
}
Is this correct or? Since this will not produce any javadoc for
implementation of delete ( last code).
Br.
//mike
-Original Message-
From: Martin Gainty [mailto:mgai...@hotmail.com]
Sent: den 14 januari 2014 13:27
To: users@maven.apache.org
Subject: RE: How to include @inheritDoc from a dependent jar
From: mikael.petter...@ericsson.com
To: users@maven.apache.org
Subject: How to include @inheritDoc from a dependent jar
Date: Tue, 14 Jan 2014 12:14:21 +
Hi,
We are building a maven site that will contain javadoc for our AppX api ( jar
file).
AppX depends on a few other jar files ( that we have built using maven) . One
dependency jar contain an interface with javadoc and we have a class
implementing it, in AppX.
AppX has @inheritDoc in in the javadoc so we don't have to rewrite it.
When I use the following under report
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.8.1/version
/plugin
But when I open up the javadoc for my Appx and look at the class implementing
the interface there is no javadoc. What am I missing?
MG@Inheritdoc pulls Javadoc comments @comment @author @param @throws
MG@return from Implemented interface If you have none of the Javadoc
MGtags in the corresponding base method of implemented interface then
MGAppX class will not be able to 'inherit' those Javadoc attributes
Br,
//mike
The longest journey is the the journey inwards..Of him who has chosen his
dentiny..Who has started upon his quest for the source of his being Dag
Hammarskjold
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: During plugin development, what is the context classloader set to?
Hi,
ClassWorlds is your friend if you need to do classloader fine-tuning.
For example (taken in an old poc, so this should be adapted to use
annotations etc.), something along the following would create a classpath
with test scope elements.
...
public class SomeMojo extends AbstractMojo
{
/**
* @parameter expression=${project.testClasspathElements}
*/
private
Listhttp://www.google.com/search?sitesearch=java.sun.comq=allinurl%3Aj2se%2F1+5+0%2Fdocs%2Fapi+List
String http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html
testProjectArtifacts;
...
protected
ClassLoaderhttp://java.sun.com/j2se/1.5.0/docs/api/java/lang/ClassLoader.html
getClassLoader()
{
try
{
ClassWorld world = new ClassWorld();
ClassRealm realm = world.newRealm(project);
for
(Stringhttp://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html
artifact
: testProjectArtifacts)
{
getLog().debug(Constituent : + artifact);
realm.addConstituent(new
Filehttp://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html
(artifact).toURL());
}
return realm.getClassLoader();
}
catch
(Exceptionhttp://java.sun.com/j2se/1.5.0/docs/api/java/lang/Exception.html
e)
{
throw new
RuntimeExceptionhttp://java.sun.com/j2se/1.5.0/docs/api/java/lang/RuntimeException.html
(WTF, e);
}
}
HTH
2014/1/8 Laird Nelson ljnel...@gmail.com
I have a plugin that I'm writing that needs to do two things during the
course of its execution:
Load a resource from the current project's classpath
Load a resource from its own guts
This is a fallback kind of thing: if the plugin can't find anything
appropriate on the project classpath, then and only then do I want it to
examine its own .jar file for the resource in question.
My hunch is that there are probably already two classloaders set up for
just this purpose.
I am guessing (haven't tried yet) that the project classpath is probably
visible to Thread.currentThread().getContextClassLoader(). Is that right?
I'm also guessing (haven't tried yet) that from within my mojo
this.getClass().getClassLoader() will return me a ClassLoader that is set
up to be able to see my mojo's innards. Is that right?
Best,
Laird
--
http://about.me/lairdnelson
--
Baptiste Batmat MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor ! nbsp;! http://about.me/lairdnelson
Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed
Hi, Stephen already answered along those lines. What are you missing? Cheers 2014/1/9 S. Ali Tokmen nos...@alishomepage.com Hi Anders Thanks for your reply - and happy new year :) Is there any way I can inject / read the whole plugin configuration from the plugin? Best regards S. Ali Tokmen http://ali.tokmen.com/ My IM, GSM, PGP and other contact details are on http://contact.ali.tokmen.com On 08/01/14 20:00, Anders Hammar wrote: AFAIK there is no support for this. If you think there should be, please file a ticket [1]. /Anders [1] http://jira.codehaus.org/browse/MNG/ On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen nos...@alishomepage.com wrote: Dear Maven users I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3 plugin; and would have a question with regards to how parameters are managed. We defined our MOJOs with parameters (you can see http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java for example), but what happens is that if a user unwillingly puts a parameter in the wrong place then the plugin execution doesn't stop. As an example, I can write the below POM and build still works (even thought the MOJO has no parameter called foo): plugin groupIdorg.codehaus.cargo/groupId artifactIdcargo-maven2-plugin/artifactId version1.4.6/version configuration foo bar /foo /configuration /plugin Is there any way I can instruct by MOJO to fail if there is an unknown parameter? Please advise Thank you -- S. Ali Tokmen http://ali.tokmen.com/ My IM, GSM, PGP and other contact details are on http://contact.ali.tokmen.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! users-h...@maven.apache.org
Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed
Isn't that simply because the configuration is shared by all goals? (or all goals of the parent execution) On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen nos...@alishomepage.comwrote: Dear Maven users I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3 plugin; and would have a question with regards to how parameters are managed. We defined our MOJOs with parameters (you can see http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java for example), but what happens is that if a user unwillingly puts a parameter in the wrong place then the plugin execution doesn't stop. As an example, I can write the below POM and build still works (even thought the MOJO has no parameter called foo): plugin groupIdorg.codehaus.cargo/groupId artifactIdcargo-maven2-plugin/artifactId version1.4.6/version configuration foo bar /foo /configuration /plugin Is there any way I can instruct by MOJO to fail if there is an unknown parameter? Please advise Thank you -- S. Ali Tokmen http://ali.tokmen.com/ My IM, GSM, PGP and other contact details are on http://contact.ali.tokmen.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/
RE: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?
-Original Message- From: Barrie Treloar [mailto:baerr...@gmail.com] Sent: Monday, January 13, 2014 4:48 PM To: Maven Users List Subject: Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version? On 14 January 2014 10:54, KARR, DAVID dk0...@att.com wrote: I have a situation where it would be convenient for my pom to have two dependencies that are almost identical, only being different by the version. The makeup of the artifact is such that it would be safe (and intended) to use both of them. The Java package used in each is similar, but different. The package will vary along with the version number. Will dependency resolution and the EAR plugin (and any other mechanism that lists dependencies) have any trouble with this? Can you describe why you think this would be convenient? Have you looked at classifiers? http://stackoverflow.com/questions/8040964/how-to-use-or-abuse-artifact- classifiers-in-maven A new version of this artifact is produced perhaps once a month. Perhaps 2-3 versions of this artifact will be referenced in the client code base at one time. More versions than that are supported in the server code base, throughout all environments. The only difference in the reported name of this artifact from one version to the next is the version number. Again, I didn't want to debate whether this is convenient, I just wanted to know if Maven dependency resolution and things like the EAR plugin will have any trouble incorporating multiple dependencies with the same G:A, but different version. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?
Hi David, Again, I didn't want to debate whether this is convenient, I just wanted to know if Maven dependency resolution and things like the EAR plugin will have any trouble incorporating multiple dependencies with the same G:A, but different version. I haven't tried it, but personally I would be shocked if Maven allowed this at all. Did you try it? Does it work? IMO, the major reason for versions is so that Maven (and humans) knows to select one from a set. If you need more than one at the same time, change the value of A. Including multiple versions of the same artifact violates Maven's current assumptions rather severely. Regards, Curtis On Tue, Jan 14, 2014 at 9:10 AM, KARR, DAVID dk0...@att.com wrote: -Original Message- From: Barrie Treloar [mailto:baerr...@gmail.com] Sent: Monday, January 13, 2014 4:48 PM To: Maven Users List Subject: Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version? On 14 January 2014 10:54, KARR, DAVID dk0...@att.com wrote: I have a situation where it would be convenient for my pom to have two dependencies that are almost identical, only being different by the version. The makeup of the artifact is such that it would be safe (and intended) to use both of them. The Java package used in each is similar, but different. The package will vary along with the version number. Will dependency resolution and the EAR plugin (and any other mechanism that lists dependencies) have any trouble with this? Can you describe why you think this would be convenient? Have you looked at classifiers? http://stackoverflow.com/questions/8040964/how-to-use-or-abuse-artifact- classifiers-in-maven A new version of this artifact is produced perhaps once a month. Perhaps 2-3 versions of this artifact will be referenced in the client code base at one time. More versions than that are supported in the server code base, throughout all environments. The only difference in the reported name of this artifact from one version to the next is the version number. Again, I didn't want to debate whether this is convenient, I just wanted to know if Maven dependency resolution and things like the EAR plugin will have any trouble incorporating multiple dependencies with the same G:A, but different version. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New logo?
On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png *Very* nice work, but...what does this Native Americans theme have to do with maven? Yes, I know, but people *will* ask. Especially since the answer has no connection with what Maven would do for them. Unless I'm mistaken, the Maven landing page exists to sell Maven, not the Apache Software Foundation. A link to the Foundation's landing page is quite appropriate and should be easy to find, but that's not why people come to this page. They come because they've heard something about Maven and want to know more, or Google gave them a link when they asked something about software project management or build tools, or because some other project had a built with Maven link on its page and they're curious. They'll probably be best pleased if, at a glance, they can get some notion of what Maven does. Possibly that message simply isn't very visual, and the best one can do is to select a (formerly) meaningless but unique mascot or abstract symbol. Possibly there is an image that will make people think, yes! that is Maven in action. I'm really not that sort of visual thinker, but images of structure, assembly, or gathering seem appropriate. The best(?) I've been able to imagine is a funnel with classes falling in and a package falling out. Or perhaps an assembly line. (What do classes look like? beats me.) Maybe you can do something with the Reactor: skinny pipes bring things in, one big pipe lets the product out. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
Re: New logo?
Love this logo. Very awesome. On Tue, Jan 14, 2014 at 9:51 AM, Mark H. Wood mw...@iupui.edu wrote: On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png *Very* nice work, but...what does this Native Americans theme have to do with maven? Yes, I know, but people *will* ask. Especially since the answer has no connection with what Maven would do for them. Unless I'm mistaken, the Maven landing page exists to sell Maven, not the Apache Software Foundation. A link to the Foundation's landing page is quite appropriate and should be easy to find, but that's not why people come to this page. They come because they've heard something about Maven and want to know more, or Google gave them a link when they asked something about software project management or build tools, or because some other project had a built with Maven link on its page and they're curious. They'll probably be best pleased if, at a glance, they can get some notion of what Maven does. Possibly that message simply isn't very visual, and the best one can do is to select a (formerly) meaningless but unique mascot or abstract symbol. Possibly there is an image that will make people think, yes! that is Maven in action. I'm really not that sort of visual thinker, but images of structure, assembly, or gathering seem appropriate. The best(?) I've been able to imagine is a funnel with classes falling in and a package falling out. Or perhaps an assembly line. (What do classes look like? beats me.) Maybe you can do something with the Reactor: skinny pipes bring things in, one big pipe lets the product out. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. -- Cheers, Paul
Re: New logo?
On 14 January 2014 15:51, Mark H. Wood mw...@iupui.edu wrote: On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png *Very* nice work, but...what does this Native Americans theme have to do with maven? Yes, I know, but people *will* ask. Especially since the answer has no connection with what Maven would do for them. Unless I'm mistaken, the Maven landing page exists to sell Maven, not the Apache Software Foundation. A link to the Foundation's landing page is quite appropriate and should be easy to find, but that's not why people come to this page. They come because they've heard something about Maven and want to know more, or Google gave them a link when they asked something about software project management or build tools, or because some other project had a built with Maven link on its page and they're curious. They'll probably be best pleased if, at a glance, they can get some notion of what Maven does. Possibly that message simply isn't very visual, and the best one can do is to select a (formerly) meaningless but unique mascot or abstract symbol. Possibly there is an image that will make people think, yes! that is Maven in action. The best I have come up with for an image as to what Maven does is https://cwiki.apache.org/confluence/display/MAVEN/Tutorial%3A+Maven+in+60+seconds But that does not a good logo make. Our current logo is just the word maven with the 'a' in orange At least this version, or maven-21 includes the Apache feather... and hints at us being an Apache project... I'm really not that sort of visual thinker, but images of structure, assembly, or gathering seem appropriate. The best(?) I've been able to imagine is a funnel with classes falling in and a package falling out. Or perhaps an assembly line. (What do classes look like? beats me.) Maybe you can do something with the Reactor: skinny pipes bring things in, one big pipe lets the product out. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
Re: New logo?
On Tue, Jan 14, 2014 at 12:45:18PM +, Adam Retter wrote: Does the Apache Foundation of any of its members have any money to engage a graphical designer? I was just thinking that after the voting, you could get a designer to do a proper job on the logo (perhaps producing some variations of the voted on design which could again be voted on further?). I do not mean any offence to everyone that submitted designs, but clearly we are not professional artists ;-) Actually I think the artwork is quite good. It's the visual language itself that seems uncertain. Which points even more strongly to the need for a graphic designer. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
Re: New logo?
maven-22: uses some of the imagery from the 60-seconds tutorial to form the logo https://cwiki.apache.org/confluence/download/attachments/38569278/maven-22.png?version=1modificationDate=1389716094692api=v2 On 14 January 2014 15:55, Stephen Connolly stephen.alan.conno...@gmail.comwrote: On 14 January 2014 15:51, Mark H. Wood mw...@iupui.edu wrote: On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png *Very* nice work, but...what does this Native Americans theme have to do with maven? Yes, I know, but people *will* ask. Especially since the answer has no connection with what Maven would do for them. Unless I'm mistaken, the Maven landing page exists to sell Maven, not the Apache Software Foundation. A link to the Foundation's landing page is quite appropriate and should be easy to find, but that's not why people come to this page. They come because they've heard something about Maven and want to know more, or Google gave them a link when they asked something about software project management or build tools, or because some other project had a built with Maven link on its page and they're curious. They'll probably be best pleased if, at a glance, they can get some notion of what Maven does. Possibly that message simply isn't very visual, and the best one can do is to select a (formerly) meaningless but unique mascot or abstract symbol. Possibly there is an image that will make people think, yes! that is Maven in action. The best I have come up with for an image as to what Maven does is https://cwiki.apache.org/confluence/display/MAVEN/Tutorial%3A+Maven+in+60+seconds But that does not a good logo make. Our current logo is just the word maven with the 'a' in orange At least this version, or maven-21 includes the Apache feather... and hints at us being an Apache project... I'm really not that sort of visual thinker, but images of structure, assembly, or gathering seem appropriate. The best(?) I've been able to imagine is a funnel with classes falling in and a package falling out. Or perhaps an assembly line. (What do classes look like? beats me.) Maybe you can do something with the Reactor: skinny pipes bring things in, one big pipe lets the product out. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
Re: New logo?
Maven is like a village made from tents... you can move from location to location (project to project) and you bring all the same tents (phases / conventions as to how to build a project) with you. Because we are an Apache project we chose a tent that is keeping with the stylings of the Apache feather logo There's a post-hoc justification for you ;-) On 14 January 2014 15:51, Mark H. Wood mw...@iupui.edu wrote: On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png *Very* nice work, but...what does this Native Americans theme have to do with maven? Yes, I know, but people *will* ask. Especially since the answer has no connection with what Maven would do for them. Unless I'm mistaken, the Maven landing page exists to sell Maven, not the Apache Software Foundation. A link to the Foundation's landing page is quite appropriate and should be easy to find, but that's not why people come to this page. They come because they've heard something about Maven and want to know more, or Google gave them a link when they asked something about software project management or build tools, or because some other project had a built with Maven link on its page and they're curious. They'll probably be best pleased if, at a glance, they can get some notion of what Maven does. Possibly that message simply isn't very visual, and the best one can do is to select a (formerly) meaningless but unique mascot or abstract symbol. Possibly there is an image that will make people think, yes! that is Maven in action. I'm really not that sort of visual thinker, but images of structure, assembly, or gathering seem appropriate. The best(?) I've been able to imagine is a funnel with classes falling in and a package falling out. Or perhaps an assembly line. (What do classes look like? beats me.) Maybe you can do something with the Reactor: skinny pipes bring things in, one big pipe lets the product out. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
Re: New logo?
And if you are not a nomadic developer (who jumps from project to project) then a lot of the benefits of Maven will seem to get in your way... once you are moving from project to project, knowing that you always have the `deploy` tent to push the results of your build to the remote repository is a good thing™ On 14 January 2014 16:30, Stephen Connolly stephen.alan.conno...@gmail.comwrote: Maven is like a village made from tents... you can move from location to location (project to project) and you bring all the same tents (phases / conventions as to how to build a project) with you. Because we are an Apache project we chose a tent that is keeping with the stylings of the Apache feather logo There's a post-hoc justification for you ;-) On 14 January 2014 15:51, Mark H. Wood mw...@iupui.edu wrote: On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png *Very* nice work, but...what does this Native Americans theme have to do with maven? Yes, I know, but people *will* ask. Especially since the answer has no connection with what Maven would do for them. Unless I'm mistaken, the Maven landing page exists to sell Maven, not the Apache Software Foundation. A link to the Foundation's landing page is quite appropriate and should be easy to find, but that's not why people come to this page. They come because they've heard something about Maven and want to know more, or Google gave them a link when they asked something about software project management or build tools, or because some other project had a built with Maven link on its page and they're curious. They'll probably be best pleased if, at a glance, they can get some notion of what Maven does. Possibly that message simply isn't very visual, and the best one can do is to select a (formerly) meaningless but unique mascot or abstract symbol. Possibly there is an image that will make people think, yes! that is Maven in action. I'm really not that sort of visual thinker, but images of structure, assembly, or gathering seem appropriate. The best(?) I've been able to imagine is a funnel with classes falling in and a package falling out. Or perhaps an assembly line. (What do classes look like? beats me.) Maybe you can do something with the Reactor: skinny pipes bring things in, one big pipe lets the product out. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed
Hi Baptiste, Thomas I guess you all got a point :) The reason why I want to check the configuration is indeed something that would have to be done in each goal. My remaining question would be whether there is a way to read the configuration XML definition from the MOJO - I could then manually implement such a verification in the different MOJOs. Please advise Thank you S. Ali Tokmen http://ali.tokmen.com/ My IM, GSM, PGP and other contact details are on http://contact.ali.tokmen.com On 14/01/14 14:24, Baptiste Mathus wrote: Hi, Stephen already answered along those lines. What are you missing? Cheers 2014/1/9 S. Ali Tokmen nos...@alishomepage.com Hi Anders Thanks for your reply - and happy new year :) Is there any way I can inject / read the whole plugin configuration from the plugin? Best regards S. Ali Tokmen http://ali.tokmen.com/ My IM, GSM, PGP and other contact details are on http://contact.ali.tokmen.com On 08/01/14 20:00, Anders Hammar wrote: AFAIK there is no support for this. If you think there should be, please file a ticket [1]. /Anders [1] http://jira.codehaus.org/browse/MNG/ On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen nos...@alishomepage.com wrote: Dear Maven users I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3 plugin; and would have a question with regards to how parameters are managed. We defined our MOJOs with parameters (you can see http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java for example), but what happens is that if a user unwillingly puts a parameter in the wrong place then the plugin execution doesn't stop. As an example, I can write the below POM and build still works (even thought the MOJO has no parameter called foo): plugin groupIdorg.codehaus.cargo/groupId artifactIdcargo-maven2-plugin/artifactId version1.4.6/version configuration foo bar /foo /configuration /plugin Is there any way I can instruct by MOJO to fail if there is an unknown parameter? Please advise Thank you -- S. Ali Tokmen http://ali.tokmen.com/ My IM, GSM, PGP and other contact details are on http://contact.ali.tokmen.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: New logo?
Stephen, Can you add the following two images to the contest entries? http://s9.postimg.org/ubyk4kczj/maven6.png http://s8.postimg.org/jdcbco351/maven5.png -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, January 14, 2014 11:33 AM To: Maven Users List Subject: Re: New logo? And if you are not a nomadic developer (who jumps from project to project) then a lot of the benefits of Maven will seem to get in your way... once you are moving from project to project, knowing that you always have the `deploy` tent to push the results of your build to the remote repository is a good thingT On 14 January 2014 16:30, Stephen Connolly stephen.alan.conno...@gmail.comwrote: Maven is like a village made from tents... you can move from location to location (project to project) and you bring all the same tents (phases / conventions as to how to build a project) with you. Because we are an Apache project we chose a tent that is keeping with the stylings of the Apache feather logo There's a post-hoc justification for you ;-) On 14 January 2014 15:51, Mark H. Wood mw...@iupui.edu wrote: On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote: Putting maven-20 in context, you get: http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-con text.png *Very* nice work, but...what does this Native Americans theme have to do with maven? Yes, I know, but people *will* ask. Especially since the answer has no connection with what Maven would do for them. Unless I'm mistaken, the Maven landing page exists to sell Maven, not the Apache Software Foundation. A link to the Foundation's landing page is quite appropriate and should be easy to find, but that's not why people come to this page. They come because they've heard something about Maven and want to know more, or Google gave them a link when they asked something about software project management or build tools, or because some other project had a built with Maven link on its page and they're curious. They'll probably be best pleased if, at a glance, they can get some notion of what Maven does. Possibly that message simply isn't very visual, and the best one can do is to select a (formerly) meaningless but unique mascot or abstract symbol. Possibly there is an image that will make people think, yes! that is Maven in action. I'm really not that sort of visual thinker, but images of structure, assembly, or gathering seem appropriate. The best(?) I've been able to imagine is a funnel with classes falling in and a package falling out. Or perhaps an assembly line. (What do classes look like? beats me.) Maybe you can do something with the Reactor: skinny pipes bring things in, one big pipe lets the product out. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: New logo?
Like this? http://s8.postimg.org/jdcbco351/maven5.png -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Monday, January 13, 2014 6:32 PM To: Maven Users List Subject: Re: New logo? Great logo, but yes, an orange hat too similar to red hat. If we're using an Apache feather, maybe we can use a Cowboy hat to complete the theme? On Mon, Jan 13, 2014 at 5:22 PM, Adam Retter adam.ret...@googlemail.comwrote: My personal fear of the hat, is that it is too similar to Redhat IMHO. On 13 January 2014 22:29, John Miller john.w.mil...@oracle.com wrote: Well I guess the attachment did not go through.. [image: Maven Hat..jpg] Thanks John - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk -- Cheers, Paul - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed
Don't think that's doable as the user could configure the params for different goals in the same configuration section (on plugin level, not execution level). /Anders On Tue, Jan 14, 2014 at 7:38 PM, S. Ali Tokmen nos...@alishomepage.comwrote: Hi Baptiste, Thomas I guess you all got a point :) The reason why I want to check the configuration is indeed something that would have to be done in each goal. My remaining question would be whether there is a way to read the configuration XML definition from the MOJO - I could then manually implement such a verification in the different MOJOs. Please advise Thank you S. Ali Tokmen http://ali.tokmen.com/ My IM, GSM, PGP and other contact details are on http://contact.ali.tokmen.com On 14/01/14 14:24, Baptiste Mathus wrote: Hi, Stephen already answered along those lines. What are you missing? Cheers 2014/1/9 S. Ali Tokmen nos...@alishomepage.com Hi Anders Thanks for your reply - and happy new year :) Is there any way I can inject / read the whole plugin configuration from the plugin? Best regards S. Ali Tokmen http://ali.tokmen.com/ My IM, GSM, PGP and other contact details are on http://contact.ali.tokmen.com On 08/01/14 20:00, Anders Hammar wrote: AFAIK there is no support for this. If you think there should be, please file a ticket [1]. /Anders [1] http://jira.codehaus.org/browse/MNG/ On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen nos...@alishomepage.com wrote: Dear Maven users I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3 plugin; and would have a question with regards to how parameters are managed. We defined our MOJOs with parameters (you can see http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java for example), but what happens is that if a user unwillingly puts a parameter in the wrong place then the plugin execution doesn't stop. As an example, I can write the below POM and build still works (even thought the MOJO has no parameter called foo): plugin groupIdorg.codehaus.cargo/groupId artifactIdcargo-maven2-plugin/artifactId version1.4.6/version configuration foo bar /foo /configuration /plugin Is there any way I can instruct by MOJO to fail if there is an unknown parameter? Please advise Thank you -- S. Ali Tokmen http://ali.tokmen.com/ My IM, GSM, PGP and other contact details are on http://contact.ali.tokmen.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] WAS6 Maven Plugin version 1.2.1 Released
Hi, The Mojo team is pleased to announce the release of the WAS6 Maven Plugin version 1.2.1 This plugin works along with an installation of WebSphere Application Server (standalone or ND), to provide automated tasks for: generating RMIC stubs, starting/stopping servers, installing/updating/uninstalling EARs to application servers, starting/stopping application and run arbitrary scripts through wsadmin http://mojo.codehaus.org/was6-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdwas6-maven-plugin/artifactId version1.2.1/version /plugin Some links : Documentation: http://mojo.codehaus.org/was6-maven-plugin/ JIRA: http://jira.codehaus.org/browse/MWAS svn: https://svn.codehaus.org/mojo/tags/was6-maven-plugin-1.2.1/ Release Notes are available at https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11730version=19594 **Bug *[MWAS-70] - Skip does not work for wsAdmin, wsStartServer and wsStopServer *[MWAS-72] - WSEJBDeploy fails when pom uses system or provided dependencies. *[MWAS-73] - WSDL2Java fails when pom uses system or provided dependencies. **New Feature *[MWAS-59] - Support install/uninstall and start/stop for WARs Enjoy, The Mojo team. Javier Murciego
Why does maven-javadoc-plugin:javadoc execute from an aggregator POM?
I'm working with a set of eclipse-plugin projects using the Tycho plugins. We are trying to embed the javadocs in the plugin jar file, with an extension point so that the Javadocs show-up inline in the IDE. Since I need the javadoc to be generated prior to the package phase, I have configured the javadoc goal in the pluginManagement section of my parent POM, bound to the process-sources phase. This works fine when building the eclipse-plugin POM. But when I build from an aggregator POM, it fails with the error No public or protected classes found to document. I can run the aggregate goal to get one giant apidocs index of all the projects, but that doesn't generate the per-project apidocs to embed in each project's jar file because the aggregate goal skips all the non-aggregator POMs. So shouldn't the non-aggregate javadoc goals quietly not fork and execute the javadoc executable when it's processing an aggregator POM within the reactor? -- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?
On 15 January 2014 01:40, KARR, DAVID dk0...@att.com wrote: Again, I didn't want to debate whether this is convenient, I just wanted to know if Maven dependency resolution and things like the EAR plugin will have any trouble incorporating multiple dependencies with the same G:A, but different version. David, you've been on the list long enough to see the term If you fight Maven you will lose. That way pain lies. You will have much more joy solving the problem in a way that Maven helps you. Does any of Stephen's response help out? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?
-Original Message- From: Barrie Treloar [mailto:baerr...@gmail.com] Sent: Tuesday, January 14, 2014 2:23 PM To: Maven Users List Subject: Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version? On 15 January 2014 01:40, KARR, DAVID dk0...@att.com wrote: Again, I didn't want to debate whether this is convenient, I just wanted to know if Maven dependency resolution and things like the EAR plugin will have any trouble incorporating multiple dependencies with the same G:A, but different version. David, you've been on the list long enough to see the term If you fight Maven you will lose. That way pain lies. I haven't heard anyone confirm conclusively that this will not work, so up to now it appears to just be an opinion that there's something wrong with this approach. I've also been writing software long enough to know that reality often makes theory irrelevant. You will have much more joy solving the problem in a way that Maven helps you. Does any of Stephen's response help out? I believe that's a different situation. There will be a new version of this artifact every single month such that multiple versions of the same artifact can and will be used at the same time (very soon we will be using 6 at the same time). It doesn't make sense to me to define a new group id or artifact id every month, considering the only difference between two names (and their contents) will simply be a number, representing its version number. If the only difference is the version, then it should be reflected in the version number, as that's the primary difference between them. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?
On 14 January 2014 22:49, KARR, DAVID dk0...@att.com wrote: -Original Message- From: Barrie Treloar [mailto:baerr...@gmail.com] Sent: Tuesday, January 14, 2014 2:23 PM To: Maven Users List Subject: Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version? On 15 January 2014 01:40, KARR, DAVID dk0...@att.com wrote: Again, I didn't want to debate whether this is convenient, I just wanted to know if Maven dependency resolution and things like the EAR plugin will have any trouble incorporating multiple dependencies with the same G:A, but different version. David, you've been on the list long enough to see the term If you fight Maven you will lose. That way pain lies. I haven't heard anyone confirm conclusively that this will not work, so up to now it appears to just be an opinion that there's something wrong with this approach. Perhaps I just wasn't clear enough... Maven will resolve any list of dependencies so that there is a single unique version of any GA. Where you have a maven does not bomb out when you double list a dependency, you will get a single version. The correct parsing behaviour that Maven *should* follow is: * If the double dependency is in a project *being built* then fail the build * If the double dependency is in a dependency of the project being built, then resolve to single version. AFAIK the only unknown I am aware of is whether the first case applies, but in all cases that I am aware of you will only see one version of any GA I've also been writing software long enough to know that reality often makes theory irrelevant. You will have much more joy solving the problem in a way that Maven helps you. Does any of Stephen's response help out? I believe that's a different situation. There will be a new version of this artifact every single month such that multiple versions of the same artifact can and will be used at the same time (very soon we will be using 6 at the same time). It doesn't make sense to me to define a new group id or artifact id every month, considering the only difference between two names (and their contents) will simply be a number, representing its version number. If the only difference is the version, then it should be reflected in the version number, as that's the primary difference between them. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?
I haven't heard anyone confirm conclusively that this will not work, so up to now it appears to just be an opinion that there's something wrong with this approach. Let me make it perfectly clear for you then: This will not work. Maven will resolve both dependencies with the same GA and different Vs into a single GAV. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?
-Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, January 14, 2014 3:10 PM To: Maven Users List Subject: Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version? On 14 January 2014 22:49, KARR, DAVID dk0...@att.com wrote: -Original Message- From: Barrie Treloar [mailto:baerr...@gmail.com] Sent: Tuesday, January 14, 2014 2:23 PM To: Maven Users List Subject: Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version? On 15 January 2014 01:40, KARR, DAVID dk0...@att.com wrote: Again, I didn't want to debate whether this is convenient, I just wanted to know if Maven dependency resolution and things like the EAR plugin will have any trouble incorporating multiple dependencies with the same G:A, but different version. David, you've been on the list long enough to see the term If you fight Maven you will lose. That way pain lies. I haven't heard anyone confirm conclusively that this will not work, so up to now it appears to just be an opinion that there's something wrong with this approach. Perhaps I just wasn't clear enough... Maven will resolve any list of dependencies so that there is a single unique version of any GA. Where you have a maven does not bomb out when you double list a dependency, you will get a single version. The correct parsing behaviour that Maven *should* follow is: * If the double dependency is in a project *being built* then fail the build * If the double dependency is in a dependency of the project being built, then resolve to single version. AFAIK the only unknown I am aware of is whether the first case applies, but in all cases that I am aware of you will only see one version of any GA Ok, thanks for clarifying. I guess I'll plan on putting the version number into the artifact id string so the G:A will vary. I've also been writing software long enough to know that reality often makes theory irrelevant. You will have much more joy solving the problem in a way that Maven helps you. Does any of Stephen's response help out? I believe that's a different situation. There will be a new version of this artifact every single month such that multiple versions of the same artifact can and will be used at the same time (very soon we will be using 6 at the same time). It doesn't make sense to me to define a new group id or artifact id every month, considering the only difference between two names (and their contents) will simply be a number, representing its version number. If the only difference is the version, then it should be reflected in the version number, as that's the primary difference between them. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Depend on a jar via another pom file
Well, what scope are used here? Thus is a central element to manage transitivity. Btw, you should never rely on a dependency to get a dependency you're also using. You must redeclare it in your own pom. (mvn dependency:analyze can also help you here). Cheers Le 8 janv. 2014 16:59, Omar@Gmail omarnet...@googlemail.com a écrit : I have a maven module (lets call it M) that requires aspectjrt but M already depends on another pom file that has aspectjrt within its dependency tree like so: M - middle pom - aspectjrt The problem is M would not compile unless I express the aspectjrt dependency directly in the M pom file, why? Is there a way for M to get apsectjrt via the middle pom without directly depending on aspectjrt?
