maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Date Sat, 17 Sep 2011 16:33:12 GMT
my comments are in the Jira issue
but the summary is: I don't think this scenario requires a new feature

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</localRepositoryRelativeT
> > 
> > > 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&page
> > 
> > > =com.atlas
> > 
> > sian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-279221
> > 
> > > ) 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/DefaultMavenExecu
> > 
> > >> 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/valida
> > 
> > >> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message