RE: Maven intern projects
> -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
> -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
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
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
-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
-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
-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
-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
-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
-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
-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
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...
.
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
+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
-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
-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?
-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
-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
-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
-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
-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
-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
-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
-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
-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
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?
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
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
