Grokbase Groups Maven dev August 2011
FAQ
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/DefaultMavenExecutionRequest
Populator.java?
2: Is there a better place for the constants than in
maven-settings-builder/src/main/java/org/apache/maven/settings/validation/Settin
gsValidator.java?

Patch: http://jira.codehaus.org/secure/attachment/56607/MNG-5167.patch

-Jason

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

Search Discussions

  • Jason van Zyl at Sep 17, 2011 at 2:25 pm
    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
    - Why you think it's important
    - Examples of how it would be used

    It's easier if you capture the discussion in the issue.
    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/DefaultMavenExecutionRequest
    Populator.java?
    2: Is there a better place for the constants than in
    maven-settings-builder/src/main/java/org/apache/maven/settings/validation/Settin
    gsValidator.java?

    Patch: http://jira.codehaus.org/secure/attachment/56607/MNG-5167.patch

    -Jason

    --
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    - -
    - 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
    Thanks,

    Jason

    ----------------------------------------------------------
    Jason van Zyl
    Founder, Apache Maven
    http://twitter.com/jvanzyl
    ---------------------------------------------------------

    A language that doesn’t affect the way you think about programming is not worth knowing.

    -— Alan Perlis
  • Jason Pyeron at Sep 17, 2011 at 3:00 pm

    -----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.
    - 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.
    - 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</localRepositoryRelativeTo><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/DefaultMavenExecut
    ionRequest
    Populator.java?
    2: Is there a better place for the constants than in
    maven-settings-builder/src/main/java/org/apache/maven/settings/validat
    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
  • Jason van Zyl at Sep 17, 2011 at 3:13 pm

    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.
    - 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.
    - 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</localRepositoryRelativeTo><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/DefaultMavenExecut
    ionRequest
    Populator.java?
    2: Is there a better place for the constants than in
    maven-settings-builder/src/main/java/org/apache/maven/settings/validat
    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
    Thanks,

    Jason

    ----------------------------------------------------------
    Jason van Zyl
    Founder, Apache Maven
    http://twitter.com/jvanzyl
    ---------------------------------------------------------

    Simplex sigillum veri. (Simplicity is the seal of truth.)
  • Stephane Nicoll at Sep 17, 2011 at 3:26 pm
    Hi,
    On Sat, Sep 17, 2011 at 5:12 PM, Jason van Zyl wrote:

    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.
    - 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.
    I definitely second that.

    Thanks,
    S.

    - 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</localRepositoryRelativeTo><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/DefaultMavenExecut
    ionRequest
    Populator.java?
    2: Is there a better place for the constants than in
    maven-settings-builder/src/main/java/org/apache/maven/settings/validat
    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
    Thanks,

    Jason

    ----------------------------------------------------------
    Jason van Zyl
    Founder, Apache Maven
    http://twitter.com/jvanzyl
    ---------------------------------------------------------

    Simplex sigillum veri. (Simplicity is the seal of truth.)


  • Benson Margulies at Sep 17, 2011 at 3:43 pm

    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.
    I definitely second that.
    I am uncomfortable rejecting a patch that has no visible negative
    impact except that it it 'encourages people to put binary dependencies
    in SCM'. Maven users are presumably consenting adults. If adding this
    feature made something surprising, slow, or unhelpful happen to users
    doing the usual thing, I'd be -1 for it. But if it adds flexibility
    without conceptual or implementation overhead, I'd be +1.

    Another direction here is to ask what sort of pluggability would allow
    someone to inject this behavior without having to maintain a fork.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
    For additional commands, e-mail: dev-help@maven.apache.org
  • Jason Pyeron at Sep 17, 2011 at 3:47 pm

    -----Original Message-----
    From: Benson Margulies
    Sent: Saturday, September 17, 2011 11:43
    To: Maven Developers List
    Subject: Re: Request for review and comment
    http://jira.codehaus.org/browse/MNG-5167
    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.
    I definitely second that.
    I am uncomfortable rejecting a patch that has no visible
    negative impact except that it it 'encourages people to put
    binary dependencies in SCM'. Maven users are presumably
    consenting adults. If adding this feature made something
    surprising, slow, or unhelpful happen to users doing the
    usual thing, I'd be -1 for it. But if it adds flexibility
    without conceptual or implementation overhead, I'd be +1.

    Another direction here is to ask what sort of pluggability
    would allow someone to inject this behavior without having to
    maintain a fork.
    If you look at the enum, it could be made into a service proder approch. But it
    wuold have to be registered at the bootstrap time frame.

    --
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    - -
    - 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
  • Mark Derricutt at Sep 17, 2011 at 10:02 pm
    Would a compromise to something using the baseDir of the project ( or root project ) and not an arbitrary relative path?

    I can see a benefit to this, but I can also see not wanting to allow the user to reach outside their SCM controlled project.

    On 18/09/2011, at 3:42 AM, Benson Margulies wrote:

    I am uncomfortable rejecting a patch that has no visible negative
    impact except that it it 'encourages people to put binary dependencies
    in SCM'. Maven users are presumably consenting adults. If adding this
    feature made something surprising, slow, or unhelpful happen to users
    doing the usual thing, I'd be -1 for it. But if it adds flexibility
    without conceptual or implementation overhead, I'd be +1.
  • Jason Pyeron at Sep 17, 2011 at 11:11 pm

    -----Original Message-----
    From: Mark Derricutt
    Sent: Saturday, September 17, 2011 18:02
    To: Maven Developers List
    Subject: Re: Request for review and comment
    http://jira.codehaus.org/browse/MNG-5167

    Would a compromise to something using the baseDir of the
    project ( or root project ) and not an arbitrary relative path?
    Currently, the patch supports

    LOCAL_REPOSITORY_RELATIVE_TO_VALUES.POM
    LOCAL_REPOSITORY_RELATIVE_TO_VALUES.M2_HOME
    LOCAL_REPOSITORY_RELATIVE_TO_VALUES.BASEDIRECTORY
    LOCAL_REPOSITORY_RELATIVE_TO_VALUES.WORKINGDIRECTORY
    LOCAL_REPOSITORY_RELATIVE_TO_VALUES.DEFAULT // As far as I have been able to
    test, DEFAULT and WORKINGDIRECTORY should and do behave the same, but the code
    for an explicit working directory is different that the current code. So the
    defaul uses an unchanged logic, and the working directory explicitly uses the
    CWD.

    I am working on adding support for
    LOCAL_REPOSITORY_RELATIVE_TO_VALUES.ROOT_PARENT_POM but this is also going to
    come when a few other issues in the configuration engin and reactor are fixed
    too.

    I can see a benefit to this, but I can also see not wanting
    to allow the user to reach outside their SCM controlled project.

    On 18/09/2011, at 3:42 AM, Benson Margulies wrote:

    I am uncomfortable rejecting a patch that has no visible negative
    impact except that it it 'encourages people to put binary
    dependencies
    in SCM'. Maven users are presumably consenting adults. If
    adding this
    feature made something surprising, slow, or unhelpful
    happen to users
    doing the usual thing, I'd be -1 for it. But if it adds flexibility
    without conceptual or implementation overhead, I'd be +1.


    --
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    - -
    - 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
  • Jason Pyeron at Sep 17, 2011 at 3:39 pm

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

    --
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    - -
    - 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
  • Benson Margulies at Sep 17, 2011 at 3:44 pm

    On Sat, Sep 17, 2011 at 11:45 AM, Jason Pyeron wrote:
    -----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.
    Certainly I can. You export it in the form of a Maven repository, with
    metadata, and on the other side of the air gap you list that
    repository in a <repository/> by pathname. Or you maintain a repo
    manager on the secure side of the air gap and you publish it there.
    - 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

    --
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    -                                                               -
    - 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
  • Jason Pyeron at Sep 17, 2011 at 3:54 pm

    -----Original Message-----
    From: Benson Margulies
    Sent: Saturday, September 17, 2011 11:44
    On Sat, Sep 17, 2011 at 11:45 AM, Jason Pyeron wrote:
    -----Original Message-----
    From: Jason van Zyl
    Sent: Saturday, September 17, 2011 11:13
    On Sep 17, 2011, at 11:06 AM, Jason Pyeron wrote:

    -----Original Message-----
    From: Jason van Zyl
    Sent: Saturday, September 17, 2011 10:25

    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.
    Certainly I can. You export it in the form of a Maven
    repository, with metadata, and on the other side of the air
    Is the metadata in the revision? Only export the revision. Defense, Healthcare,
    life safety, large organizations, all of these type of organizations have rules,
    we are trying to make Maven more adaptable so it can be used there on projectes
    where the rules are enforced.
    gap you list that repository in a <repository/> by pathname.
    Then you have a forbiden delta from what is in the official record.
    Or you maintain a repo manager on the secure side of the air
    The repo manager was not in the official record.
    gap and you publish it there.


    --
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    - -
    - 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
  • Manfred Moser at Sep 18, 2011 at 3:39 am

    On 11-09-17 09:00 AM, Jason Pyeron wrote:
    Is the metadata in the revision? Only export the revision. Defense, Healthcare,
    life safety, large organizations, all of these type of organizations have rules,
    we are trying to make Maven more adaptable so it can be used there on projectes
    where the rules are enforced.
    gap you list that repository in a<repository/> by pathname.
    Then you have a forbiden delta from what is in the official record.
    Or you maintain a repo manager on the secure side of the air
    The repo manager was not in the official record.
    gap and you publish it there.
    This whole argument is totally a red herring. You will not be able to
    have all artifacts in the SCM system. At least you have to specify the
    tool chain to actually run the build including operating system, java
    and so on.

    These do not necessary have to be in the SCM system but have to be in
    the official record for the filing.

    It is totally feasible to add a repo manager as just another required
    build tool and add a backup/export of the repository content as part of
    the code that you put on the dvd. You could even just do a clean build
    on a fresh machine and take a copy of the local repo. Or even create a
    virtual machine image with the full setup.

    It will work just fine off the grid. In fact with Maven it will run
    better if you use a repo manager than without..

    I have done that in the past for escrow services in the healthcare
    industry fullfilling all requirements and passing various audits for ISO
    and FDA approval.

    The requirement you cite as part CMMI L3 and such does imho not really
    exist in this strict sense of pure SCM storage. You have to be able to
    do a reproducible build without anything beyond what you supply for
    escrow .. but that has nothing to do with SCM. And if you controlling
    the content of your repository for build reproducability is one of the
    dedicated enterprise features of e.g. Nexus Pro (and others like
    Artifactory).

    Cludging something into Maven itself feels wrong to me.

    manfred
    http://simpligility.com

    PS: also look at e.g. the Debian project and their integration with
    Maven. It all build complete offline since this is part of their
    requirement for bootstirapping so this kind of behaviour is already
    possible.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
    For additional commands, e-mail: dev-help@maven.apache.org
  • Jason Pyeron at Sep 18, 2011 at 3:49 am

    -----Original Message-----
    From: Manfred Moser
    Sent: Saturday, September 17, 2011 23:38
    To: dev@maven.apache.org
    Subject: Re: Request for review and comment
    http://jira.codehaus.org/browse/MNG-5167
    On 11-09-17 09:00 AM, Jason Pyeron wrote:

    Is the metadata in the revision? Only export the revision. Defense,
    Healthcare, life safety, large organizations, all of these type of
    organizations have rules, we are trying to make Maven more adaptable
    so it can be used there on projectes where the rules are enforced.
    gap you list that repository in a<repository/> by pathname.
    Then you have a forbiden delta from what is in the official record.
    Or you maintain a repo manager on the secure side of the air
    The repo manager was not in the official record.
    gap and you publish it there.
    This whole argument is totally a red herring. You will not be
    able to have all artifacts in the SCM system. At least you
    have to specify the tool chain to actually run the build
    including operating system, java and so on.
    And they are in the SCM too ... Look I am not going to argue about what
    organizations should or should not do, nor do or will I care about arguments on
    how it should be changed. I am here providing a patch, and asking for technical
    evaluation on it. There is one simple fact here, and it is there are maven users
    who require this patch. There is two possible outcomes: it gets included in some
    form or it does not. If there are technical issues with the patch I will address
    them. I will no longer argue "political" issues, I will call them out as
    nonsense.
    It is totally feasible to add a repo manager as just another
    required build tool and add a backup/export of the repository
    content as part of the code that you put on the dvd. You
    could even just do a clean build on a fresh machine and take
    a copy of the local repo. Or even create a virtual machine
    image with the full setup.

    It will work just fine off the grid. In fact with Maven it
    will run better if you use a repo manager than without..

    I have done that in the past for escrow services in the
    healthcare industry fullfilling all requirements and passing
    various audits for ISO and FDA approval.

    The requirement you cite as part CMMI L3 and such does imho
    not really exist in this strict sense of pure SCM storage.
    You have to be able to do a reproducible build without
    anything beyond what you supply for escrow .. but that has
    nothing to do with SCM. And if you controlling the content of
    your repository for build reproducability is one of the
    dedicated enterprise features of e.g. Nexus Pro (and others
    like Artifactory).

    Cludging something into Maven itself feels wrong to me.
    What part of the patch is cludgy, I would like to fix it.
    manfred
    http://simpligility.com

    PS: also look at e.g. the Debian project and their
    integration with Maven. It all build complete offline since
    this is part of their requirement for bootstirapping so this
    kind of behaviour is already possible.

    --
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    - -
    - 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
  • Manfred Moser at Sep 18, 2011 at 4:24 am

    On 11-09-17 08:55 PM, Jason Pyeron wrote:
    -----Original Message-----
    From: Manfred Moser
    Sent: Saturday, September 17, 2011 23:38
    To: dev@maven.apache.org
    Subject: Re: Request for review and comment
    http://jira.codehaus.org/browse/MNG-5167
    On 11-09-17 09:00 AM, Jason Pyeron wrote:
    Is the metadata in the revision? Only export the revision. Defense,
    Healthcare, life safety, large organizations, all of these type of
    organizations have rules, we are trying to make Maven more adaptable
    so it can be used there on projectes where the rules are enforced.
    gap you list that repository in a<repository/> by pathname.
    Then you have a forbiden delta from what is in the official record.
    Or you maintain a repo manager on the secure side of the air
    The repo manager was not in the official record.
    gap and you publish it there.
    This whole argument is totally a red herring. You will not be
    able to have all artifacts in the SCM system. At least you
    have to specify the tool chain to actually run the build
    including operating system, java and so on.
    And they are in the SCM too ... Look I am not going to argue about what
    organizations should or should not do, nor do or will I care about arguments on
    how it should be changed. I am here providing a patch, and asking for technical
    evaluation on it. There is one simple fact here, and it is there are maven users
    who require this patch. There is two possible outcomes: it gets included in some
    form or it does not. If there are technical issues with the patch I will address
    them. I will no longer argue "political" issues, I will call them out as
    nonsense.
    It is totally feasible to add a repo manager as just another
    required build tool and add a backup/export of the repository
    content as part of the code that you put on the dvd. You
    could even just do a clean build on a fresh machine and take
    a copy of the local repo. Or even create a virtual machine
    image with the full setup.

    It will work just fine off the grid. In fact with Maven it
    will run better if you use a repo manager than without..

    I have done that in the past for escrow services in the
    healthcare industry fullfilling all requirements and passing
    various audits for ISO and FDA approval.

    The requirement you cite as part CMMI L3 and such does imho
    not really exist in this strict sense of pure SCM storage.
    You have to be able to do a reproducible build without
    anything beyond what you supply for escrow .. but that has
    nothing to do with SCM. And if you controlling the content of
    your repository for build reproducability is one of the
    dedicated enterprise features of e.g. Nexus Pro (and others
    like Artifactory).

    Cludging something into Maven itself feels wrong to me.
    What part of the patch is cludgy, I would like to fix it.
    The patch by itself might not be but in my feeling it goes against the
    general design of Maven and might have problems associated to it in
    various use cases beyond your specific example

    Taking on the patch means providing documentation for it and support
    into the future and around use cases others come up with together with
    plugins and so on. At a minimum I would suggest to have that all done as
    well as some IT tests around it.

    I can see this feature being used by a lot of people coming from manual
    dependency management and never actually getting the benefits of Maven
    due to being stuck with this approach since that is how they started.

    just my 2c though..

    manfred




    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
    For additional commands, e-mail: dev-help@maven.apache.org
  • Jason Pyeron at Sep 18, 2011 at 4:40 am

    -----Original Message-----
    From: Manfred Moser
    Sent: Sunday, September 18, 2011 0:24
    To: Maven Developers List
    Subject: Re: Request for review and comment
    http://jira.codehaus.org/browse/MNG-5167
    On 11-09-17 08:55 PM, Jason Pyeron wrote:
    -----Original Message-----
    From: Manfred Moser
    Sent: Saturday, September 17, 2011 23:38
    To: dev@maven.apache.org
    Subject: Re: Request for review and comment
    http://jira.codehaus.org/browse/MNG-5167
    <snip/>
    Cludging something into Maven itself feels wrong to me.
    What part of the patch is cludgy, I would like to fix it.
    The patch by itself might not be but in my feeling it goes
    against the general design of Maven and might have problems
    associated to it in various use cases beyond your specific example

    Taking on the patch means providing documentation for it and
    support into the future and around use cases others come up
    with together with plugins and so on. At a minimum I would
    suggest to have that all done as well as some IT tests around it.
    Thank you. I have been struggling on the tests aspect, do you have any
    recommendations? I will create better documentation too.
    I can see this feature being used by a lot of people coming
    from manual dependency management and never actually getting
    the benefits of Maven due to being stuck with this approach
    since that is how they started.
    Agreed, I will try to show how to leverage maven in the maven way too (prevent
    anti-patterns)

    -Jason

    --
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    - -
    - 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
  • Hervé BOUTEMY at Sep 18, 2011 at 5:26 am
    with ${maven.home}, you can have your use case

    for other options:
    - POM is a nonsense to me
    - WORKINGDIRECTORY too: notice that it can be done with ${user.dir}, if you
    really want to

    the more I'm thinking at this, the more I'm convinced we should not accept
    relative path at all: with java system properties, you already have a lot of
    choice (user.home, user.dir, maven.home). And if you really want something
    more flexible, just define a convention in your organization to set an
    environment variable that is required

    but adding a feature to Maven for that is an anti-pattern IMHO

    Just for the record, if you provide a patch, please have a look at code
    conventions [1], and IDE configurations to have them directly done by your IDE

    Regards

    Hervé

    [1] http://maven.apache.org/developers/conventions/code.html

    Le dimanche 18 septembre 2011, Jason Pyeron a écrit :
    -----Original Message-----
    From: Manfred Moser
    Sent: Sunday, September 18, 2011 0:24
    To: Maven Developers List
    Subject: Re: Request for review and comment
    http://jira.codehaus.org/browse/MNG-5167
    On 11-09-17 08:55 PM, Jason Pyeron wrote:
    -----Original Message-----
    From: Manfred Moser
    Sent: Saturday, September 17, 2011 23:38
    To: dev@maven.apache.org
    Subject: Re: Request for review and comment
    http://jira.codehaus.org/browse/MNG-5167
    <snip/>
    Cludging something into Maven itself feels wrong to me.
    What part of the patch is cludgy, I would like to fix it.
    The patch by itself might not be but in my feeling it goes
    against the general design of Maven and might have problems
    associated to it in various use cases beyond your specific example

    Taking on the patch means providing documentation for it and
    support into the future and around use cases others come up
    with together with plugins and so on. At a minimum I would
    suggest to have that all done as well as some IT tests around it.
    Thank you. I have been struggling on the tests aspect, do you have any
    recommendations? I will create better documentation too.
    I can see this feature being used by a lot of people coming
    from manual dependency management and never actually getting
    the benefits of Maven due to being stuck with this approach
    since that is how they started.
    Agreed, I will try to show how to leverage maven in the maven way too
    (prevent anti-patterns)

    -Jason

    --
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    - -
    - 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
  • Hervé BOUTEMY at Sep 17, 2011 at 4:33 pm
    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
    --
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    - -
    - 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
  • Jason Pyeron at Sep 17, 2011 at 5:24 pm

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriesmaven
postedAug 26, '11 at 10:07p
activeSep 18, '11 at 5:26a
posts19
users7
websitemaven.apache.org
irc#maven

People

Translate

site design / logo © 2021 Grokbase