Q1. What is your definition of a "compile" dependency?
A1. Some module other than the current one which is required for this module to be compiled. Most of the time this will be because you issued an import org.apache.commons.logging.Log; statement, as a topical example.
Q2. How will you know what the "compile" dependencies of those projects are in order to raise those jira issues? In fact, how do you know what the "compile" dependencies of your own projects are if you are using maven?
A2. I don't see how this is relevant, but ever the teacher, there are lots of easy ways to determine this. It's quite trivial to ensure that every import can be found in one of the dependencies which are immediately referenced in the POM. Maven provides a nice plugin which assists in this process, see http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
Maven does not always add transitive dependencies to the compile classpath. For example, junit is a frequent dependency of a most projects, and yet it will not be added to the compile classpath. It will be added to the test-compile classpath. I could go on and on..
Use whatever deployment mechanism you want, but as long as you are going to make POMs available to the general community, then you should get them correct. I think it's a shame that your team would abandon Maven, but perhaps it's based on obvious misunderstandings and misapprehensions about how Maven works, as is evident in this JIRA; but again, use whatever deployment mechanism you wish.. Please don't introduce problems for majority of us.
So I recommend we either delete the POMs all together, or get them right. Wrong/bad information is worse than no information.