RE: Maven intern projects

2020-04-13 Thread Jason Pyeron
> -Original Message-
> From: Markus KARG
> Sent: Monday, April 13, 2020 1:44 PM
> 
> What users finally expect is to have multirelease JAR building being a Maven 
> native
> functionality. This means, it should be as-easy-as putting code in these 
> folders:
> 
> src/main/java/9/
> src/main/java/
> src/main/java/11/

JEP 238 does not require any specific source folder organization. Please do not 
step on 
the contents of the /java/ folder. You can accomplish the same with /java/ | 
/java.9/ | /java.11/ .

Doing so will break many, many assumptions those have made in many, many 
existing packages.

In fact, for those already having large multi release source trees, having POM 
properties to 
specify the java version source folders would be handy.

> 
> then perform
> 
> mvn clean package
> 
> to get a multi-release jar -- without *any* special switches, config, or 
> POM.xml tweaking,
> and *all* maven-*-plugins will perform the necessary steps on their own (e. 
> g. compiler
> runs multiple times as the compiler plugins knows this is needed when it sees
> /java/number/ folders).

I concur, strongly, otherwise.

> 
> -Markus

-Jason


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



RE: FYI: on exotic nodes for our CI

2017-03-16 Thread Jason Pyeron
> -Original Message-
> From: Michael Osipov 
> 
> Am 2017-03-16 um 13:39 schrieb Stephen Connolly:
> > https://reference.apache.org/committer/node-hosting
> >
> > So if somebody really feels that we need exotic node types... and is
> > willing to provide such a node and hook it up...
> 
> This is somewhat ridiculous. Exotic is HP-UX or AIX, but 
> CentOS, Solaris 
> and *BSD are mainstream.
> 
> Consider that we invest our free/work time to make this 
> project better I 
> see no reason to add hardware at my expense. In fact, most companies 
> (including mine) wouldn't even be able to provide nodes 
> because company 
> network is behind a VPN.

Huh, the link is bad on the page. I guess nuderscores are exotic too. 

https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=blobplain;f=modules/buildslaves/files/jenkins.pub;hb=HEAD

Should be:

https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=blob_plain;f=modules/build_slaves/files/jenkins.pub;hb=HEAD



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



RE: on exotic nodes for our CI

2017-03-16 Thread Jason Pyeron
Cool info. 

But I seriously thought this was a spam message the first 3 times I read it. 

Subject exotic - check
link - check
1 sentence body - check

> -Original Message-
> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
> Sent: Thursday, March 16, 2017 08:39
> To: Maven Developers List
> Subject: FYI: on exotic nodes for our CI
> 
> https://reference.apache.org/committer/node-hosting
> 
> So if somebody really feels that we need exotic node types... and is
> willing to provide such a node and hook it up...
> 


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



Logging for 3.0.x and >=3.1.0

2016-11-23 Thread Jason Pyeron
Working on a plugin right now and it needs to work in 3.0 as well as 3.3.

Scratching my head on can we use slf4j in 3.0 or is there a backwards 
compatibility logic to put in.

-Jason

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 



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



RE: Default Maven Compiler Version

2015-06-18 Thread Jason Pyeron
 -Original Message-
 From: Manfred Moser [mailto:manf...@mosabuam.com] 
 Sent: Thursday, June 18, 2015 12:21 AM
 To: dev@maven.apache.org
 Subject: Re: Default Maven Compiler Version
 
 Yes... a corporate or some other higher level pom is 

I think some detail was missed in the OP's question.

It is not that he always wants version X. It is he wants the default to be
the version in the path for each system.

In other words: On system A it should be java version A on system B it
should be java version B, etc.

Maybe start with this idea:

properties
  maven.compiler.source${java.version}/maven.compiler.source
  maven.compiler.target${java.version}/maven.compiler.target
/properties

Now I know that ${java.version} is likley to have some cruft in it, but
someone better than I can come up with a way to strip out the 1.x from the
java.version.


 typically how you configure this across lots of projects. But 
 even if you dont ... its two lines of config on the compiler plugin.
 
 Manfred
 
 Sander Verhagen wrote on 17.06.2015 15:16:
 
  I wonder if this would be a good candidate for a corporate POM that 
  deals with this kind of configuration?
  
  
  
  Sander Verhagen
  [  san...@sanderverhagen.net  ]
  
  NOTICE: my e-mail address has changed. You may still e-mail me at 
  verha...@sander.com but you will see me using 
  san...@sanderverhagen.net from now on. Feel free to update 
 your address book.
  
  -Original Message-
  From: Mangold, Kevin C. [mailto:kevin.mang...@nist.gov]
  Sent: Wednesday, June 17, 2015 12:55
  To: dev@maven.apache.org
  Subject: Default Maven Compiler Version
  
  Why does the maven compiler plugin STILL target 1.5 by default and 
  not the JDK's current version? This seems completely backwards. We 
  use CI tools to test against different JDK versions and 
 architectures 
  and it is a massive pain to implement all these 
 workarounds to have 
  the compiler target each JDK's respective version.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 


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



