jira.codehaus.org

[MNG-868] Use uniform format for and other tags

Sat, 13 Dec 2008 18:35:06 -0600 (CST)

In settings.xml, the activationproperties have the format: <property><name/><value/></property>
whereas the 'user' properties below (which don't have any documentation) have the format
<my.property.name>my.property.value</my.property.name>.

They should really be uniform. My personal favourite is ofcourse: <property name="....">....</property>.

There are more places where duplicate classes are used (repositories,..).

(Also suggest to remove the <dependencies> tag from <dependencyManagement>
and make DependencyManagement extend from Dependencies (or, make it a list)., but this
could prove troublesome.)

[MNG-1569] Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare

Related — Wed, 30 Dec 2009 18:44:00 -0600 (CST)

We need to have the ability to look at a mojo descriptor and see how it will change the build environment. This requires two things:

1. Cut off the loophole allowing unauthorized mutation of build state by making build state read-only to the mojo
2. Provide an API/annotation-set to allow explicit export of values from a mojo, where they will be incorporated into the build state.

This should enable things like determining whether a mojo generates sources, or collecting the source directories (even generated ones) by scanning the plugins configured for the build.

[MNG-656] lazily resolve extensions

Related — Thu, 14 Jan 2010 09:56:37 -0600 (CST)

try and resolve extensions only when they might be required. Currently, even clean:clean would resolve an extension for the project (not that projects will often have an extension, but this is still undesirable, especially if it is a snapshot).

[MNG-944] activation of a profile on some Project definition (artifactId/groupId)

Sat, 13 Dec 2008 18:35:20 -0600 (CST)

It would be helpfull to activate a profile
using the value of some property of the
pom beeing used. Like the project.artifactId.

In an multi project environement, the 'current'
project activate the profile.

[MNG-2021] Allow properties to be dom objects

Related — Fri, 7 Sep 2007 01:07:39 -0500 (CDT)

Allow properties like

<property>
<includes>
<include>whatever1/*.java</include>
<include>whatever2/*.java</include>
</include>
</property>

to avoid repeating stuff in the different plugins

Not very important if we have a way to share mojo configuration

[MNG-542] Allow properties to inherit from other properties

Related — Tue, 12 Jan 2010 11:21:22 -0600 (CST)

For example pom.build.outputDirectory (classes directory) should inherit from pom.build.directory. Same for all properties that are used to generate build data.

Why? Becasue otherwise it's downright impossible to change the location of the target directory (pom.build.directory) as you don't know beforehand all the plugins that are part of the lifecycle and how many properties they each have and their name.

For example in the clover plugin I need to set the target dir to another location so that main build data is not compromised. I can't do it as I can't controll all the properties that could possibly exist. I'd just like to set the pom.build.directory to a new value and be done with it.

[MNG-730] [language support] Ability to use single lifecycle with dynamic extension

Sat, 13 Dec 2008 18:35:23 -0600 (CST)

Currently maven-project, via maven-artifact-manager , uses pom packaging's value (also use by lifecycle) to lookup a ArtifcactHandler and then get the extension out of that artifact handler. This is one to one relationship, one lifecyle per artifact extension.

Because of this issue, I have to use one lifecycle per extension ( ie native-dll artifact hanlder will have dll extension)
for maven-native-plugin which has the following extension .dll, .exe, .lib, .so, si, .a and may be more

The work around still need the fix for ~~MNG-729~~

[MNG-860] Allow Mojos that don't participate in the lifecycle to be configured using profiles

Duplicate — Sat, 13 Dec 2008 18:35:06 -0600 (CST)

The particular use case here is setting the ${jdkName} variable to be used by the IDEA plugin are part of the generation of the IDEA project files. It would be nice to have this set across the board so that I don't have to specify it on the command line or in each POM (which would be very unwieldly). Chatting with John, it seems it would be reasonable only for Mojos that don't participate in the lifecycle as to ensure portability of the build. Mojos that are typically related to tooling are mojos that don't participate in the lifecycle like the IDE related plugins which are generally gear for a user specific setup. Here's an example of what might be nice to have in a settings.xml:

<profiles>
<profile>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-idea-plugin</artifactId>
<configuration>
<jdkName>/home/jvanzyl/jdk/1.5</jdkName>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profiles>

[MNG-1390] @requiresDependencyResolution in process-classes post compile

Wed, 30 Dec 2009 13:45:06 -0600 (CST)

I was looking back into some plugins I had written a while back and ran across an oddity.

it appears that when using a plugin in the process-classes phase, after the compiler plugin has done its thing, the @requiresDependencyResolution javadoc flag will toggle the presense of dependencies that are scoped to provided in the dependencies section when calling project.getCompileClasspathElements(); (a difference of 80 vs 24 when not using the flag and then using it)

—

this are two snippits of code from the plugin

/**

A plugin for generating * java file containing all the classes in a src tree.
*
@goal generate
@requiresDependencyResolution
@description Functions Generator plugin
@author jesse <jesse@g.com>
*/

List classpathFiles = project.getCompileClasspathElements();

URL[] urls = new URL[classpathFiles.size() + 1];

getLog().debug("" + classpathFiles.size());

for (int i = 0; i < classpathFiles.size(); ++i) { getLog().debug((String)classpathFiles.get(i)); urls[i] = new File((String)classpathFiles.get(i)).toURL(); }

urls[classpathFiles.size()] = new File( buildDirectory + "/classes" ).toURL();

URLClassLoader ucl = new URLClassLoader(urls, Thread.currentThread().getContextClassLoader());

being used with the following plugin declaration:

<plugin>
<groupId>gallup.maven</groupId>
<artifactId>services-provider-maven-plugin</artifactId>
<version>1.0.1</version>
<configuration>
<fullyQualifiedFileName>com/g/util/ServiceProvider.java</fullyQualifiedFileName>
</configuration>
<executions>
<execution>
<phase>process-classes</phase>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>

analyzing the debug output when I run the plugin without the @requiresDependencyResolution I get 80 dependencies and it builds out the classloader correctly..

but if I add the @requiresDependencyResolution statement I go down to 24 dependencies being put into the classloader...and the discrepency corresponds to the presense of the <scope>provided</scope> statement.

[MNG-1567] improvements to complex mojo configuration

Related — Fri, 27 Jun 2008 07:24:48 -0500 (CDT)

currently, you can specify an object in the configuration that allows nesting multiple levels of config. This is helpful, but it would be good to be able to validate those portions of the configuration as well as set default values, and make them extendable by making them fully fledged configured component requirements.

basically:

be able to specify expressions and default values within the fields of the object, not just the top mojo, as long as it is in the same source tree as the mojo (like extends)
to be able to put a polymorphic object in there without an implementation given in the pom. This might require selectors, and so might be best left until a later version (se elinked issue for a use case)

I haven't tried, but it might already be possible to do this (from components.xml), and we just need to wire up the tools to handle it.

[MNG-1823] dependencies with classifier mask transitive dependencies of same dependency without classifier

Related — Sat, 13 Dec 2008 18:34:48 -0600 (CST)

A module in cocoon has following dependencies :

<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-core</artifactId>
<version>2.2.0-SNAPSHOT</version>
<classifier>tests</classifier>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-core</artifactId>
<version>2.2.0-SNAPSHOT</version>
</dependency>

The first dependency is created by the core module using :

<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>

Now i would like the module to depend on the jar with classifier "tests" during the testing phase ie cocoon-core-2.2.0-SNAPSHOT-tests.jar, and during the normal compilation phase it should just use cocoon-core-2.2.0-SNAPSHOT.jar. IMO above dependencies express exactly this.

The problem is that maven somehow removes all transitive dependencies from cocoon-core-2.2.0-SNAPSHOT.jar when both dependencies are in place, breaking compilation. When i remove the dependency with the classifier, then all is fine (but ofcourse my tests can't run)

I hope above is clear, otherwise just ping me on irc

[MNG-1879] Allow dependencies to be defined in external profiles.xml for inclusion at build time when a profile is activated (and allow reuse of profies.xml)

Sat, 13 Dec 2008 18:35:23 -0600 (CST)

Here's a use-case where I believe it would make sense to allow <dependencies> to be defined for profiles in profiles.xml.

Lets says I have a web-project that sets up profiles.xml for target build environments that it can be deployed on. Target environments can each have
different J2EE containers. Now this is what happens when I setup my project for builds/deploys.

1) Set up a build control project, a minimal pom.xml that has contains SCM connection to my web-project above.

2) checks out profiles.xml first so now the build control project has a minimal pom + profiles.xml.

3) checks out the web-project under ${basedir}/target

4) I can activate a particular profile, based on which some operations can be done by a custom Plugin before an embedded instance of maven is spawned
and some goals (specific to that profile) are delegated down to the checked out project.

[MNG-1949] project-level plugin dependencies not handled correctly in multimodule builds

Duplicate — Mon, 28 Dec 2009 19:07:04 -0600 (CST)

plugin containers are only initialized once per build, which means they may contain incorrect project-introduced dependencies for project Y in a multimodule build (polluted by project X predecessor). We should look at ways of dumping plugin containers with project-specific configurations, or else providing a container overlay to handle project-specific dependencies, etc.

NOTE: This is tied into the notions of build extensions, which will have similar consequences on the core container.

[MNG-1982] wagons should be tolerant of incorrect configurations in entries within settings.xml

Sat, 13 Dec 2008 18:34:42 -0600 (CST)

basically, we need to soften the reaction to invalid configuration of a wagon...make it a warning instead of an exception.

[MNG-4223] Resolve expressions in POM artifact coordinates

Related — Mon, 29 Jun 2009 15:17:57 -0500 (CDT)

See: http://docs.codehaus.org/display/MAVEN/Artifact-Coordinate+Expression+Transformation