Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
At our company we're taking a critical look at the products in our Java Development/QA street. One of the products we're looking at is Apache Continuum.
Could someone with Continuum experience (and preferably also Jenkins experience) explain what the advantages and disadvantages of Apache Continuum are (especially with regards to Jenkins)?
My first impressions are:
Advantages:
Better suited for grouping builds and projects (from a UI perspective).
Disadvantages:
No clear dashboard.
A relatively small community.
No plugins (right?).
We are using continuum and we switched to jenkins.
Jenkins advantages:
Findbugs
pmd
checkstyle
code coverage (very good chart see for emma)
integration with artifactory
integration with sonar
post build task (build other projects, automatic archiving)
new delivery of jenkins every week - critical bugs are solved very quickly
rpm/deb packages (you can use yum/deb for automatic update every week)
In jenkins you create the view and you can group projects there.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 9 months ago.
The community reviewed whether to reopen this question 9 months ago and left it closed:
Opinion-based Update the question so it can be answered with facts and citations by editing this post.
Improve this question
Before starting on a new Java Open Source Framework (e.g. ProjectReactor) or a including a new Open Source Library (e.g. Jackson), I would like to know how popular and stable these dependencies are. In particular I would like to know how many times have these been downloaded. With many maven repositories (Nexus, Artifactory) in play, is there a way to get this information? E.g. if I go to maven central and search for these dependencies, I don't see #downloads?
With JavaScript libraries, this is so much easier. All I need is to go to https://www.npmjs.com and search for the package. It shows the #downloads right there.
If there is no easy way to get #downloads, what are the possible metrics by which I can assess whether a Java library is suitable to use?
Edit:
Some people suggested to use "Usages" in the maven central. But that is the count of how many times this dependency has been used by other maven projects in the maven central. IMHO that doesn't always give a good indication about how many times that library was used in enterprise or other non-open-source projects. Why does maven central not expose #download for everyone? Or maybe there is a way to get this information that I don't know of.
mvnrepository.com has the number of usages by other projects.
e.g. for Hamcrest
Used By 7,059 artifacts
Careful, this website isn't affiliated with Apache. I'm not sure how they get those stats but they probably build the graph themselves.
This blog post states that individual project owners can see download statistics, but I would infer from that that it's not public information. The post is 12 years old though so it may have changed since then.
Of course, there's always number of GitHub stars, which is a metric that's applicable for any language.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am considering forking a long lived but seemingly abandoned OSS project. In my updated pom.xml, should I include the developers of original work to give them credit since they are responsible for the 99% of the code, or just new maintainers, as the Maven POM Reference would imply:
All projects consist of files that were created, at some time, by a
person. Like the other systems that surround a project, so to do the
people involved with a project have a stake in the project. Developers
are presumably members of the project's core development. Note that,
although an organization may have many developers (programmers) as
members, it is not good form to list them all as developers, but only
those who are immediately responsible for the code. A good rule of
thumb is, if the person should not be contacted about the project,
they do not need to be listed here.
It is just the pom.xml file. Do like it is written in the rule of thumb.
For a branch or a fork the history and dependencies or codebase should be clarified elsewhere, e.g. git, GitHub.com, GitLab.com, a project page, the docs...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I know that IntellJ IDE is better than Eclipse for Java coding. But I have a hard time figuring out what would be easier to develop. An Eclipse plugin or an IntellJ plugin. Both have their own guidelines for plugin development but does anyone has any experience in plugin development to answer me? Thanks!
It depends. Would do you want to archive with your plugin?
General answer:
When I want to work with an existing code base - i.e. writing a plugin, first I take a look at the documentation to get a rough overview and then I get my fingers dirty as fast as possible.
I take an example or existing plugin that does something similar that I want to archive and I start to experiment.
So, try out both. One day writing/changing a simple Eclipse plugin and the other day doing the same with with IntelliJ platform.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
What i have done :
Created few projects using Java/ Selenium Webdriver/ TestNG using eclipse
Getting the TestNG test results in an XML/ HTML formats and looking for failures etc.,
What i can look for hereafter,
Do i need to use Maven(or likely tools), for managing projects, and why?
Do i need to look for Jenkins type of tools(But i know it depends on context, still if there will be any real usability with selenium webdriver)
Do i need to look for reporting tools(such as surefire) which is well equiped?
Or is it ok to continue with what i'm doing for a not so complicated project?
I know this qustion may be really broad, but i don't find anything solid to look after.
Appreciate your help, Thanks!
I think the world has agreed that Continuous Integration is good which is pretty rare for any technology.
I would definitely suggest setting up jenkins or equivalent and adding the maven configuration to be able to get your project to run and store results there. This may end up being more work because ideally you want to get the project you are testing to be built on check in and have its unit tests etc to run and then get deployed so you can run your selenium tests.
It shouldnt take too long to do depending on the ease of deployment of the app your testing, but even just having your tests being able to be kicked off automatically and its results stored will be handy and give you a real visibility boost of your tests.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
How do we future proof our code against changes in third party libraries? Maintaining unit tests seems like one way of going about it.
1) Configuration management. Knowing exactly what versions of your libraries go into making up your build is essential. Some distributions are very sloppy in identifying versions, so you may want to invest in a good version extractor, such as http://www.jboss.org/tattletale -- also, comparing reports over time so that you can identify what has changed in your libraries.
2) Unit tests and integration tests. The phrase "unit test" is badly misused in the community. You need to test a spectrum of behavior in your configurations.
3) Managing interaction effects. One of the toughest issues to manage is upgrading just one item. Often, point releases of libraries depend on other point releases of other libraries. You can't just take one.
4) Planning for systematic upgrading. Build into your project schedules work to do testing of newer releases so you can estimate the impacts of doing an upgrade. With that information, you can plan your upgrades for a time when you are not under the gun because it has gotten too old, or is incompatible with the next supported JVM.