RE: Codehaus JIRA EOL

2015-03-01 Thread Jason Pyeron
 -Original Message-
 From: Of Anders Hammar
 Sent: Sunday, March 01, 2015 3:41
 
 Just a heads up that the Codehaus services are coming to an 
 end, see [1].
 As there already was an discussion about moving our JIRA 
 projects, we now
 have a deadline for that, in May if I read the info correctly.
 
 [1] http://www.codehaus.org/

The end of another era. They will be missed.

-Jason

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00. 


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



RE: JIRA

2014-12-28 Thread Jason Pyeron
 -Original Message-
 From: Hervé BOUTEMY 
 Sent: Sunday, December 28, 2014 18:27
 
 if I count from 
 http://jira.codehaus.org/secure/BrowseProjects.jspa#all
 taking relevant projects from Maven 2 Plugins, Maven 
 Admin and Maven 
 Technologies categories, I get 61 projects

I just got 244.

83 Maven 1 Plugins
114 Maven 2 Plugins
6 Maven Admin
26 Maven Technologies
15 No Category (GMAVENPLUS, MNGIDEA, MTOMCAT, MVNBLAME, MVNCONFSITE, 
MAVENENTERPRISE, PSEUDOTRANS, MDWEB, MDBUNIT, MWEBLOGIC, MOPENJPA, MSITESKIN, 
MTRUEZIP, MUNIX, UMP)

 
 Hope this helps :)
 
 Regards,
 
 Hervé
 
 Le dimanche 28 décembre 2014 18:13:45 Benson Margulies a écrit :
  infra@ asks: _exactly_ how many projects. Does anyone know off hand?
  
  On Sun, Dec 28, 2014 at 1:13 AM, Barrie Treloar 
 baerr...@gmail.com wrote:
   On 28 December 2014 at 08:46, Jason van Zyl 
 ja...@takari.io wrote:
   Would certainly be easier to have it at Apache at this 
 point. I don't
   think it's particularly hard, just time consuming. I 
 think the only safe
   option is exporting the entire database and removing all 
 projects except
   ours. It will probably take several attempts and there 
 are a lot of
   projects at Codehaus in that JIRA instance. I've tried 
 moving individual
   projects with the RPC mechanism and generally doesn't 
 work all that well.
   
   Perhaps someone who has done this before enough times if 
 willing to step
   forward?
   Or can we lean on Atlassian?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00. 


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



RE: JIRA projects for Maven

2014-12-28 Thread Jason Pyeron

 -Original Message-
 From: Benson Margulies 
 Sent: Sunday, December 28, 2014 21:52
 
 On Sun, Dec 28, 2014 at 9:18 PM, David Nalley da...@gnsa.us wrote:
  On Sat, Dec 27, 2014 at 11:37 AM, Benson Margulies
  bimargul...@gmail.com wrote:
  Dear Infra,
 
  For historical reasons, the Maven project has a host of 
 JIRA projects
  at codehaus. This is not an ideal situation for many reasons.
 
  In the past, discussions on moving onto ASF infrastructure have
  founded on the sheer number: dozens. Infrastructure didn't 
 feel that
  they could support that many project, and the Maven 
 project felt that
  it would be very difficult to combine all of the many 
 per-maven-plugin
  JIRA projects into a single project with many components.
 
 
  Can you tell me why it would be difficult? E.g. I am envisioning a
  single maven project, an each plugin has a component instead of a
  separate project.
 
 David, I've restored dev@maven to this thread. I suspect that others
 may be more eloquent than I on this; if no one else joins in, I'll
 expand tomorrow some time.
 
 
  It seems to me that much has changed since the last time that this
  subject was explored, so I felt that it was worth re-opening the
  discussion. Could the existing main JIRA support a large influx of
  low-activity projects? Or would infra consider a separate instance?
 
 
  The number of projects is not a huge issue. Jira can support many
  magnitudes more 'projects' than we currently have.
 
  Migrating 61 low-activity projects seems like a lot of work;
  historically, that's involved dumping to XML, potentially 
 deploying to
  a matching version of the source, and then upgrading the version to
  match the destination version of Jira, then exporting again and
  deploying to the destination version. Generally (depending 
 on the way
  the restore happens) the ticket numbers may not stay the same.
  Historically, we've had a lot of frustration on this front 
 when we've
  attempted migrations. Though generally they tend to be larger
  migrations.
 
  That said, how much of this work is Maven willing to bear?
 
  --David

