> -----Original Message-----
> From: Hervé BOUTEMY
> Sent: Saturday, September 17, 2011 12:33
> To: Maven Developers List
> Subject: Re: Request for review and comment
> http://jira.codehaus.org/browse/MNG-5167
>
> my comments are in the Jira issue
> but the summary is: I don't think this scenario requires a new feature
Hervé's workaround example cited in JIRA does not function as assumed here is
the result of running the example:
Already tried that and this is why it does not work:
Adding to surefire booter test classpath: C:\Documents and Settings\All
Users\Desktop\projects\cascade\trunk\tmp\test\${env.M2_HOME}\..\..\..\lib\mvn\or
g\apache\maven\surefire\surefire-booter\2.7.2\surefire-booter-2.7.2.jar Scope:
compile
as to the lib/mvn it was copied from a project which was following ARB naming
conventions and I did not get to choose the name.
>
> Regards,
>
> Hervé
>
> Le samedi 17 septembre 2011, Jason Pyeron a écrit :
> > > -----Original Message-----
> > > From: Jason van Zyl
> > > Sent: Saturday, September 17, 2011 11:13
> > > To: Maven Developers List
> > > Subject: Re: Request for review and comment
> > > http://jira.codehaus.org/browse/MNG-5167
> > >
> > > On Sep 17, 2011, at 11:06 AM, Jason Pyeron wrote:
> > > >> -----Original Message-----
> > > >> From: Jason van Zyl
> > > >> Sent: Saturday, September 17, 2011 10:25
> > > >> To: Maven Developers List
> > > >> Subject: Re: Request for review and comment
> > > >> http://jira.codehaus.org/browse/MNG-5167
> > > >>
> > > >> I honestly have no idea what problem you're trying to
> > >
> > > solve from your
> > >
> > > >> comments in the issues. I'd start with:
> > > >>
> > > >> - What problem you're trying to solve
> > > >
> > > > Presently the local repository can only be specified as an
> > > > absolute path or relative to the current working
> directory (CWD).
> > > > In a CMMI
> > >
> > >
> (http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration)
> > >
> > > > Level 3 and greater environment it is often a requirement
> > >
> > > to have all
> > >
> > > > project dependencies at all times (or at a minimum at
> > >
> > > release milestones) in the SCM system.
> > >
> > > > Each developer workstation may not be configured
> identically and
> > > > it would be burdensome to expect a configuration change for a
> > >
> > > build tool.
> > >
> > > > By allowing project relative repository paths, the
> > >
> > > configuration can
> > >
> > > > be predicted and controlled.
> > >
> > > I don't buy any of that. From my understanding it's to be able to
> > > retrieve everything in a predictable reliable fashion. You're not
> > > going to convince anyone here putting the binary
> dependencies in the
> > > SCM is a good idea.
> >
> > Could you propose a solution to the following scenario?
> >
> > Pick a revision, export it to cd/dvd media, take it to a air gapped
> > build machine, and build it in a reproducible way.
> >
> > > >> - Why you think it's important
> > > >
> > > > As a measure of importance, this patch is being used in
> > >
> > > production in
> > >
> > > > 3 different companies in a production capacity presently.
> > >
> > > This patch
> > >
> > > > allows a switch to maven from a manual dependency
> > >
> > > management approach
> > >
> > > > without breaking policies.
> > >
> > > This is why the project is open source. I don't think
> this patch is
> > > something I would generally promote if the end result is
> encouraging
> > > people to put binary dependencies in the source control
> system. But
> > > you are free to maintain a patched version, that's your right.
> >
> > So don't encourage, but allow it. We are trying to
> contribute, I don't
> > think deciding what CM procedures is best for some other
> organization
> > should be a motivating driver for the patch acceptance. Is
> the urge to
> > control how an organization handles its SDLC such a strong
> issue that
> > you want a fork of MAVEN?
> >
> > Can you point out technical deficiencies?
> >
> > I think it is worth noting from a do no harm approach, looking at
> > lines 249, 250, 269, 286 of the patch it should be clear
> that if the
> > user does not configure maven with this element then the
> behavior will
> > remain unchanged.
> >
> > > >> - Examples of how it would be used
> > > >
> > > > Project structure:
> > > >
> > > > ./
> > > > ./bin
> > > > ./lib/mvn
> > > > ./src
> > > > ./var/opt/apache-maven-3.0.4-SNAPSHOT/
> > >
> > > > ./var/opt/apache-maven-3.0.4-SNAPSHOT/conf/settings.xml:
> > >
> <settings><localRepositoryRelativeTo>M2_HOME</localRepositoryRelativ
> > > eT
> > >
> > > > o><localRe
> > > > pository>../../../lib/mvn</localRepository></settings>
> > > >
> > > >> It's easier if you capture the discussion in the issue.
> > > >
> > > > This is a copy of what was posted
> > >
> > >
> (http://jira.codehaus.org/browse/MNG-5167?focusedCommentId=279221&pa
> > > ge
> > >
> > > > =com.atlas
> > >
> > >
> sian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-2792
> > > 21
> > >
> > > > ) for all to read.
> > > >
> > > >> On Aug 26, 2011, at 6:12 PM, Jason Pyeron wrote:
> > > >>> There are 2 areas I would like input on.
> > > >>>
> > > >>> 1: Did I make proper use of logging in
> > >
> > >
> maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExec
> > > u
> > >
> > > >> t
> > > >>
> > > >>> ionRequest
> > > >>> Populator.java?
> > > >>> 2: Is there a better place for the constants than in
> > >
> > >
> maven-settings-builder/src/main/java/org/apache/maven/settings/valid
> > > a
> > >
> > > >> t
> > > >>
> > > >>> ion/Settin
> > > >>> gsValidator.java?
> > > >>
> > > >>> Patch:
> > > >> http://jira.codehaus.org/secure/attachment/56607/MNG-5167.patch
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
