I found HTMLUnit is useful for me,but the files are too old.
So I use svn co https://htmlunit.svn.sourceforge.net/svnroot/htmlunit htmlunit to check the code,But I don't know how to use them.
Is there somebody can tell me how to compile them?
I see you have very little knowledge of Subversion.
I could link you to lots of verbose documentation, but let's make it quick and easy: what you downloaded is the whole repository, containing lots of redundant code, majorly the three canonical directories branches tags trunk.
In order to obtain usable code, you either download a stable (tag) version or unstable version (trunk). Advantage of trunk over tag is that it mostly contains new features, but tags are generally stable.
Try to get the following URL: https://htmlunit.svn.sourceforge.net/svnroot/htmlunit/tags/HtmlUnit-2.8/, then you could try ant to build (I'm no Java expert, does the package have an ant script?)
You don't need to take the detour of building it from sources yourself. The latest version is 2.8, and it's readily available from the Maven central repository. If you're not using a dependency manager, just grab the jar from here:
http://repo2.maven.org/maven2/net/sourceforge/htmlunit/htmlunit/2.8/
Check out the projects instructions on how to get and build the latest version !
http://htmlunit.sourceforge.net/gettingLatestCode.html.
It seems it ships as a collection of submodules, each with its own build system (some of them maven, some ant).
The latest release dates back to August 2010, doesn't seem to be that old, but if you're aware of improvements you need which are available only in later versions I suggest you look at their CI server, which provides already the artifacts from the latest build.
Related
It is mentioned here that
If you do not follow Maven versioning standards in your project versioning scheme, then for version comparison, Maven interprets the entire version as a simple string
From the example, we can see that 1.0.9.3 should be treated the more updated than 1.0.10.1
1.0.1.0
1.0.10.1
1.0.10.2
1.0.9.3 < most updated version
There is a project I am currently working on. It has a dependency on a package com.example.http, which is versioned 1.0.12.2. There are several updates on it now. A subset of the versions are (1.0.0, 1.0.9, 1.0.12.2, 1.0.16). Since it does not follow Maven versioning standards, I would expect the order of these versions to be:
1.0.0
1.0.12.2
1.0.16
1.0.9
Q1:
However, when I run mvn versions:display-dependency-updates, it said that 1.0.16 was the most updated version. Why?
Q2:
Should I do something to removed the non-standard 1.0.12.2? notes: all, but 1.0.12.x, follows the maven versioning standard
[INFO] com.example:http ............................ 1.0.12.2 -> 1.0.16
The mechanism changed about 10 years ago, so your information is outdated. Maven is able to sort arbitrarily long version numbers, see e.g. https://blog.soebes.de/blog/2017/02/04/apache-maven-how-version-comparison-works/
More information can also be found in the answer https://stackoverflow.com/a/31482463/927493
I'm maintaining a parent pom for my team which will provide the latest compatible version of various maven plugins per the JDK that the project uses. Sometimes if a project utilizes an older version of Java (like 1.5) maven will fail due to a plugin requiring a newer version. Is there a way to get a map of a given plugin and see what the minimum java version is for said plugin? I was thinking there was some sort of report or something that would show me that, but I'm not seeing anything.
What about: https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html Apart from that on every plugin page you can find the goals page which contains the information you need. One more thing if you are using not the most uptodate versions all older versions pages are available where you can look at which version which JDK versions uses. It shouldn't be problem to write some kind of script to programmatically extract the information of the older plugins. The above site contains the informations of the uptodate plugins.
Apart from that plugin version selection basead on JDK version is not a good idea. The plugins have only a minimum version for JDK they need to run with. Apart from that they run on all versions (already on JDK 9 with one exception)...Furthermore plugins might require a minimum Maven version to run with which is either Maven 2.2.1 or Maven 3.0+ which shouldn't a problem.
You should define your plugins versions simply based on problems you might have but i would recommend to keep uptodate with your plugins.
If you need running you build with JDK 6 for example, but you use Maven 3.3.X which needs JDK 7 to run you can achieve this by using toolchain to handle this situation.
In theory this shouldn't be an issue. Maven will use the Java version you run it with, so the plugin's dependency will be satisfied, independent of the project's language level. Just make sure your devs are using a current version.
Example: running Maven with Java 8 will satisfy the dependency of a Plugin that requires Java 8, independent of the project's source and target level.
(With dependencies it's more complicated, I am afraid, but since you are not actually coding against your plugins, you should be fine)
In my work they are using a system in Java that works as a TFS. We also use a plugin in eclipse to handle the versions of the projects. My question is if I can use VisualSVN, instead of the plugin, for better management of versions. In short, is it possible to use properties of TFS in VisualSVN ?. If possible, what can be used ? Thanks.
SVN is a version control system. TFS is project planning, version control, build, testing, release, and so on in one package. Basically, it's a superset of SVN.
You can use all of the non-source control while keeping your source code in another version control system, but it would be hacky and awkward and require a bunch of hoop-jumping that just isn't necessary. You can migrate source code from SVN to TFS very easily, with fairly minor disruption.
TFS has two options for source control: TFVC, which is similar to SVN, and Git, which is not.
For Java developers, there's a plugin for Eclipse called Team Explorer Everywhere that gives them an IDE-integrated TFS experience.
I am wanting to create a gihub repository that offers benchmarking code that
works for concurrent features available only in JDK 1.7 (Fork/Join) as well as for older ones found in JDK 1.6.
Offering both options is important for what I need.
Does anyone have a recommendation how should I structure the repository.
I was planning on having a repo called and under it:
jdk17
build
src
mycode ...
jdk16
build
src
mycode
Please suggest any alternatives, possibly use of Maven or other more practical approaches, if any.
Unless you need to have source code for both versions available at the same time, you can just put them in separate branches.
Ant's current release is 1.8.2, but I found a 1.8.3 readme via google that indicates a bug that I'm interested in was fixed in that version.
Does anyone know how I most easily obtain 1.8.3? They don't seem to make it easy.
You can either build it yourself from source or use the nightly builds from their CI server. Obviously use at your own risk - there's no guarantee the latest code will work, and the binaries are tagged "alpha".
Subversion snapshot
Most probably you'll have to build this pre-release yourself from the subversion repository.