Maven follow-up: building from repository source

[ruel.loehr]

I'll address each follow-up question in a distinct thread.

Follow up investigation #1:

Source in the repository. A goal we have had is to be able to pull down the source for a dependent component as part of a dependency relationship. Maven2 has a weak notion of this but not one to the point of actually being able to build the component artifacts from the respository source.

The use case I have in mind for this is that user a has checked out jbossas. They discover an issue with a thirdparty dependency (e.g. apache-log4j) and would like to see the source. Assuming that log4j has a src jar in the http repository or scm information defined, a custom plugin could be created which allows the user to pull down this source from a particular repository. To execute this plugin the user would issue:

mvn getSource:getSource -DgroupId=apache -DartifactId=log4j

This plugin would then add the log4j src as a top level component to the src tree.

As it stands today with out of the box functionality, the user would then make the necessary modifications to log4j and then build the new log4j module which would install the jar to the local repository. JBossAS would then build against this.

The ideal situation would be if the custom getSource plugin could not only retrieve the source, but inject the new source tree into the build such that later top level issued builds would compile not only jbossAS but the new log4j tree as well.

In order to accomplish this, the current architecture would need to be modified. The list of modules to build is statically defined in the top level pom file and is read upon build initiation. This would need to be abstracted out (to a props file), which could be added to dynamically by the get sources plugin.

I'm sifting through the source now to see what this would take and will follow up.

[ruel.loehr]

I can see two requirements for source in the http repository. First off, is the case of debugging with an IDE. A developer may run across the need to step into the source of a thirdparty component. The src zip or jar which would be attached to the binary would only contain the src files in the packaged format.

e.g. org/jboss/...

This functionality is handled out of the box by use of the eclipse plugin:
http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html

Sources can be downloaded when the .classpath and .project files are created. however, you cannot modify the src and then build against it.

This leads to the second item, a way to build against sources of dependencies. I'm limiting the scope here to the http repository. First off, a source jar would be required which contained not only the source, but the build file and this would need to have a reasonable file structure present within. It is possible to retrieve these jars, and expand them into the build src structure.

At this point, as previously stated the user could manually build the dependency, and then rebuild the entire project. The con to this is that an additional step is involved.

To make the dependency's src a standard part of the build, some type of persistence would have to take place in the modules description. This is easier on the user, but we run the risk of somebody checking in these changes.

The only flaw I see here is that you wouldn't be able to commit changes made to dependency src as they are not associated with cvs.

[starksm64]

To make the dependency's src a standard part of the build, some type of persistence would have to take place in the modules description. This is easier on the user, but we run the risk of somebody checking in these changes.

The only flaw I see here is that you wouldn't be able to commit changes made to dependency src as they are not associated with cvs.

I don't understand this statement. What is the persistent aspect in question here?

How I would like to see this implemented is that the source in the repository was broken into the raw source tree for the classes in the artifacts, and a build src tree into which the raw source tree would be expanded to create a buildable project structure.

The exisiting maven notion would remain intact. We would just be expanding this.