Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information. WWW: http://maven.apache.org/ Fix: Patch attached with submission follows:
You need to explain why devel/maven3 can't/shouldn't be updated instead of adding a new port. also (form letter): Hi, if you are still interested in having this port in FreeBSD, it may (or may not) need to be reworked to support stage, and it may need updating to other newer conventions such as "USES" which is expanding all time. For staging, see http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-May/000080.html Additionally, you need to provide some sort of quality assurance. In order of preference, we are looking for: 1) "poudriere testport" or "poudriere bulk -t" logs 2) Redports or tinderbox logs Please provide an updated shar file and attach a test log. Alternatively, please indicate if you are no longer interested in having this software in the Ports Collection and that we can close the PR. Thanks!
port appears staged and doesn't suffer bitrot. Maven is notorious though; I wouldn't move this to patch-ready with nothing less than poudriere testport logs.
Hi, Sorry I haven't been more responsive, been pretty busy. I'll try to get those logs next week. Never used Poudriere before, so might take me longer. I believe the Maven 3.2 branch was updated recently, so will also update the port if I can.
Created attachment 148018 [details] maven32 port Updated to maven 3.2.3
Created attachment 148019 [details] Poudriere logs
I'm terribly sorry for the delay, this was getting embarrassing. Here are is the updated maven32 port as well as the poudriere logs. I'm unsure I got what you wanted for the latter, so let me know if that wasn't it. The reason I want to create a maven32 port is because the Apache foundation currently currently 3, 3.1 and 3.2, so I think it makes sense to have them all three.
Please, find attached port (latest version + fixed MASTER_SITE_SUBDIR for new releases)
Created attachment 150818 [details] port 3.2.5
Forgot to mention - this maven was manually tested by building itself, all went well.
Thank you for providing an updated port. I had kinda given up on this since it has been so long since I submitted the original port. I'm happy for this port to replace mine, although technically there is no port as of yet, so not sure my opinion counts. :)
build tests done on 10.1a, 9.3a, 8.4i, all fine. I think this should be committed as devel/maven and the maven3* versions should be deprecated.
(In reply to Kurt Jaeger from comment #11) There have been a few changes in the pom file format that broke compatibility between versions, which I'm guessing is the reason why the project maintains that many branches. It might be safer to keep all those versions for now.
Acording with release notes in 3.2.5 : << Maven 3 aims to ensure backward compatibility with Maven 2 >> More comes here: https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes We can just perform the maven3 upgrade.
We have 3 different versions of maven in ports tree when the last (3.2.5) ensure backward compatibility with 2. How to fix this issue.
I would just update maven3 to this 3.2.x stuff and if issues pop up, we'll discuss again. Right now we just *assume* that there are issues, and I guess, this is too much thinking for too little gain.
Phrase "Maven 3 aims to ensure backward compatibility with Maven 2, " are copied, and present in all info about mavens: 3.0.5 3.1.1 3.2.5 However, I think update maven3 port would be ok, if there any java users who get some problems - we'll see them ;)
My preference is to maintain the 3 branches because that's what the upstream project supports, but I don't have any strong objections either way.
I would support the update of maven3- who knows we have trouble enough getting rid of old versions of many ports! However, I think an exp-run would be warranted...
Searching for devel/maven mentioned in ports/*/Makefile found: archivers/snappy-java databases/hbase devel/hadoop2 devel/spark devel/hive java/eclipse java/jrosetta So testing those would be sufficient ?
I'd started with eclipse, other things after this. If all builds, we are OK.
I had a look at the recent changes to make maven 3.x more backwards compatible with 2.x and I'm now happy with removing the mess of different versions we currently have and just stick to the maven3 port (or possibly even just maven). I noticed that 3.3.1 was just released. Will try to create the port when I have a minute.
Created attachment 154997 [details] patch to update devel/maven3 to 3.3.1 see attached patch, test-builds on 10.1a.
Created attachment 155020 [details] patch to update devel/maven3 to 3.3.1, fixed missed pkg-plist in first patch
poudriere builds on 10.1a, 9.3a, 8.4i went fine. I would add devel/maven and deprecate the other ports end-of-may, if the maintainer approves.
It seems that wombat kindly gave me maintainerships, so I don't mind adding new port and deprecating other ones :)
Just wanted to make you aware of bug 199022 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199022 The suggestion is to add CPE numbering scheme, which I think would be a nice addition, so it would make sense to incorporate those changes in the final version of the one maven port to rule them all since I think we all agree at this point it's the way to go.
*** Bug 199915 has been marked as a duplicate of this bug. ***
Created attachment 157555 [details] Maven33.shar - Maven 3.3.3 new port Port for Maven 3.3.3, which was released April 28, 2015. The Maven 3.3.x branch requires Java 1.7, the prior releases up through Java 3.2.x only require Java 1.6
I think that it will be a mistake to replace the existing port structure with a single Maven port. Maven 3.0.x requires Java 1.5 to run, Maven 3.1.x and 3.2.x require Java 1.6 to run, and Maven 3.3.x requires Java 1.7 to run. While it is possible to build applications requiring older Java compilers on Maven 3.3.x using toolchains, it may not be desirable/practical to force users to implement toolchain changes to their poms.
I accidentally lost a line in my maven33.shar file, if you decide to create a maven33 port, you should probably use Jon Chen's shar that's attached to 199915, or ask me to upload a new attachment.
There's a new attempt at getting a port in the tree: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203903
Mine is a side effect of trying to get an updated devel/spark building as the current one in ports is very old. Recent spark needs Maven 3.3. Do we have consensus that there should be a single devel/maven? If so I'm happy to cancel my ticket and help out with that effort instead. As has previously been stated that would introduce a Java 7 dependency (instead of 5 or 6) but Oracle have already EOLed Java 7 so it's not exactly bleeding edge.
Would love to this happen. I was initially against merging all ports, but seeing the efforts of the latest branch to improve backwards compatibility, I think it makes sense now.
(In reply to Mark Dixon from comment #32) Hi Mark, I don't have too much time to go into the deep of this port right now, If you want to handle this ticket and push it, go ahead. Regards - rodrigo
It sounds like the way forward is a single devel/maven, move everything else to that and then obsolete devel/maven3 and maven31. I'll try and get a patch together to do that, probably based on Kurt's patch and try to build everything locally.
I'll work on it on the weekend.
I've done some testing with Maven 3.3.3 and the dependent Maven ports and unfortunately, there is a snag. I've tested the following projects: archivers/snappy-java devel/spark (1.2.1 - current port and 1.5.1 my work in progress) java/eclipse All but Spark 1.2.1 will build with Maven 3.3.3, but not in their current form. The problem lies in the way the Maven builds are packaged. Essentially what happens is the port system downloads a zip file containing all the dependant jars for the build and unzips them. Maven is then pointed at that for it's repository to prevent it from having to fetch all the dependencies from the internet itself. Unfortunately, these dependencies are not limited to the software being built, they also include Maven plugins and dependencies of those plugins. When Maven is upgraded the plugin version are upgraded too but these new plugins and their dependencies are not in the zip files we ship with the ports. Spark 1.2.1 is an odd one, I think it's probably a dependency conflict issue as with 3.3.3 I was running Maven in online mode and it was fetching quite a few jars. I don't really see much point in trying to unknot it as 1.2.1 is quite old. This makes this upgrade a little more painful. We could still commit a Maven 3.3.3 port as devel/maven, but we will have to keep devel/maven3 (and possibly devel/maven31) around for a while whilst we work with the port maintainers to get new versions of the dependency zips built. This will likely also be an ongoing problem impacting future upgrades if we continue to package Maven ports in this way. I think the whole approach needs some thought. Packaging up all the dependencies makes Maven upgrades hard, but makes builds work reliably, but the other approach, leaving Maven online leaves us at the mercy of external repositories and strange conflicts (as we see with Spark 1.2.1).
*** Bug 203903 has been marked as a duplicate of this bug. ***
Re the last comment from Mark: I had a look at eclipse, and the dist file comes from a google drive location ? Is that a hand-rolled zip-file someone provided to be able to have an eclipse-port ? You see me surprised. If maven uses some kind of packaging scheme itself for its dependencies, would it work if we packaged those dependencies in the ports tree ?
@Kurt It looked that way to me as well, but the spark and snappy ports seem to use the same approach of zipping up the repo. I'm not conviced it's the right way, but at least it seems to be consistent.
(In reply to Kurt Jaeger from comment #39) Yes, it's a zip of the local cache of all the dependencies needed to build Eclipse that Maven created when I got the eclipse port working. This local dependency cache has to be provided up front because the FreeBSD ports infrastructure does not allow a port to connect to the internet during the "build" phase to, as maven normally would do, download a dependency that is needed to build whatever project is being built. It's on Google Drive because that's the only "public" place I have to host the distribution files; if there's a more preferred place that I can get to, I'd be happy to move them.
I'm thinking that having separate Maven ports might be the best way forward for now. We can then try to push to get people off maven31 and maven3 where possible and try to obsolete them. Eclipse seems to be the only thing using maven31 so that would be a good candidate to get onto 3.3. At least then we're in no worse position. As for the right solution, I did think about a freebsd-ports Maven plugin that would generate a Makefile (or at least the files part of it) to pull all the individual dependencies in the Makefile (avoiding the manual zip). I'm not really sure that solves the Maven upgrade issue either though.
A commit references this bug: Author: pi Date: Sat Oct 31 21:51:20 UTC 2015 New revision: 400592 URL: https://svnweb.freebsd.org/changeset/ports/400592 Log: New port: devel/maven33 Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information. WWW: http://maven.apache.org/ PR: 188110 Submitted by: wombat@marsupial.org, yerenkow@gmail.com, jonc@chen.org.nz, mnd999@gmail.com Reviewed by: ljboiler@gmail.com Changes: head/devel/Makefile head/devel/maven33/ head/devel/maven33/Makefile head/devel/maven33/distinfo head/devel/maven33/files/ head/devel/maven33/files/mvn.sh.in head/devel/maven33/pkg-descr head/devel/maven33/pkg-plist
Thank you all for the input and submissions to get this done. As it looks now: Yes, we need a new maven version for each release, and then we have to update the dependent ports and their strange mvn-related .zip process to get older versions out of the tree. Mark, you wrote: > [some magic] to pull all the individual dependencies in the Makefile > (avoiding the manual zip) This needs some work, but it's really the way forward. If this idea/input is sent upstream, maybe maven will be more ports/package-friendly in future versions...