I have some spare cycles right now to tackle this.

-Jason

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00. 


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



RE: JIRA

2014-12-27 Thread Jason Pyeron
 -Original Message-
 From: Benson Margulies 
 Sent: Saturday, December 27, 2014 13:01
 
 On Sat, Dec 27, 2014 at 12:57 PM, Karl Heinz Marbaise 
 khmarba...@gmx.de wrote:
  Hi Benson,
 
  On 12/27/14 5:59 PM, Benson Margulies wrote:
 
  On Sat, Dec 27, 2014 at 11:45 AM, Michael Osipov 
 micha...@apache.org
  wrote:
 
  Am 2014-12-27 um 17:38 schrieb Benson Margulies:
 
 
  I've re-asked infra if there is any possible path to 
 moving all the
  JIRA projects to ASF infrastructure. I'll report back.
 
 
 
snip/
 
  In the past, there was some consideration of
 
  squashing all the plugin projects into one with 
 components; that would
  be a painful transition.
 
 
  Not that it will be painful... it will result in loosing 
 the overview of the
  individual projects cause we have different maintainers for 
 different
  plugins etc.
 
 I am not an advocate, but I think that the codehaus situation is
 intolerable. Let's hope that infra is willing to take on all the
 individual projects, rather than consume brain cells on what we do if
 they aren't.
 
 
 
  If Infra still can't accommodate all the
 
  individual projects I think we should reconsider it.
 

IIRC JIRA is more efficient with less tickets per project and more projects 
than less projects with more tickets. This comes from experience on huge a 
USCYBERCOM JIRA install.

-Jason


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



RE: Maven ear plugin

2014-05-21 Thread Jason Pyeron
 -Original Message-
 From: Maciek Karas  
 Sent: Wednesday, May 21, 2014 6:47
 
 Hi.
 
 I found bug or at least missing feature in maven ear plugin. 
 I tried to
 submit it in JIRA http://jira.codehaus.org/browse/MEAR but I 
 don't have account there. 

To create an account http://xircles.codehaus.org/signup

-Jason

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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



RE: Let's fix the Rat Check usability fail

2014-05-18 Thread Jason Pyeron
 -Original Message-
 From: Jason van Zyl 
 Sent: Sunday, May 18, 2014 13:05
 
 Right now though we require all files to have license headers 
 we do not run the check to verify this by default.
 

Can it be turned off by option?

 It kept dinging me until I turned it on by default in Maven 
 core. Someone currently trying to contribute has no idea this 
 is a requirement and is not told so because it doesn't run by 
 default. If it's required how about we just run all the time 
 everywhere?

What phase? 

 
 I would like to change the POMs so that it always runs. 
 Having to run RAT separately is a usability fail. The chances 
 of anyone contributing knowing they have to run it are pretty 
 close to zero.
 
 Anyone see a reason not to always run it?

How much time do they take (add)?

-Jason

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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



RE: [jira] (MNG-5167) relative local repository settings

2014-01-29 Thread Jason Pyeron
This was closed as won't fix.

This is still something that is of high value. Can the close comment be more
substantiated and it be migrated to apache?

Respectfully,

Jason Pyeron

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 

 -Original Message-
 From: Jason van Zyl (JIRA) [mailto:j...@codehaus.org] 
 Sent: Sunday, January 19, 2014 14:36
 To: jpye...@pdinc.us
 Subject: [jira] (MNG-5167) relative local repository settings
 
 
  [ 
 https://jira.codehaus.org/browse/MNG-5167?page=com.atlassian.j
ira.plugin.system.issuetabpanels:all-tabpanel ]
 
 Jason van Zyl closed MNG-5167.
 --
 
 Resolution: Won't Fix
 
  relative local repository settings
  --
 
  Key: MNG-5167
  URL: https://jira.codehaus.org/browse/MNG-5167
  Project: Maven 2  3
   Issue Type: New Feature
   Components: Settings
 Affects Versions: 3.0.3, 3.0.4
 Reporter: Jason Pyeron
 Assignee: Jason van Zyl
  Attachments: MNG-5167.patch
 
 
  see patch
 
 --
 This message is automatically generated by JIRA.
 If you think it was sent incorrectly, please contact your 
 JIRA administrators For more information on JIRA, see: 
 http://www.atlassian.com/software/jira
 
 


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



