> 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.
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...
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!
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:/..</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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
