Re: Release of Maven Indexer 5.0
That's exactly what I think too!! Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Manfred Moser manf...@mosabuam.com To: Maven Developers List dev@maven.apache.org Sent: Thursday, September 13, 2012 7:04:09 AM Subject: Re: Release of Maven Indexer 5.0 On Wed, September 12, 2012 6:06 pm, Chris Graham wrote: On Wed, Sep 12, 2012 at 9:46 PM, Anders Hammar and...@hammar.net wrote: I fully agree with you and I'm actually of the opinion that the Java community has a responsibility to provide enough reasons for those on older Java platforms to upgrade. But as long as we provide libraries Simple. Two reasons actually. Without going off on an essay about the psychology of developers and being obsessed with shiny new things (and a Dev centric view of the world)... 1. Cost. 2. Especially in the corporate world, they are far more concerned with function rather than form (ie the underlying technology). In short, if it works, leave it. Which also relates to #1. Case in point: My current project is a multi million dollar one that is *finally* moving from 5-7 YO tech to the newest stack. Partly due to the support issues, but mostly due to the cost of support of the older versions; it's finally become cheaper to upgrade than to continue paying the huge support costs. But my basic point is, that the act of upgrading large systems is not a cheap one, so it is NOT done lightly. I think that the cost is only so high because companies keep waiting until it is too painful. If you constantly keep upgrading a bit here and there and stay up to date with your operating systems, runtime environments, browsers and client site frameworks and so on you would actually be able to save a LOT of money in the long run. But you would have to constantly invest rather than waiting with no investment until things fall apart and then being forced to large costly upgrades. So it is mostly short sighted management and an absence of real technology leadership in organizations causing this problem imho. And forcing the pain to stay on old stuff higher (like Oracle is doing with deprecating Java 6 earlier) is actually a good thing. imho Maven 2 should have long been deprecated and removed from the downloads pages.. just my 2c though ;-) manfred - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Indexer version 5.0.0
+1 2012/9/12 Milos Kleint mkle...@gmail.com: +1 basic testing inside netbeans codebase, all seems to work. Milos On Wed, Sep 12, 2012 at 8:20 PM, Tamás Cservenák ta...@cservenak.net wrote: Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112version=18722 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=12112status=1 Staging repo: https://repository.apache.org/content/repositories/maven-058/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, ~t~ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plan for git migration
Hi, Don't know if we need more complete verifications, but here's what I just found for the release repo at git://git.apache.org/maven-release.git: Using my current box (m3.0.4 / jdk 1.6.0_33), I wrote a simple scripthttps://gist.github.com/3713444 and ran it on the maven-release repo. Summary: Only maven-release-3, maven-release-4 maven-release-5 tags (respectively 2.0-beta6, 7 8) cannot be built (tests failed). The others build just fine. Full builds result can be found here: https://dl.dropbox.com/u/6790263/result-mrelease-build.log So that repo seems to be usable. The failing tags above are for quite old versions (2007) and I guess nobody will ever want to start patching an beta version? If you want, I can also check if svn tags have the same behaviour. Do you think some more checks should be done? If so, just let me know: * building with other JDK versions? other Maven versions? * what else? I think I'll do the same with menforcer repo in the week-end. Cheers 2012/9/12 Kristian Rosenvold kristian.rosenv...@zenior.no We still need some verification that the individual repos are ok. (build an old tag, just look at file trees to see nothing strange happens) You can post that here. Kristian Den 12. s. 2012 kl. 15:55 skrev Olivier Lamy ol...@apache.org: 2012/9/12 Baptiste MATHUS m...@batmat.net: I can try and take care of enforcer release to begin with if no-one objects. But I cannot add myself to the wiki even logged in. I guess the pages are protected to spammers. Thanks for the help. But the task will be relatively easy as we have already clones available for some parts of the svn tree. It's just a question of available time from ASF infra folks (normally already existed volunteers from the project will help too at least I hope :P ) Cheers 2012/9/12 Olivier Lamy ol...@apache.org +1 for keep svn references. FYI I will start migration with moving the following repositories: * surefire * wagon * scm 2012/9/12 Baptiste MATHUS m...@batmat.net: 2012/9/12 Kristian Rosenvold kristian.rosenv...@gmail.com Are you thinking about the svn references etched into each commit ? The current git-svn repos all have this information appended at the end of each commit: git-svn-id: https://svn.apache.org/repos/asf/maven/surefire/trunk@1374642 13f79535-47bb-0310-9956-ffa450edef68 Personally I think we should keep them, since they contain the historical reference to the SVN commit number. And technically we have a lot of jiras referencing r990909 so removing them is not a good idea wrt traceability of changes. +1000. I was about to answer in the same vein. I really think that storing as much information of where a gives path comes from will be very valuable in the future. I cannot understand how one could want to get rid of that informations. Exactly as Kristian said: you have JIRAs, mails, whatever pointing to some revisions and it's always very useful to be able to find that very revision in the Git history. Cheers -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! dev-h...@maven.apache.org
Re: Plan for git migration
I see mention of the current git-mirros of the svn tree. I recommended caution in just using these, or just looking at these as currently they're not used for releases, and there's well known issues with maven/git releases ( single tag/branch repository wide, maven releases only from the root etc. ) With that in mind - is there a document/plan for how the svn repository will be carved up into smaller git repositories for the various different release cadences of projects? On 12/09/2012, at 8:44 PM, Olivier Lamy ol...@apache.org wrote: Hi Folks, So the vote passed, now it's time for volunteers to use their fingers :-). I have started a page [1] for ETA of migration (note the Volunteer column :-) ) and for discussion on some stuff (plugins shared) Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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 Vincent 2012/9/5 Olivier Lamy ol...@apache.org: 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, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release of Maven Indexer 5.0
On Wed, Sep 12, 2012 at 09:04:09PM -0700, Manfred Moser wrote: On Wed, September 12, 2012 6:06 pm, Chris Graham wrote: On Wed, Sep 12, 2012 at 9:46 PM, Anders Hammar and...@hammar.net wrote: I fully agree with you and I'm actually of the opinion that the Java community has a responsibility to provide enough reasons for those on older Java platforms to upgrade. But as long as we provide libraries Simple. Two reasons actually. Without going off on an essay about the psychology of developers and being obsessed with shiny new things (and a Dev centric view of the world)... 1. Cost. 2. Especially in the corporate world, they are far more concerned with function rather than form (ie the underlying technology). In short, if it works, leave it. Which also relates to #1. Case in point: My current project is a multi million dollar one that is *finally* moving from 5-7 YO tech to the newest stack. Partly due to the support issues, but mostly due to the cost of support of the older versions; it's finally become cheaper to upgrade than to continue paying the huge support costs. But my basic point is, that the act of upgrading large systems is not a cheap one, so it is NOT done lightly. I think that the cost is only so high because companies keep waiting until it is too painful. If you constantly keep upgrading a bit here and there and stay up to date with your operating systems, runtime environments, browsers and client site frameworks and so on you would actually be able to save a LOT of money in the long run. But you would have to constantly invest rather than waiting with no investment until things fall apart and then being forced to large costly upgrades. I think this happens because the money you spend on upgrading and the money you save because of it are in two different pots. If you look at the way budgeting works, you might find that the current behavior makes sense -- assuming that you accept that the way budgeting works, makes sense. :-/ So it is mostly short sighted management and an absence of real technology leadership in organizations causing this problem imho. And forcing the pain to stay on old stuff higher (like Oracle is doing with deprecating Java 6 earlier) is actually a good thing. imho Maven 2 should have long been deprecated and removed from the downloads pages.. Tell the distro.s. Gentoo still has Maven 3 keyworded on all arches, and Gentoo is one of the bleeding-edge, daily-updating distro.s. I'll be using M3 for production work the day after they take the ~amd64 keyword off it. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpACPFgTrDoh.pgp Description: PGP signature
Proposal for new git-workspace-plugin
I have just added wiki document to discuss the design of a totally new plugin I have dubbed the git-workspace-plugin. The idea is to change the way we work with layered multi-module projects in git that will make it a whole lot easier for anyone wishing to make a change to do so. The page is at https://cwiki.apache.org/confluence/display/MAVEN/git-workspace-plugin and I would really appreciate any kind of feedback on this. Feel free to edit the page, I will also keep it up to date ;) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release of Maven Indexer 5.0
When one thinks of Linux distros and Java you would better consider Fedora - Maven 3 is there for the last 1.5 years. Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Mark H. Wood mw...@iupui.edu To: dev@maven.apache.org Sent: Thursday, September 13, 2012 4:52:39 PM Subject: Re: Release of Maven Indexer 5.0 On Wed, Sep 12, 2012 at 09:04:09PM -0700, Manfred Moser wrote: On Wed, September 12, 2012 6:06 pm, Chris Graham wrote: On Wed, Sep 12, 2012 at 9:46 PM, Anders Hammar and...@hammar.net wrote: I fully agree with you and I'm actually of the opinion that the Java community has a responsibility to provide enough reasons for those on older Java platforms to upgrade. But as long as we provide libraries Simple. Two reasons actually. Without going off on an essay about the psychology of developers and being obsessed with shiny new things (and a Dev centric view of the world)... 1. Cost. 2. Especially in the corporate world, they are far more concerned with function rather than form (ie the underlying technology). In short, if it works, leave it. Which also relates to #1. Case in point: My current project is a multi million dollar one that is *finally* moving from 5-7 YO tech to the newest stack. Partly due to the support issues, but mostly due to the cost of support of the older versions; it's finally become cheaper to upgrade than to continue paying the huge support costs. But my basic point is, that the act of upgrading large systems is not a cheap one, so it is NOT done lightly. I think that the cost is only so high because companies keep waiting until it is too painful. If you constantly keep upgrading a bit here and there and stay up to date with your operating systems, runtime environments, browsers and client site frameworks and so on you would actually be able to save a LOT of money in the long run. But you would have to constantly invest rather than waiting with no investment until things fall apart and then being forced to large costly upgrades. I think this happens because the money you spend on upgrading and the money you save because of it are in two different pots. If you look at the way budgeting works, you might find that the current behavior makes sense -- assuming that you accept that the way budgeting works, makes sense. :-/ So it is mostly short sighted management and an absence of real technology leadership in organizations causing this problem imho. And forcing the pain to stay on old stuff higher (like Oracle is doing with deprecating Java 6 earlier) is actually a good thing. imho Maven 2 should have long been deprecated and removed from the downloads pages.. Tell the distro.s. Gentoo still has Maven 3 keyworded on all arches, and Gentoo is one of the bleeding-edge, daily-updating distro.s. I'll be using M3 for production work the day after they take the ~amd64 keyword off it. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal for new git-workspace-plugin
Hi, This idea looks nice :-). I imagine you will retrieve scm locations of dependencies from their poms. In such case dependencies can be a mix of scm (git, svn, hg etc..) So I would prefer we try to do something more generic to provide such features for all scms we support with maven scm (hey we have a very generic scm api :-) ). Maybe it's the case and just the plugin name confuse me :-). 2012/9/13 Kristian Rosenvold kristian.rosenv...@gmail.com: I have just added wiki document to discuss the design of a totally new plugin I have dubbed the git-workspace-plugin. The idea is to change the way we work with layered multi-module projects in git that will make it a whole lot easier for anyone wishing to make a change to do so. The page is at https://cwiki.apache.org/confluence/display/MAVEN/git-workspace-plugin and I would really appreciate any kind of feedback on this. Feel free to edit the page, I will also keep it up to date ;) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal for new git-workspace-plugin
You may want to look at PSF files in Eclipse if you want to leverage an existing format. http://wiki.eclipse.org/PSF On Sep 13, 2012, at 7:43 AM, Olivier Lamy wrote: Hi, This idea looks nice :-). I imagine you will retrieve scm locations of dependencies from their poms. In such case dependencies can be a mix of scm (git, svn, hg etc..) So I would prefer we try to do something more generic to provide such features for all scms we support with maven scm (hey we have a very generic scm api :-) ). Maybe it's the case and just the plugin name confuse me :-). 2012/9/13 Kristian Rosenvold kristian.rosenv...@gmail.com: I have just added wiki document to discuss the design of a totally new plugin I have dubbed the git-workspace-plugin. The idea is to change the way we work with layered multi-module projects in git that will make it a whole lot easier for anyone wishing to make a change to do so. The page is at https://cwiki.apache.org/confluence/display/MAVEN/git-workspace-plugin and I would really appreciate any kind of feedback on this. Feel free to edit the page, I will also keep it up to date ;) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Release of Maven Indexer 5.0
On Thu, September 13, 2012 6:52 am, Mark H. Wood wrote: On Wed, Sep 12, 2012 at 09:04:09PM -0700, Manfred Moser wrote: I think that the cost is only so high because companies keep waiting until it is too painful. If you constantly keep upgrading a bit here and there and stay up to date with your operating systems, runtime environments, browsers and client site frameworks and so on you would actually be able to save a LOT of money in the long run. But you would have to constantly invest rather than waiting with no investment until things fall apart and then being forced to large costly upgrades. I think this happens because the money you spend on upgrading and the money you save because of it are in two different pots. If you look at the way budgeting works, you might find that the current behavior makes sense -- assuming that you accept that the way budgeting works, makes sense. :-/ Most of the time budgeting is also short sighted and without leadership.. so I dont accept that it makes sense .. sorry ;-) So it is mostly short sighted management and an absence of real technology leadership in organizations causing this problem imho. And forcing the pain to stay on old stuff higher (like Oracle is doing with deprecating Java 6 earlier) is actually a good thing. imho Maven 2 should have long been deprecated and removed from the downloads pages.. Tell the distro.s. Gentoo still has Maven 3 keyworded on all arches, and Gentoo is one of the bleeding-edge, daily-updating distro.s. I'll be using M3 for production work the day after they take the ~amd64 keyword off it. Dont use the package supplied by the distro then. Use the upstream release. manfred - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Wierd archive deployed?
I had trouble working on the javadoc plugin in IntelliJ, and this response came back from their support person. What's special about this artifact? Should I see if making a new release will fix it? Quote starts here: This issue occurs because ...\.m2\repository\org\apache\maven\maven-toolchain\1.0\maven-toolchain-1.0.jar file has some weird archive format that IDEA cannot read: http://dl.dropbox.com/u/2752840/screens/snap2142-1347566987.png . If you look inside this jar with any external unpacker, you'll find that it contains empty file entries that match directories. So it's some Maven packaging issue that affects IDEA ability to properly read this jar. I don't think that we'll want to invest resources into fixing this issue, it should be rather fixed in the Maven repository. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal for new git-workspace-plugin
We will definitely be using the scm locations from the POM, combined with some dark magics on resolving where the project is located (think maven-plugins with multiple projects sharing the same root). Mark has tried explaining this algorithm on irc several times, but my eyes go watery every time. This time I suppose I'll have to find out ;=) The problem I see with supporting multiple different SCMs is that at some point their model breaks down, and at some point quite fundamentally. Let me get into a very subtle detail: When you have multiple top-level project sharing plexus-utils and you run a command like mvn git-snapshot plexus-utils (inside surefire) I think what really needs to be done is git checkout -tb surefire-snapshot origin/master; in other words we create a branch that represents the changes done in context of surefire. When you run the corresponding mvn git-snapshot plexus-utils inside the maven-jar-plugin, you probably create a branch for the changes in context of jar-plugin. If you do that, you can basically be in a position to ALWAYS be able to switch contexts (I can resume working on my jar-plugin changes while being in mid-progress on the surefire changes). You can just auto-commit and change branch The clue here is that this is the plexus-utils clone will have one branch tracking head for each top-level project, as well as the master branch from asf. Now this is the stuff git is built for; I can pick changes between the branches like cherries from an autumn tree. The only way I can map this onto subversion involves making a number of distinct checkouts of the same project (tags, trunk and feature branches); I think this is a receipe for disaster. So while I should be able to check out svn projects, I'm afraid the feature set of the plugin I want to make is not very adaptable/valuable in svn. We *will* of course use maven-scm; and I'm sure the smart people here will come up with some models that allow this plugin to be useful for svn too ;) I'm sure we'd work well with hg. Since no code has been written yet, we're free to call it what we want ;) I added a section on GITHUB support to the end of the wiki page Kristian 2012/9/13 Olivier Lamy ol...@apache.org: Hi, This idea looks nice :-). I imagine you will retrieve scm locations of dependencies from their poms. In such case dependencies can be a mix of scm (git, svn, hg etc..) So I would prefer we try to do something more generic to provide such features for all scms we support with maven scm (hey we have a very generic scm api :-) ). Maybe it's the case and just the plugin name confuse me :-). 2012/9/13 Kristian Rosenvold kristian.rosenv...@gmail.com: I have just added wiki document to discuss the design of a totally new plugin I have dubbed the git-workspace-plugin. The idea is to change the way we work with layered multi-module projects in git that will make it a whole lot easier for anyone wishing to make a change to do so. The page is at https://cwiki.apache.org/confluence/display/MAVEN/git-workspace-plugin and I would really appreciate any kind of feedback on this. Feel free to edit the page, I will also keep it up to date ;) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal for new git-workspace-plugin
IntelliJ would work very happily with just a pom file aggregating pom; which in this case would be just a modules list. The only problem reaIly is that I have to put it in a subfolder, since there can be only one (Highlander). I'm sure we could generate multiple output formats for the aggregating project, does not eclipse have native pom support too ? Kristian (Only touches eclipse with pitcfork) 2012/9/13 Jason van Zyl ja...@tesla.io: You may want to look at PSF files in Eclipse if you want to leverage an existing format. http://wiki.eclipse.org/PSF On Sep 13, 2012, at 7:43 AM, Olivier Lamy wrote: Hi, This idea looks nice :-). I imagine you will retrieve scm locations of dependencies from their poms. In such case dependencies can be a mix of scm (git, svn, hg etc..) So I would prefer we try to do something more generic to provide such features for all scms we support with maven scm (hey we have a very generic scm api :-) ). Maybe it's the case and just the plugin name confuse me :-). 2012/9/13 Kristian Rosenvold kristian.rosenv...@gmail.com: I have just added wiki document to discuss the design of a totally new plugin I have dubbed the git-workspace-plugin. The idea is to change the way we work with layered multi-module projects in git that will make it a whole lot easier for anyone wishing to make a change to do so. The page is at https://cwiki.apache.org/confluence/display/MAVEN/git-workspace-plugin and I would really appreciate any kind of feedback on this. Feel free to edit the page, I will also keep it up to date ;) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Simplex sigillum veri. (Simplicity is the seal of truth.) - 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
Whilst it may work it's also rather horrible, unless every module in said repository shares the same version number and gets released at the same time. If however it's planned to go this route of a single repository, but separate release cadences for modules, some rework and new releases of the maven-release-plugin should probably first be ironed out. On 12/09/2012, at 12:13 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Tagging the whole repo svn-style definitely works, and the maven-plugins repo isn't that big either. We could consider stephen's subdivision suggestion, but really I think it's totally viable to just leave one big repo. We're talking 37mb for the full history of everything, give or take a few bytes. Not too much by any modern standard.
Re: [VOTE] Move Maven projects sources to git
Is this not where the use of Review Board ( or preferably, Gerrit IMHO ) comes into play, any patch/commit goes thru the code review system prior to being accepted, and part of that review process is a required signoff that committer X has a contribution license for the project. On 12/09/2012, at 12:13 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: How is accepting a patch in Jira from user fuzzyBear without any further credentials attached (and no visible identification of a real or imagined person) different form a github pull request ? So while I agree about being careful about IP, i can't see our current regime being a bit different from github. You may argue that we'd want to tighten this, but this is the current reality for over 1 million committs. I have no idea of how many John Smith accounts there are in our jira, but we pretend to ignore the fact.
Re: [VOTE] Release Maven Indexer version 5.0.0
+1 but there is no site? Regards, Hervé Le mercredi 12 septembre 2012 20:20:24 Tamás Cservenák a écrit : Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112version=187 22 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=12112sta tus=1 Staging repo: https://repository.apache.org/content/repositories/maven-058/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, ~t~ - 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/9/13 Mark Derricutt m...@talios.com: Whilst it may work it's also rather horrible, unless every module in said repository shares the same version number and gets released at the same time. If however it's planned to go this route of a single repository, but separate release cadences for modules, some rework and new releases of the maven-release-plugin should probably first be ironed out. That must work since 2.2 (see http://jira.codehaus.org/browse/MRELEASE-457 ) On 12/09/2012, at 12:13 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Tagging the whole repo svn-style definitely works, and the maven-plugins repo isn't that big either. We could consider stephen's subdivision suggestion, but really I think it's totally viable to just leave one big repo. We're talking 37mb for the full history of everything, give or take a few bytes. Not too much by any modern standard. -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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
Yes, that works fine already. I've already used it for releasing Apache DeltaSpike where we do not have the pom directly under the root folder but in a ./deltaspike/ folder (in parallel to docs, etc) LieGrue, strub From: Olivier Lamy ol...@apache.org To: Maven Developers List dev@maven.apache.org Sent: Thursday, September 13, 2012 9:45 PM Subject: Re: [VOTE] Move Maven projects sources to git 2012/9/13 Mark Derricutt m...@talios.com: Whilst it may work it's also rather horrible, unless every module in said repository shares the same version number and gets released at the same time. If however it's planned to go this route of a single repository, but separate release cadences for modules, some rework and new releases of the maven-release-plugin should probably first be ironed out. That must work since 2.2 (see http://jira.codehaus.org/browse/MRELEASE-457 ) On 12/09/2012, at 12:13 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Tagging the whole repo svn-style definitely works, and the maven-plugins repo isn't that big either. We could consider stephen's subdivision suggestion, but really I think it's totally viable to just leave one big repo. We're talking 37mb for the full history of everything, give or take a few bytes. Not too much by any modern standard. -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
excludepackages versus other things in the javadoc plugin
I'm working on MJAVADOC-350. I've discovered that the implementation does not bother to inventory the individual file names of the source files if there are any excluded packages. Anyone know why? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release of Maven Indexer 5.0
On Thu, Sep 13, 2012 at 2:04 PM, Manfred Moser manf...@mosabuam.com wrote: On Wed, September 12, 2012 6:06 pm, Chris Graham wrote: On Wed, Sep 12, 2012 at 9:46 PM, Anders Hammar and...@hammar.net wrote: I fully agree with you and I'm actually of the opinion that the Java community has a responsibility to provide enough reasons for those on older Java platforms to upgrade. But as long as we provide libraries Simple. Two reasons actually. Without going off on an essay about the psychology of developers and being obsessed with shiny new things (and a Dev centric view of the world)... 1. Cost. 2. Especially in the corporate world, they are far more concerned with function rather than form (ie the underlying technology). In short, if it works, leave it. Which also relates to #1. Case in point: My current project is a multi million dollar one that is *finally* moving from 5-7 YO tech to the newest stack. Partly due to the support issues, but mostly due to the cost of support of the older versions; it's finally become cheaper to upgrade than to continue paying the huge support costs. But my basic point is, that the act of upgrading large systems is not a cheap one, so it is NOT done lightly. I think that the cost is only so high because companies keep waiting until it is too painful. If you constantly keep upgrading a bit here and there and stay up to date with your operating systems, runtime environments, browsers and client site frameworks and so on you would actually be able to save a LOT of money in the long run. But you would have to constantly invest rather than waiting with no investment until things fall apart and then being forced to large costly upgrades. When a release has to move through 15 environments before it gets to prod (think large government project), and various change control boards etc, nothing is easy or cheap. And that is just for a release of code that we write. Updating the underlying technology stack is not a simple or cheap exercise. It's a matter of scale. Smaller, more self contained projects may indeed be able to take the faster route that you suggest. But it is always a matter of *business* risk, not *developer* led changes. So it is mostly short sighted management and an absence of real technology leadership in organizations causing this problem imho. And forcing the I could not disagree with you more. And, in a strange way, you're made the very point that I'm trying to get across. What you've said there is a very developer centric view. Which is putting the technology ahead of the business. It is the business needs that should be dictating the technology; not the other way around. -Chris pain to stay on old stuff higher (like Oracle is doing with deprecating Java 6 earlier) is actually a good thing. imho Maven 2 should have long been deprecated and removed from the downloads pages.. just my 2c though ;-) manfred - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release of Maven Indexer 5.0
On Thu, Sep 13, 2012 at 11:52 PM, Mark H. Wood mw...@iupui.edu wrote: On Wed, Sep 12, 2012 at 09:04:09PM -0700, Manfred Moser wrote: On Wed, September 12, 2012 6:06 pm, Chris Graham wrote: On Wed, Sep 12, 2012 at 9:46 PM, Anders Hammar and...@hammar.net wrote: I fully agree with you and I'm actually of the opinion that the Java community has a responsibility to provide enough reasons for those on older Java platforms to upgrade. But as long as we provide libraries Simple. Two reasons actually. Without going off on an essay about the psychology of developers and being obsessed with shiny new things (and a Dev centric view of the world)... 1. Cost. 2. Especially in the corporate world, they are far more concerned with function rather than form (ie the underlying technology). In short, if it works, leave it. Which also relates to #1. Case in point: My current project is a multi million dollar one that is *finally* moving from 5-7 YO tech to the newest stack. Partly due to the support issues, but mostly due to the cost of support of the older versions; it's finally become cheaper to upgrade than to continue paying the huge support costs. But my basic point is, that the act of upgrading large systems is not a cheap one, so it is NOT done lightly. I think that the cost is only so high because companies keep waiting until it is too painful. If you constantly keep upgrading a bit here and there and stay up to date with your operating systems, runtime environments, browsers and client site frameworks and so on you would actually be able to save a LOT of money in the long run. But you would have to constantly invest rather than waiting with no investment until things fall apart and then being forced to large costly upgrades. I think this happens because the money you spend on upgrading and the money you save because of it are in two different pots. If you look at the way budgeting works, you might find that the current behavior makes sense -- assuming that you accept that the way budgeting works, makes sense. :-/ Absolutely true! Especially when support is outsourced (even internally) an you have on-shore/off-shore teams. Thanks for reminding me of that. -Chris So it is mostly short sighted management and an absence of real technology leadership in organizations causing this problem imho. And forcing the pain to stay on old stuff higher (like Oracle is doing with deprecating Java 6 earlier) is actually a good thing. imho Maven 2 should have long been deprecated and removed from the downloads pages.. Tell the distro.s. Gentoo still has Maven 3 keyworded on all arches, and Gentoo is one of the bleeding-edge, daily-updating distro.s. I'll be using M3 for production work the day after they take the ~amd64 keyword off it. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart.
Re: Wierd archive deployed?
:-) [Trying...too...resist...the...urge...to...say...use...eclipse...] But seriously, a Zip file has directory entries in it. They can be a File entry, that points to a file's contents, or a Directory entry. If the (empty) directory entries are not there, then most archive tools simply go ahead and create the path and then the file anyway. Having the Directory entries there is not unique to maven's archiver. In short, IntelliJ need to fix their code. They should be able to handle that situation. -Chris On Fri, Sep 14, 2012 at 2:18 AM, Benson Margulies bimargul...@gmail.comwrote: I had trouble working on the javadoc plugin in IntelliJ, and this response came back from their support person. What's special about this artifact? Should I see if making a new release will fix it? Quote starts here: This issue occurs because ...\.m2\repository\org\apache\maven\maven-toolchain\1.0\maven-toolchain-1.0.jar file has some weird archive format that IDEA cannot read: http://dl.dropbox.com/u/2752840/screens/snap2142-1347566987.png . If you look inside this jar with any external unpacker, you'll find that it contains empty file entries that match directories. So it's some Maven packaging issue that affects IDEA ability to properly read this jar. I don't think that we'll want to invest resources into fixing this issue, it should be rather fixed in the Maven repository. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