RE: Plugin phase awareness...

2013-12-25 Thread Jason Pyeron
.
   Just skim the javadoc comments.
  
  
   HTH,
   ~t~
  
  
   On Sat, Dec 21, 2013 at 3:27 PM, Igor Fedorenko 
   i...@ifedorenko.com
   wrote:
  
   Something like this should do the trick
  
   @Parameter(defaultValue = ${mojoExecution.lifecyclePhase})
   private String executionPhase;
  
   other magic properties available to mojos are 
 documented in 
   [1]
  
   [1] http://maven.apache.org/ref/3.1.1/maven-core/apidocs/org/
   apache/maven/plugin/PluginParameterExpressionEvaluator.html
  
   --
   Regards,
   Igor
  
  
  
   On 12/21/2013, 3:52, Lennart Jörelid wrote:
  
   Hello all,
  
   How can a running Mojo query the Maven API (or some 
 other API) 
   to
   find out
   which Maven Phase it has been invoked in? Something like ...
  
   String currentPhase = 
   getSomeMavenApiHelper().getCurrentPhase();
  
   --
   +==+
   | Bästa hälsningar,
   | [sw. Best regards]
   |
   | Lennart Jörelid
   | EAI Architect  Integrator
   |
   | jGuru Europe AB
   | Mölnlycke - Kista
   |
   | Email: l...@jguru.se
   | URL: www.jguru.se
   | Phone
   | (skype): jgurueurope
   | (intl): +46 708 507 603
   | (domestic): 0708 - 507 603
   +==+
  
  
   
 ---
   -- To unsubscribe, e-mail: 
 dev-unsubscr...@maven.apache.org 
   For additional commands, e-mail: dev-h...@maven.apache.org
  
  
  
  
  
  
  
   --
  
   --
   +==+
   | Bästa hälsningar,
   | [sw. Best regards]
   |
   | Lennart Jörelid
   | EAI Architect  Integrator
   |
   | jGuru Europe AB
   | Mölnlycke - Kista
   |
   | Email: l...@jguru.se
   | URL: www.jguru.se
   | Phone
   | (skype): jgurueurope
   | (intl): +46 708 507 603
   | (domestic): 0708 - 507 603
   +==+
  
   
  
  
  
 -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For 
  additional commands, e-mail: dev-h...@maven.apache.org
  
 

 
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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



RE: [VOTE] Move Maven projects sources to git

2012-09-05 Thread Jason Pyeron
+1 I/we can volunteer.

 -Original Message-
 From: Stephane Nicoll [mailto:stephane.nic...@gmail.com] 
 Sent: Wednesday, September 05, 2012 9:21
 To: Maven Developers List
 Subject: Re: [VOTE] Move Maven projects sources to git
 
 +0
 
 S.
 
 On Wed, Sep 5, 2012 at 1:04 PM, Olivier Lamy ol...@apache.org wrote:
  Hi,
  This vote is to decide moving our source tree currently 
 located in one 
  svn repository to git (multiple git repositories).
  First, we need to have at least 3 volunteers to help on 
 Apache infra 
  for this move and more generally on git Apache 
 infrastructure. (if you 
  are volunteer you must say that with your vote).
  The vote will pass on majority (PMC committer) and if we have the 
  minimum of 3 volunteers !
  BTW contributors can express their opinion by a vote too !
  The vote will decide on moving all the source tree  
 (volunteers time 
  will the main throttle).
 
  Volunteers will decide on what they move (notification on 
 dev@ is mandatory).
  The goal is to move simple projects first(scm,surefire, 
 indexer,core, 
  wagon etc..) then plugins (except if Kristian want to start with 
  plugins immediately :-) )
 
  Vote open for 72H.
 
  [+1] Move to git scm
  [0] No interest
  [-1] don't move to git (please explain why)
 
 
  Thanks,
  --


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.


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



RE: Git as the canonical SCM

2012-09-04 Thread Jason Pyeron
 -Original Message-
 From: Jason van Zyl 
 Sent: Tuesday, September 04, 2012 15:55
 
 How's Git doing at Apache these days?
 
 Anyone interested in pursuing putting Maven in Git as the 
 canonical SCM?

