Fix Maven Source Version Having No Effect

In a recent article at http://impossible-is-development.blogspot.com/2012/11/basic-maven-project-build-fix-tip.html, I wrote about a trick to get the .classpath file to reflect the src/main/java etcetera build structure. This trick actually helps in another not-to-uncommon situation: unsyncronized source versions.

If you create a new pom.xml, it may happen that there is no Java versions information given. The version can be given in two ways; via some xml using a 'properties' tag, or via more xml. 

Plugin config: 

<build>

<plugins>

<plugin>

maven-compiler-plugin

<configuration>

<source>1.6</source>

<target>1.6</target>

</configuration>

</plugin></plugins>

Sorry about the formatting. (Doesn't the Blogger editor suck something awful for quotes and code? ...hmm...can one blog on Github?)

<project.build.source>1.6</project.build.source> <project.build.target>1.6</project.build.target>

(Again, sorry about the formatting.)

Now; if you add this to an existing pom.xml, Eclipse may fail to take note of this change automatically. Maybe it never takes note. In any case, the same solution applies here as in the earlier blog post: just disable and enable dependency management.

Slashdot Descriptors Feature For Stack Overflow

You probably already know about Stack Overflow, a mostly nice Q&A site. There are still some problems with it, in my experience.

One problem is getting down-voted without explanation. Has happened to me lots of times, so you get used to it, you even expect it (without submitting knowingly bad questions, to be clear). But it's still confusing.

There is a solution, that would help at least some: down-vote buttons should be categorized. We know and love this feature on Slashdot: moderation descriptors. The complete list seems to be: normal, offtopic, flamebait, troll, redundant, insightful, interesting, informative, funny, overrated, or underrated (from http://en.wikipedia.org/wiki/Slashdot).


The negative ones are: offtopic, flamebait, troll, redundant, overrated. 

The positive ones are: insightful, interesting, informative, funny, underrated.

I haven't thought up good descriptors for Stack Overflow, but why not reuse the canned answers used when a question is considered so bad that it gets deleted? Maybe: 'unclear', 'shopping-list', 'clearly-homework', 'submitter-should-have-tried-harder', et cetera.

Eclipse/SVN Nice Going

Trying to add new property 'svn:ignore' with value 'target

.settings

',

but property already exists with value '.settings

target

'.

Missing Quick Fix In Package-Info File

Creating a package-info.java is useless without the package declaration. But strangely, in Eclipse, you get no error if you leave the file empty. And the usual Quick Fix to mend the package declaration is absent. Odd.

But the solution is simple: just add a "class X {}". It's legal syntax, and when that class declaration is present, you'll get that helpful Quick Fix. You can then remove the class if you want -- after you invoke the 'Add Package Declaration' Quick Fix.

Java Project Modularity Woes

We want to publish:
1) an API (DTOs and stuff), 20 classes or so.
2) a devkit. A simple server based on Jetty, less than ten classes.

Now, of course there are ways to do it. But no really good ways, I believe.

We may have to use Maven here.

Basic Maven Project Build Fix Tip

Sometimes, in Eclipse, a maven project will not be properly set up. For instance, when you create a maven project by creating a pom.xml file inside a folder. This can be seen by inspecting the '.classpath' file -- it will contain only these three items (or similar):

<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/> 

<classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> 

<classpathentry kind="output" path="target/classes"/>

Then, what you do is this: simply "Disable Dependency Management" and then "Enable Dependency Management" from the "Maven" menu in the contextual menu from the project. If you keep the ".classpath" file open, you'll be able to see the what happens.

In the 'Disable' step, the Maven entry disappears:

<classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/>

Then, in the 'Enable' step, the entries which enable the build appears:

kind="src" output="target/classes" path="src/main/java"> 

<classpathentry kind="src" output="target/test-classes" path="src/test/java">

 along with the 'MAVEN2_CLASSPATH_CONTAINER' thing mentioned above. Done!

--

Today I discovered that the above maneuver is in fact useful to handle another problem involving mis-synchronization between ".classpath" and the "pom.xml" file. Article forthcoming.

AWS Alarm Super Easy to Set: Warning

Mea culpa: I must've not clicked the link in the confirmation email. Just tried adding my email, and now it shows up in the SNS console of 'NotifyMe'. Me bad,AWS good!

However... it would be nice if the AWS alarm GUI could warn me of such a condition as where a notification has no confirmed endpoints.

---

In a previous post, I stated that the AWS alarm feature is super-easy to use. That may be the case, but it seems to not have sent me the notification mail I expected.

So now I am trying to find out information about what happened, and that turns out to be not so easy.

Clicking the link next to the alarm status icon gets you alarm info -- good. Then you can get history data pertaining to this alarm -- fine. And even some JSON describing what happened -- might be useful.

What seems not possible to get, is information about the action connected to the event. I am pretty sure that I filled in the e-mail field correctly, but what else might cause me to not get that email? So I want to check the settings in the connected action, which happens to have the name "NotifyMe".

In the "Edit" view, there is this information: "This is an SNS Console managed topic and cannot be viewed". 

That's an unexpected complication. By the way, 'SNS' means 'Simple Notification Service'.

Entering the SNS Console, there is no trace of the email I entered back when I created the alarm. Mysterious. 

Why did I think that it'd be easy, and Just Work? It's a rare event -- like diamonds -- when something just works. I should've tried the alarm out, of course. 

Maybe there is an email sent as confirmation when the notification is set. Then you could check that email, and if you don't get that email, something is wrong.