Maven Idea

Here's a radical idea to simplify the usage of Maven, especially when considering Eclipse cooperation.

How about not using test scope, but instead create a 'project-test' for every 'project'? Some advantages:

The pom.xml files will be cleaner.

The single-classpath Eclipse will not be a problem any more.

One will not have to think about the interaction between the declared dependency scope and the importing dependency scope. (Unfortunately, the 'provided' scope is still needed, but that is pretty simple.)

If one would want to import test code into another project, no need to fiddle with '-tests' attachment.

One can build with-out tests, which is quicker, and could likely allow tests to be run quicker, ironically, because of parallel execution. Or you could collect all tests before running them.

The odd thing is that maven wasn't designed this way from the start. It would have dispensed with a lot of extra complexity. Etcetera.

Maven Source Properties That Don't Work

When I do 'Maven > Update Project Configuration' in Eclipse, this seems not to work: 

    <properties>

        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

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

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

    </properties>

    

But this seems to work: 

    <build>

        <plugins>

            <plugin>

                <artifactId>maven-compiler-plugin</artifactId>

                <configuration>

                    <source>1.6</source>

                    <target>1.6</target>

                </configuration>

            </plugin>

     ...

    

Too bad, since the first xml is neater. 

---

PS. One sign that there is some mix-up with 1.5/1.6, is that the @Override annotation acts up.

Java Package Reflection

There's no Package.forName() like there is a Class.forName(). Is this an accident? If it's not, only packages that have a class in them, let's call them 'inhabited' packages, can actually be accessed.

There's the Philosophical Question of whether they then 'exist' or not. Platonic package, anyone? But on the other hand, one can probably find out: there is the Package.getPackages().

-- TBD --

Development Is Implannable

It's possible, but not plannable. Let's make a new word: Implannable. Implannable.

That's at least half of what the 'agile' thinking is about.

Must. Write. About. Planning.

Must write about planning soon.

Maven Is Back, Stronger Than Ever

Guess what this does, in proper maven resource plugin context:

<configuration>

<outputDirectory>target/classes</outputDirectory>

<excludes>

<exclude>**/*.java</exclude>

<exclude>**/*.class</exclude>

<exclude>**/.svn</exclude>

</excludes>

<resources>

<resource>

<directory>src/test/java</directory>

<filtering>false</filtering>

</resource>

<resource>

<directory>src/main/java</directory>

<filtering>false</filtering>

</resource>

</resources>

</configuration>

Copies resources out of src/test/java and src/main/java, excluding files matching the specified patterns? 

Wrong. Or, mostly wrong. 

The exclusions will apply to the src/test/java directory paths, but not the src/main/java. Yep, at least in the version we use. 

Caveat utilitor.

Maven Copy Plugin

This (new?) Maven 'copy' plugin: http://evgeny-goldin.com/wiki/Copy-maven-plugin, seems to be a useful tool to simplify some Maven projects. It seems to be a good way to using a minimal number of plugins for common tasks. This is not a deep review; I'm just blogging this as sort of a mental note.

But it could be used for the following problem: I recently learned a second way that the 'real' Maven and running under the Eclipse Maven plugin differs, in that resource files in /src/man/java are copied; but not so with Maven defaults. (The other difference I know of is that Eclipse has only one classpath, the same for both src/test and src/main. Fertile ground for bad imports.) It's easy to add with a standard plugin, but if you have many such small tasks, then possibly this 'copy' plugin will be better than a bunch of disparate plugins. Maven is verbose enough, I think.