On Jul 28, 2011, at 8:31 PM, Mark Struberg wrote: > Of course, not having to touch the POMs is a good thing. > > But I don't get the 'historic behaviour' part. Even if you would have > components in the scm-providers (which all need to be changed), this solution > would not work with older maven version because they will simply not get > injected somewhere. >
Dealing with what people use today versus native expressions in the future. The components are simple, they could be external and use in Maven 2.x and 3.x. > Plus, you would need to split that code from the scm-providers, as explained > before. But maintaining them separately, I wonder how this should scale. It > must be part of maven-core, because it must clearly be available _before_ > dependencies and even extensions are available. We're going to end up with a few lines of code for each SCM. For the short term I doubt this is going to be a problem because there are probably less than 10 to deal with and changes could be made quickly and then they are unlikely to change. It's not a lot of code to deal with, it can be in Maven as it is more for POM construction than anything to do with any particular SCM. > > So basically it comes down to > > 1.) having a list of SCMs which must not get the module-name appended. It imo > doesn't make much difference if you do this via a regexp or via a Java class. > I think the regexp in toolchains.mdo even would have the benefit that a user > would be able to overwrite/extend the default config if he needs to. Is it as simple as that for all SCMs? > > 2.) marking the url tag somehow. Either inside the URL string with a prefix > like 'absolute:' or via an xml attribute. > > > The explicit marking of URLs allows this solution to get applied for site > stuff too. The regexp/Java stuff would not work for the site URL problematic, > because there is no information about the intention of the user in the pom > atm. > It would be useful to see the forms SCM URL construction for: CVS SVN Git Hg Perforce Clearcase And anything else that people might want. I think if it's going to be something that must work for all cases, and cases we cannot foresee then a simple implementation in a component where the default implementation is component that uses regexes that's fine, but if we're thinking of making this pluggable then I think allowing someone to plug in whatever logic they want would be useful. > LieGrue, > strub > > > --- On Fri, 7/29/11, Jason van Zyl <ja...@sonatype.com> wrote: > >> From: Jason van Zyl <ja...@sonatype.com> >> Subject: Re: [DISCUSS] SCM child-project URL composition >> To: "Maven Developers List" <dev@maven.apache.org> >> Date: Friday, July 29, 2011, 12:08 AM >> I would also propose >> >> C) A small bit of Java code in the form of a component for >> each SCM type and inject those into the inheritance >> assembler to deal with the URLs. Then no need is required in >> the POM, and we can also look at the version of Maven if we >> want to mimic historic behavior. We could also try to >> simply the form we currently have to simply allow >> native expressions like: >> >> g...@github.com:sonatype/sonatype-aether.git >> >> And deal with those in the component if it's determined >> it's possible. I think this method has the advantage of >> requiring zero change to the POM, no trickery with Modello, >> can be made flexible with relation to different versions of >> Maven and will allow a progression toward using native >> expressions. It would be a bit more code but are we sure we >> can handle weirder cases like with Perforce or Clearcase >> with just absolute and relative?. If someone can hack out a >> little bit a Java code I think that's ultimately simpler >> than trying to play with regular expressions, and modello. >> >> On Jul 28, 2011, at 6:59 PM, Mark Struberg wrote: >> >>> will try that too.... >>> >>> yup, just fine too with mvn-3.0.3 and mvn-2.2.1. >>> >>> So we now have either >>> >>> A.) >>> <url absolute="true">scm:git:https://... >>> >>> or >>> B.) >>> <url>absolute:scm:git:https://... >>> >>> Please decide folks ;) >>> >>> LieGrue, >>> strub >>> >>> --- On Thu, 7/28/11, Stephen Connolly <stephen.alan.conno...@gmail.com> >> wrote: >>> >>>> From: Stephen Connolly <stephen.alan.conno...@gmail.com> >>>> Subject: Re: [DISCUSS] SCM child-project URL >> composition >>>> To: "Maven Developers List" <dev@maven.apache.org> >>>> Date: Thursday, July 28, 2011, 10:47 PM >>>> i think modelleo allows any random >>>> attributes (as other pays them no heed... >>>> not sure of ivy, and the others... but they are >> likely only >>>> looking at >>>> dependencies... a garden problem alright) >>>> >>>> - Stephen >>>> >>>> --- >>>> Sent from my Android phone, so random spelling >> mistakes, >>>> random nonsense >>>> words and other nonsense are a direct result of >> using swype >>>> to type on the >>>> screen >>>> On 28 Jul 2011 23:38, "Benson Margulies" <bimargul...@gmail.com> >>>> wrote: >>>>> attributes are special in XML schema. I plan >> to check >>>> and see if pom >>>>> 4.0 really precludes unqualified attributes. >>>>> >>>>> On Jul 28, 2011, at 6:26 PM, John Casey <jdca...@commonjava.org> >>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 7/28/11 6:12 PM, Mark Struberg wrote: >>>>>>> Hi and txs 4 looking through the >> proposal! >>>>>>> >>>>>>> <url static="true"> is a neat >> idea but >>>> sadly requires us to change the >>>> pom-4.0 schema. So I fear this is a no-go atm. >>>>>>> >>>>>>> I'm not sure if there is lots of code >> which >>>> parses the content of the >>>> urls manually. It's not guaranteed what it >> contains, and we >>>> already apply >>>> _lots_ of magic to those URLs (property expansion, >> etc). So >>>> anyone which >>>> does not use our stuff is on his own anyway. >> Actually the >>>> content is still a >>>> valid URL in the sense of RFC-1738. But it's our >> own >>>> protocol now ;) >>>>>>> >>>>>>> Just my $0.02 >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> PS: I really like the 'absolute:' >> protocol >>>> name Robert proposed (instead >>>> of 'static:'. >>>>>> >>>>>> +1 >>>>>> >>>>>>> >>>>>>> --- On Thu, 7/28/11, Benson >> Margulies<bimargul...@gmail.com> >>>> wrote: >>>>>>> >>>>>>>> From: Benson Margulies<bimargul...@gmail.com> >>>>>>>> Subject: Re: [DISCUSS] SCM >> child-project >>>> URL composition >>>>>>>> To: "Maven Developers List"<dev@maven.apache.org> >>>>>>>> Date: Thursday, July 28, 2011, >> 10:01 PM >>>>>>>> As well I know from MSITE-600. >>>>>>>> However, now I'm confused: you >>>>>>>> couldn't use the static business >> with >>>>>>>> >> /project/distributionManagement/site/url, >>>> since those are >>>>>>>> naked urls. >>>>>>>> The proposal above is not >> scm:static:, >>>> it's static:scm:. >>>>>>>> are you >>>>>>>> suggesting putting static:http: >> in >>>>>>>> >> /project/distributionManagement/site/url? >>>> That looks >>>>>>>> like a problem >>>>>>>> for anything that parses the pom >> and >>>> doesn't use the model >>>>>>>> code, and I >>>>>>>> thought we felt precluded from >> busting >>>> things like this. >>>>>>>> >>>>>>>> Yet Another Alternative: >>>>>>>> >>>>>>>> <url >>>> static='true'>what-we-have-today</url> >>>>>>>> >>>>>>>> would work for scm and also for >> websites. >>>> In my opinion, >>>>>>>> the >>>>>>>> 'disconnected parent' issue has to >> be >>>> fully taken on board, >>>>>>>> and that >>>>>>>> really calls for >>>>>>>> >>>>>>>> <url >>>>>>>> >>>> inherit='false'>what-we-have-today</url> >>>>>>>> >>>>>>>> which would be a good thing for >> the >>>> overall ASF pom. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 28, 2011 at 5:50 PM, >> John >>>> Casey<jdca...@commonjava.org> >>>>>>>> wrote: >>>>>>>>> using scm2: you're not able to >> apply >>>> the solution to >>>>>>>> website urls, etc. >>>>>>>>> which have a similar >>>> inheritance/calculation >>>>>>>> problem... >>>>>>>>> >>>>>>>>> On 7/28/11 5:45 PM, Benson >> Margulies >>>> wrote: >>>>>>>>>> >>>>>>>>>> Is static: really superior >> to >>>> scm2: and then more >>>>>>>> colons allowing >>>>>>>>>> arbitrary keyword-value >> pairs? >>>>>>>>>> >>>>>>>>>> On Thu, Jul 28, 2011 at >> 5:44 PM, >>>> Mark >>>>>>>> Struberg<strub...@yahoo.de> >>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi! >>>>>>>>>>> >>>>>>>>>>> A small update: >>>>>>>>>>> >>>>>>>>>>> Benjamin mentioned >> that this >>>> might also be >>>>>>>> useful for site URLs if a user >>>>>>>>>>> like to define the >> effective >>>> URLs of the >>>>>>>> sub-module site via >>>>>>>>>>> >>>> ${project.version}/${project.artifactId} or >>>>>>>> similar. >>>>>>>>>>> >>>>>>>>>>> So we just came up >> with >>>> "static:" as prefix. >>>>>>>>>>> >>>>>>>>>>> More soon via Jira. >>>>>>>>>>> >>>>>>>>>>> LieGrue, >>>>>>>>>>> strub >>>>>>>>>>> >>>>>>>>>>> --- On Thu, 7/28/11, >> Brian >>>> Fox<bri...@infinity.nu> >>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> From: Brian >> Fox<bri...@infinity.nu> >>>>>>>>>>>> Subject: Re: >> [DISCUSS] SCM >>>> child-project >>>>>>>> URL composition >>>>>>>>>>>> To: "Maven >> Developers >>>> List"<dev@maven.apache.org> >>>>>>>>>>>> Date: Thursday, >> July 28, >>>> 2011, 9:32 PM >>>>>>>>>>>> not crazy about >> the >>>> syntax, but >>>>>>>>>>>> generally yes i >> think that >>>> makes sense. >>>>>>>>>>>> >>>>>>>>>>>> I've long >> maintained that >>>> we need >>>>>>>> something similar for >>>>>>>>>>>> properties to >>>>>>>>>>>> balance between >> "resolve >>>> at build time" >>>>>>>> and "resolve at >>>>>>>>>>>> fetch from >>>>>>>>>>>> repo" type of >> issues. >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jul 28, >> 2011 at >>>> 3:37 PM, Mark >>>>>>>> Struberg<strub...@yahoo.de> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi John, >> Brian >>>>>>>>>>>>> >>>>>>>>>>>>> Just to make >> sure I >>>> did understand >>>>>>>> that correctly: >>>>>>>>>>>>> you propose to >> use a >>>> special URL >>>>>>>> prefix to tell the >>>>>>>>>>>> >>>>>>>>>>>> maven >>>> DefaultProjectBuilder to treat those >>>>>>>> urls as static. >>>>>>>>>>>> An example: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> <scm> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>> >> <developerConnection>staticscm:git:ssh://myserver:/..</developerConnection >>>>>>>>>>>>> >>>>>>>>>>>>> resulting in >> replacing >>>> 'staticscm' >>>>>>>> with 'scm' and not >>>>>>>>>>>> >>>>>>>>>>>> adding the child >> modules >>>> to the URL. >>>>>>>>>>>>> >>>>>>>>>>>>> Did I get >> this >>>> correctly? >>>>>>>>>>>>> >>>>>>>>>>>>> Tried that >> with >>>> mvn-3.0.3 and >>>>>>>> mvn-2.2.1 and a standard >>>>>>>>>>>> >>>>>>>>>>>> build works just >> fine. Of >>>> course a release >>>>>>>> would only work >>>>>>>>>>>> with the newer >> maven >>>> versions! >>>>>>>>>>>>> >>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>> strub >>>>>>>>>>>>> >>>>>>>>>>>>> --- On Thu, >> 7/28/11, >>>> Brian Fox<bri...@infinity.nu> >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> From: >> Brian >>>> Fox<bri...@infinity.nu> >>>>>>>>>>>>>> Subject: >> Re: >>>> [DISCUSS] SCM >>>>>>>> child-project URL >>>>>>>>>>>> >>>>>>>>>>>> composition >>>>>>>>>>>>>> >>>>>>>>>>>>>> To: >> "Maven >>>> Developers List"<dev@maven.apache.org> >>>>>>>>>>>>>> Date: >> Thursday, >>>> July 28, 2011, >>>>>>>> 7:23 PM >>>>>>>>>>>>>> On Thu, >> Jul 28, >>>> 2011 at 2:59 PM, >>>>>>>> John >>>>>>>>>>>>>> >> Casey<jdca...@commonjava.org> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Would >> it be >>>> better to have a >>>>>>>> syntax to mark a >>>>>>>>>>>> >>>>>>>>>>>> URL as >>>>>>>>>>>>>> >>>>>>>>>>>>>> literal, >> not to >>>> be >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >> calculated or >>>> used as the >>>>>>>> basis of >>>>>>>>>>>> >>>>>>>>>>>> calculation? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes. I >> tried to >>>> fix this behavior >>>>>>>> for urls back in >>>>>>>>>>>> >>>>>>>>>>>> ~2.0.6/7 >>>>>>>>>>>>>> >>>>>>>>>>>>>> ish and >> it >>>>>>>>>>>>>> broke lots >> of >>>> stuff that depended >>>>>>>> upon that >>>>>>>>>>>> >>>>>>>>>>>> behavior. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> That >> way, we >>>> don't have to >>>>>>>> worry about >>>>>>>>>>>> >>>>>>>>>>>> adjusting to >>>>>>>>>>>>>> >>>>>>>>>>>>>> new SCMs >> or other >>>> places >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> where >> we want >>>> to use it...new >>>>>>>> SCMs could be >>>>>>>>>>>> >>>>>>>>>>>> added via >>>>>>>>>>>>>> >>>>>>>>>>>>>> build >> extension, >>>> IIRC, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> so >> this is >>>> particularly >>>>>>>> important there. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On >> 7/28/11 >>>> 12:46 PM, Mark >>>>>>>> Struberg wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> Hi! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> problem >>>> description >>>>>>>>>>>>>>>> >>>> ----------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> SCM URLs >>>> currently >>>>>>>> automatically get >>>>>>>>>>>> >>>>>>>>>>>> extended for >>>>>>>>>>>>>> >>>>>>>>>>>>>> child >> modules. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> E.g. from >>>>>>>>>>>>>>>> >>>>>>>> svn://mycompany.com/myproject >>>>>>>>>>>>>>>> in >> the >>>> parent pom, a child >>>>>>>> module >>>>>>>>>>>> >>>>>>>>>>>> 'frontend' will >>>>>>>>>>>>>> >>>>>>>>>>>>>> result in >> getting >>>> a SCM >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> URL >>>>>>>>>>>>>>>> >>>>>>>> >> svn://mycompany.com/myproject/frontend >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> This is >>>> fine for SVN and >>>>>>>> CVS, but broken >>>>>>>>>>>> >>>>>>>>>>>> for GIT, >>>>>>>>>>>>>> >>>>>>>>>>>>>> HG, etc >> because >>>> the SCM >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> URL is >>>> 'static' for them. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> proposal >>>>>>>>>>>>>>>> >>>> ----------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> Since we >>>> cannot put this >>>>>>>> information into >>>>>>>>>>>> >>>>>>>>>>>> the >>>>>>>>>>>>>> >>>>>>>>>>>>>> various >> scm >>>> plugins (because >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> of >> a >>>> 'definition cycle' as >>>>>>>> explained here >>>>>>>>>>>> >>>>>>>>>>>> [1]) we >>>>>>>>>>>>>> >>>>>>>>>>>>>> could >> split the >>>> URL >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> construction into >>>>>>>>>>>> >>>>>>>>>>>> >>>> scmUrlAppendChild=true/false and >>>>>>>>>>>>>> >>>>>>>>>>>>>> make it >>>> configurable. The >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> configuration could be >>>>>>>> controlled via a >>>>>>>>>>>> >>>>>>>>>>>> Modello >>>>>>>>>>>>>> >>>>>>>>>>>>>> config, >> my >>>> suggestion would >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> be >> to just >>>> add them to >>>>>>>> toolchains.mdo. >>>>>>>>>>>>>>>> >> I'd just >>>> add a String >>>>>>>> property which >>>>>>>>>>>> >>>>>>>>>>>> holds a >>>>>>>>>>>>>> >>>>>>>>>>>>>> regular >> expression >>>> which >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> parses the >>>> SCM URL and >>>>>>>> decides upon this >>>>>>>>>>>> >>>>>>>>>>>> whether >>>>>>>>>>>>>> >>>>>>>>>>>>>> the >> appending >>>> should get >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> activated, >>>> e.g. for all >>>>>>>> SCMs which >>>>>>>>>>>> >>>>>>>>>>>> contain >>>>>>>>>>>>>> >>>>>>>>>>>>>> 'scm:svn:' >> or >>>> 'scm:cvs:' or the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> java-svn >>>> (olamy, you know >>>>>>>> the plexus key >>>>>>>>>>>> >>>>>>>>>>>> for >>>>>>>>>>>>>> >>>>>>>>>>>>>> that?) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If >> there >>>> is a better place >>>>>>>> to put that >>>>>>>>>>>> >>>>>>>>>>>> config or a >>>>>>>>>>>>>> >>>>>>>>>>>>>> better way >> to get >>>> the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> info, then >>>> please speak up >>>>>>>> now :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I >> think >>>> this change would >>>>>>>> be backward >>>>>>>>>>>> >>>>>>>>>>>> compatible >>>>>>>>>>>>>> >>>>>>>>>>>>>> and >> doesn't need >>>> any pom >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> changes. >>>> It also could >>>>>>>> easily get >>>>>>>>>>>> >>>>>>>>>>>> back-ported to >>>>>>>>>>>>>> >>>>>>>>>>>>>> mvn2 if >> needed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> Are there >>>> other URLS which >>>>>>>> also need a >>>>>>>>>>>> >>>>>>>>>>>> similar >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> distinction while >>>> building >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> the >>>> model? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> WDYT? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> txs and >>>> LieGrue, >>>>>>>>>>>>>>>> >> strub >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> [1] http://markmail.org/message/npw3hp6aloa55ctf >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>> >> --------------------------------------------------------------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> To >>>> unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>>>>>>>> >> For >>>> additional commands, >>>>>>>> e-mail: dev-h...@maven.apache.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> John >> Casey >>>>>>>>>>>>>>> >> Developer, PMC >>>> Chair - Apache >>>>>>>> Maven (http://maven.apache.org) >>>>>>>>>>>>>>> Blog: >> http://www.johnofalltrades.name/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>> >> --------------------------------------------------------------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To >>>> unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>>>>>>> For >> additional >>>> commands, >>>>>>>> e-mail: dev-h...@maven.apache.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>> >> --------------------------------------------------------------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> To >> unsubscribe, >>>> e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>>>>>> For >> additional >>>> commands, e-mail: >>>>>>>> dev-h...@maven.apache.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>> >> --------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> To >> unsubscribe, >>>> e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>>>>> For >> additional >>>> commands, e-mail: dev-h...@maven.apache.org >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>> >> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, >> e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>>>> For additional >> commands, >>>> e-mail: dev-h...@maven.apache.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>> >> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, >> e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>>> For additional >> commands, >>>> e-mail: dev-h...@maven.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>> >> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>> For additional commands, >> e-mail: >>>> dev-h...@maven.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> John Casey >>>>>>>>> Developer, PMC Chair - Apache >> Maven >>>> (http://maven.apache.org) >>>>>>>>> Blog: http://www.johnofalltrades.name/ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>> >> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>> For additional commands, >> e-mail: dev-h...@maven.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>> >> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>> For additional commands, e-mail: >> dev-h...@maven.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>> >> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>> >>>>>> >>>>>> -- >>>>>> John Casey >>>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org) >>>>>> Blog: http://www.johnofalltrades.name/ >>>>>> >>>>>> >>>> >> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>> >>>>> >>>> >> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>> >>> >>> >> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> You are never dedicated to something you have complete >> confidence in. >> No one is fanatically shouting that the sun is going to >> rise tomorrow. >> They know it is going to rise tomorrow. When people are >> fanatically >> dedicated to political or religious faiths or any other >> kind of >> dogmas or goals, it's always because these dogmas or >> goals are in doubt. >> >> -- Robert Pirzig, Zen and the Art of Motorcycle >> Maintenance >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham