Building maven plugin should be easier

• Key: CACTUS-137
• Type: Improvement
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Felipe Leme
• Reporter: Felipe Leme
• Component/s: Maven Integration
• Affects Version/s: 1.7
• Fix Version/s: 1.7

Description

Building the maven integration plugin should be an automated task - right now, the developer must manually copy jars to his local maven repo.

Ideally, the whole Cactus should be build with Maven, but while that doesn't happen, we need a workaround. We have at least 2 options:

1.Modify root's build.xml to copy the JARs to the local repo
2.Modify maven.xml on integration/maven to do both jobs.

Each approach has its advantages and disadvantages:

Ant approach
------------

- D: requires a lot of Ant coding (once you get used to Maven, is hard to bo back to the task of writing Ant targets :-)
- D: it needs to check if user has maven installed, if $MAVEN_REPO, exists, etc...
- A: the process would be transparent for the maven integration module

Maven approach
--------------

The main issue with the Maven approach is that we have a chicken-egg p roblem: we would be copying the jars to the repo using maven, but maven wouldn't run because the dependencies check would fail. The solution would be overriding the jars on build.properties and creating a postGoal on plugin:install to copy the jars.

- A: easier to implement
- A: the process would be isolated to the maven integration module
- D: overriding the jars is kind of a hack solution


If we opt for the maven approach, I can work on a patch (well, I could do the same for the Ant approach too, but I rather not touch those evil scripts :-)



 

Comments

[Felipe Leme]

patch implementing the maven approach.

[Vincent Massol]

Hi Felipe,

Cool. Thanks for the patch. I was about to apply it when I noticed you've used a build.properties file. I'm reserving this file for user specific environmental variable only and it should never be checked in (hence the cvsignore). If the properties are supposed to be shared and I suppose they are, then they should go in project.properties.

Ok with this? :-)

Thanks

[Felipe Leme]

Hi Vincent,

I realized the build.properties is reserved to the user. But I think these properties can't go to the project.properties, as that file will be installed on the user's maven cache. I mean, my concern is that this way the maven.jar.overrides will always on by default (and the cactus jars pointing to the wrong places), because maven always reads the project.properties from each plugin (but I might be wrong - I'm not sure if maven really reads each plugin's project.properties - I know it reads the plugin.properties though).

Anyway, my current patch changes the comments on build.properties.sample stating that it should be added to build.properties, although that wouldn't solve the .cvsignore issue. So, another solution would be to instruct the user to append build.properties.sample to ${HOME}/build.properties (as that file has the 'highest priority' anyways).

So, what do you think?

-- Felipe

[Felipe Leme]

PS: by looking at some plugins project.properties, doesn't looks like they are used by maven, as some plugins defines some important properties like maven.junit.fork=yes and maven.changes.issue.template = %URL%/../browse/%ISSUE%

So, in this case I'm fine with using project.properties. But then another issue arises: why do we need to install project.properties on the plugin, if it's not used at runtime by maven?

[Felipe Leme]

Vincent,

Here is a new patch, this time using project.properties (and removing project.properties from POM's resources - I don't think it's necessary to include it in the plugin).

-- Felipe

[Felipe Leme]

New patch - the previous one didn't include the -13 on the files being copied.

[Vincent Massol]

Done.