Le vendredi 29 juillet 2011, Mark Struberg a écrit : > > Is it as simple as that for all SCMs? > > Yes it is. > Remember the old days: this is only a fix for a 'fix'. Originally the SCM > URLs haven't been changed for child modules. This 'feature' only got > introduce later to make life easier for SVN and CVS users (the vast > majority of projects back then). > > What we now do is to disable this 'feature' (which now got a known and > expected default behaviour) in some certain cases. Not more not less. a property? like we did for project.build.encoding? this would be project.scm.autoModule?
> > I honestly fear of doing some magic with the SCM Urls because those are NOT > native urls but get interpreted by the SCM providers. Thus the 'url > adaptors' would need to 100% match the specific scm providers. So you > either ship it in the same build or you are soon doomed I fear. But as you > need to ship that classes as part of a maven release, there is just no > upgrade scenario and you would need to support sins for a long time... if this gets into maven-scm, this needs to be a dedicated module, cross-scms, and independendant from wagon-provider-api And the upgrade scenario exists: you can override a library shipped with Maven > > The 2nd nice benefit: I'm currently digging into the attribute stuff in > Modello. If this works out, we can use this approach for other long > awaited features (like the mixins) in a pom-4.0.0 compatible way! if you didn't see, there is a strictXmlAttribute configuration added in Modello 1.2 [1] to deal with attributes checks or not I don't know how the maven.mdo has been configured in every Maven release. Regards, Hervé [1] http://modello.codehaus.org/modello.html#class_default > > 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:47 AM > > > > 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:/..</developerConnectio > > n > > > > > > 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 > > --------------------------------------------------------------------- > 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
