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.
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.
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.
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.
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
