plugin.jelly patch as a file

Are you planning to include this patch in 1.10?

Hmmm... I hope that maven-plugins commiters will do that, if they found it valuable. It's only a proposal. If you want, you can use the patch yourself, but I don't know plans for maven-eclipse-plugin future.

I don't agree with

<j:if test="${depItem.getType().equalsIgnoreCase('jar')}">

What if I have an ejb-jar module in my dependencies? The type is ejb, not jar but still I want to include it in my eclipse sources.

This has proven very useful. I modified it to use the maven dist plug-in. This allows us to use the dist plug-in to generate the source code in a Maven standard way but also use this extension to download the code onto the local repository.

I hope this gets into the plugin soon.,

Scott

to http://jira.codehaus.org/browse/MPECLIPSE-60#action_28273 (by Stephane Nicoll)

OK. EJB could be included. In my project I just didn't use any EJB dependencies. Conclusion - GOOD IDEA.

to http://jira.codehaus.org/browse/MPECLIPSE-60#action_28350 (by Scott D. Ryan)

If you could, please, include diff/patch file in JIRA issue/comment.

Unfortunately, this patch does not handle SNAPSHOT dependencies. We have regular problems here with this patch.

If we depend on XXX-SNAPSHOT, the jelly code does not download the sources again.

The only solution so far is to clear our local cache and reinvoke the plugin. I think we could use maven standard dependencie's mechanism, right?

I can assist on this if necessary (Let me know)

to http://jira.codehaus.org/browse/MPECLIPSE-60#action_28830 (by Stephane Nicoll)

Of course you are welcome to assist on the plugin version/diff development!

In my project I do not use SNAPSHOT dependencies, so I guess that is why I had none of the problems you descibed. Conclusion: Please help if you have some time and ideas.

Just wonder, if the property should really be named "eclipse.source", since IDEA has the same functionality. "sourceCode" or "IDE.source" might be more appropriate.

to http://jira.codehaus.org/browse/MPECLIPSE-60#action_38644 (by Joerg Schaible)

Hmmm... since it is a eclipse plugin, and there was already a property called eclipse.dependency I've just added eclipse.source. There is nothing more general e.g. IDE.dependency, so there is neither IDE.source. It's an architectural issue. If there would be a general plugin core and more specific plugins to this plugin () for given IDEs there we could change the name to IDE.* and then filter it in (where?) some specific configuration file for given IDE (e.g. idea.properties or eclipse.properties). But for simplicity let's let it as it is - just eclipse.*

Its not just IDEs. Think about the javadoc URL. That can be used by eclipse plugin, but also by the javadoc plugin, that has nothing to do with IDEs. At our location, we have people working with different IDEs for the same project. So it seems quite silly to add the same information twice.

I've added an enhancement to maven-dist-plugin for creation and upload of source file distributions that are similar to javadoc distributions - MPDIST-21.
it allows to upload the source artifact to repository/${groupId}/src.jars/${artifactid}-{$version}.src.jar which is consistent with the javadoc plugin.
It allows me to check for the src jar in mevenide and download it if it exists. The repository/${groupId}/src/<name>.zip location seems lessconsistent and doesn't have a countepart on the upload side.

I don't think a dependency property is necessary, this can be trasparently checked for any dependency. Once we have a standard location and format of the source artifact.

> I don't think a dependency property is necessary, this can be trasparently checked for any dependency. Once we have a standard location and format of the source artifact.

Well, it could be. However, I think you might need to disable the behavior somehow (if I am not interested, the plugin should not check the repository for something I don't want).

maybe a separate goal or a goal parameter property could do?

do you have a usecase when you want to check for one dependency and not for another one? (if yes, a dependency property is probably necessary but I can't imagine the usecase)

No, I don't have such use case. If it could be disabled globally (property) that's fine with me.

Guys,

We need to include this in 1.11 I think. I don't think that M1 has a "java source" artifact right? Even if the patch sounds like a workaround, it's really needed. Without it, the source inclusion does not make much sense.

OK. So maven one has now a source plugin which is currently available in the plugins-sandbox.

The plugin deploys/installs the source archive in a location with maven2 legacy mode (i.e. java-sources/${artifactId}-${version}-sources.jar).

We now need to include download of such artifact. Milos Kleint has a solution for the mevenide plugin which I am gonna mimic.

A patch which allows to download java source archives from the repository. Only support the location handled by the maven source plugin.

handles SNAPSHOT artifacts.

OK ; It is resolved (finally!).

The plugin downloads source archives from the remote repository. This could be disabled, see the doc for more details.