You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2011/09/17 16:24:58 UTC
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
- 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
RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Hervé BOUTEMY <he...@free.fr>.
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
Re: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Hervé BOUTEMY <he...@free.fr>.
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
RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----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
Re: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Manfred Moser <ma...@mosabuam.com>.
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
RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----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
Re: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Manfred Moser <ma...@mosabuam.com>.
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
RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----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
Re: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Benson Margulies <bi...@gmail.com>.
On Sat, Sep 17, 2011 at 11:45 AM, Jason Pyeron <jp...@pdinc.us> 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
>> >> 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
RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----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
RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----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
RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----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
Re: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Mark Derricutt <ma...@talios.com>.
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.
Re: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Benson Margulies <bi...@gmail.com>.
>> 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
Re: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Stephane Nicoll <st...@gmail.com>.
Hi,
On Sat, Sep 17, 2011 at 5:12 PM, Jason van Zyl <ja...@maven.org> 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.)
>
>
>
>
Re: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Jason van Zyl <ja...@maven.org>.
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.)
RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----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