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