Comments from the peanut gallery: It would make it very nice to contribute back.
Since I do not have a sandbox access I have thrown away fixes because there was
no efficient way to track them until they were accepted as patches. (same
problem in struts, commons, ...)

We would be very happy here at PD Inc if that was done.

-Jason Pyeron

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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



RE: how to obtain project class-path with all his dependencies

2012-04-30 Thread Jason Pyeron
 -Original Message-
 From: Tony Chemit 
 Sent: Monday, April 30, 2012 6:30
 
 Hi,
 
 I'd like to know if there is an existing helper code to 
 obtain for a given scope a fresh class-path containing all 
 dependencies of a maven module.

Could be misunderstanding you, but googling dependency classpath gets me
http://maven.apache.org/plugins/maven-dependency-plugin/build-classpath-mojo.htm
l



--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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



RE: RPMs for Maven 3?

2012-03-18 Thread Jason Pyeron
 -Original Message-
 From: Jos Backus [mailto:j...@catnook.com] 
 Sent: Thursday, March 15, 2012 16:04
 To: dev@maven.apache.org
 Subject: RPMs for Maven 3?
 
 Hi,
 
 I'm trying to install Maven 3 in automatically generated 
 CentOS VM images, and having Maven 3 and plugins available as 
 RPMs would help greatly with this effort.
 
 How hard would it be to augment the CI setup that creates the 
 Maven packages today to also generate RPMs for RHEL/CentOS? 

Should not be to hard, there are rpm building tools for mote platforms and if
you can execute a shell script in your CI then you can do it.


 Perhaps the Maven RPM plugin 
 (http://mojo.codehaus.org/rpm-maven-plugin/) can be used for 
 this purpose?
 
 I looked at jpackage.org but the latest Maven version there 
 is too old (2.0.7).
 
 Thanks,
 Jos
 --
 Jos Backus
 jos at catnook.com
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For 
 additional commands, e-mail: dev-h...@maven.apache.org
 


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.


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



RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167

2011-09-17 Thread Jason Pyeron
 -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: 


settingslocalRepositoryRelativeToM2_HOME/localRepositoryRelativeTolocalRe
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=279221page=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 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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



RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167

2011-09-17 Thread Jason Pyeron
 -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: 
  
  
  
 settingslocalRepositoryRelativeToM2_HOME/localRepositoryRelativeT
  olocalRe
  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=279221page
  =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 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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



RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167

2011-09-17 Thread Jason Pyeron
 -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 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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



RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167

2011-09-17 Thread Jason Pyeron
 -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 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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



RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167

2011-09-17 Thread Jason Pyeron
 -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:
   
 settingslocalRepositoryRelativeToM2_HOME/localRepositoryRelativ
   eT
   
olocalRe
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=279221pa
   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

RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167

2011-09-17 Thread Jason Pyeron
 -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 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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



RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167

2011-09-17 Thread Jason Pyeron
 -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 arepository/  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 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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



RE: Request for review and comment http://jira.codehaus.org/browse/MNG-5167

2011-09-17 Thread Jason Pyeron
 -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 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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



Maven Dependency Plugin

2011-09-12 Thread Jason Pyeron
What is the likelyhood of significant new features being accepted?

On my hit list are the following:

* a usable listing of all dependencies and/or plugins 
** the current list does not list plugins
** the resolve-plugins does not list groupid, artifactid, etc
** might just be a list-plugins

* a repo purge candidates listing
** it would list all items found in the repo not consumed by the project (think
go-offline)
** could be called shrink-local-repository
*** should take the results from one execution as input to another execution to
cascade filter the removal candidates list.
*** Ex: 

cd /project1  mvn dependency:shrink-local-repository
-DinputFile=/tmp/purgablelist.txt -DoutputFile=/tmp/purgablelist.txt 
cd /project2  mvn dependency:shrink-local-repository
-DinputFile=/tmp/purgablelist.txt -DoutputFile=/tmp/purgablelist.txt 
mvn dependency:shrink-local-repository -DinputFile=/tmp/purgablelist.txt
-Dpurge=true

-Jason 



--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.



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



Why is the jira for maven at codehaus.org?

2011-08-29 Thread Jason Pyeron
Why is the jira for maven at codehaus.org and not apache.org?

-Jason

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.



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



Request for review and comment http://jira.codehaus.org/browse/MNG-5167

2011-08-26 Thread Jason Pyeron
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 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.



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