Comments for Sysbliss Blog

Comment on Testing Atlassian Rest Plugins by Erik Husby

Erik Husby — Thu, 21 Jan 2010 16:44:06 +0000

Two more things.

1. Had to change the URL used in ProjectRestTest.java to http://localhost:2990/jira/rest/projectfinder/1.0/projects.xml instead of http://localhost:2990/jira/rest/projectversions/1.0/projects.xml

2. atlas-integration-test is running the test twice! Is that because I am using JUnit instead of TestNG?

Comment on Testing Atlassian Rest Plugins by Erik Husby

Erik Husby — Wed, 20 Jan 2010 21:07:28 +0000

Thanks for the quick response. Problems resolved.

Comment on Testing Atlassian Rest Plugins by jdoklovic

jdoklovic — Wed, 20 Jan 2010 20:47:11 +0000

Sorry… I started out using HttpClient, but then switched to using the jersey testing utilities.
I added the dependency list in the beginning of this post.

The javax.ws.rs.core.GenericEntity is the proper class as well.

Comment on Testing Atlassian Rest Plugins by Erik Husby

Erik Husby — Wed, 20 Jan 2010 20:30:12 +0000

There are some disconnects between the code and import statements.

In ProjectRestTest, the code references Client, WebResource, and GenericType but there are no import statements for them. The imports list several classes from org.apache.commons.httpclient which are not mentioned in the code. Replacing Client with HttpClient from commons-httpclient 3.1 fails because there are not create or resource methods there.

In several of the other sources, there was a GenericEnity that had no import statement. Intellij suggested javax.ws.rs.core.GenericEntity which appears to work.

What is the solution to the import problems?

Comment on Atlassian® as a Web-App Framework by bqlr

bqlr — Tue, 05 Jan 2010 02:19:13 +0000

stupid! so complicated configuration, where is business model ? where is Domain-driven Design, sorry, do you know DDD?

see another true light-weight framework, so simple: DI + AOP + DDD = jdonframework, http://jdon.dev.java.net

Comment on Atlassian® as a Web-App Framework by jdoklovic

jdoklovic — Mon, 04 Jan 2010 20:28:52 +0000

I create the version class on the fly so that I can override the version used at runtime via a maven property.
Essentially this let’s me pass a version on the command line when building.
This is useful if you use an external system (say, JIRA) to get your version/build numbers.

Using JIRA + Bamboo in this manner is outlined in another post:
http://blog.sysbliss.com/uncategorized/release-management-with-atlassian-bamboo-and-jira.html

Comment on Atlassian® as a Web-App Framework by Wim Deblauwe

Wim Deblauwe — Mon, 04 Jan 2010 19:44:46 +0000

Why are you creating this Java class on the fly? I am doing something simular, but just put the version in a properties file using the filtering of the resource plugin and then loading that properties file in the application.

Great post!

Comment on Atlassian® as a Web-App Framework by cburleson

cburleson — Sat, 02 Jan 2010 00:02:17 +0000

This is a great post, overflowing with value. Thanks so much for taking the time to share your detailed journey. I intend to go through this carefully soon to see what parts might be applicable to a J2EE Reference Architecture I am working on. It seems that you may be a little too closely tied to some Atlassian dependencies for my taste. But… this is very educational.

Comment on Atlassian® as a Web-App Framework by Jessica Doklovic

Jessica Doklovic — Thu, 31 Dec 2009 18:41:04 +0000

spoiler alert U == dork

Comment on Release Management with Atlassian Bamboo and Jira by sergiu

sergiu — Wed, 30 Dec 2009 15:51:54 +0000

Hi, I’d like to clarify how the bugfix releases should be handled…

After 1.0.0 is released, work will start on new features in 1.1.0. So new versions will be created, say: 1.1.0-dev1, 1.1.0-rc1, and 1.1.0; the bamboo build plan will start building 1.1.0-dev1, because that is the ‘first’ unreleased version, correct?

In the meantime we will need to fix some bugs in 1.0.0. Here the picture is not clear…

Normally the bug fixing occurs on new ‘release’ branch in SCM. If this work lasts about 2 weeks, to get some continuous builds, we will have to create another build plan for the new branch, and I guess associate this plan with same Jira project for which we need to create a new 1.0.1 version (in addition to the 1.1.* versions created after 1.0.0 was released). At first this 1.0.1 version is also unreleased in Jira, correct? How does the Jira versions plugin know that it needs to build 1.0.1, and not 1.1.0-dev1?

Or do we have to create a new Jira project for this, and start with 1.0.1

Can you clarify the sequence here?

Thank you