Hi domi,
merging our plugins seems to be a good idea as the functionality is
mostly overlapping.
The use-case I'm focusing on is that a team does several releases
(i.e. release candidates). After some sort of acceptance testing one
of the release candidates is chosen as the final release artifact and
pushed to a customer FTP server or deployed directly on a WebSphere
application server.
After digging through the documentation and the codebase (only a bit)
of the repository-connector plugin I see the following differences
between the 2 plugins:
1. Your plugin does the download itself, whereas I use the Ant
(Gradle) built-in tasks to perform this job.
=> I'm not yet sure what is better. If the plugin does the download,
then there is no need to pass the credentials to the script (security
aspect).
In my opinion there is only one important requirement. The download
folder must be relative to the project that contains the Ant/Gradle
script so that the project is self contained. This also simplifies
testing the Ant/Gradle scripts only, as you can put some files into
the folder and then run the script on them.
But for displaying purposes and because I need to create a similar
folder structure on an FTP server, I need the version, the groupId and
the artifactId as properties so that I can issue FTP mkdir commands to
create the folders.
2. I need patterns to select the artifact as our release builds have
multiple artifacts: a binary ZIP, a source ZIP, and a documentation
ZIP.
=> The extension field in your plugin could be used as pattern, the
question is whether the Aether API can handle patterns.
3. You support Maven repositories only (via the Aether API), but I've
seen a few projects where SVN was used as a poor man's Maven
repository.
=> Maybe the Aether API can access those kind of repositories too!?
4. When trying to install your plugin into a local Jenkins instance
(inside the repoclient-plugin project and started with mvn clean
hpi:run) I get the following exception when opening the Jenkins global
configuration:
=> I'm quite new to Jenkins plugin development, so I'm not sure
whether this is related to your plugin!? However, when I disable your
plugin the global configuration is shown without errors.
INFO: Jenkins is fully up and running
2012-05-15 11:46:20.871::WARN: EXCEPTION
javax.servlet.ServletException:
org.apache.commons.jelly.JellyTagException:
jar:file:/C:/work/workspaces/misc/github/jenkins/plugins/repoclient-plugin/target/work/webapp/WEB-INF/lib/jenkins-core-1.464.jar!/lib/form/section.jelly:39:46:
<st:adjunct> org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.
(Caused by org.apache.commons.logging.LogConfigurationException:
Invalid class loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.)
(Caused by org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class
loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.
(Caused by org.apache.commons.logging.LogConfigurationException:
Invalid class loader hierarchy. You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.))
at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
...
Regards,
Michael
On Sun, May 13, 2012 at 9:40 AM, domi <[email protected]> wrote:
> Michael,
> I have granted you commit access to the plugins, but lets really talk about
> merging the two plugins, I really think this would make sense and give a
> great benefit for users.
> e.g. global repositories are to be configured for both plugins otherwise.
> regards Domi
>
> On 13.05.2012, at 09:22, domi wrote:
>
>
> Hi Michael,
> this is close to the functionality of this
> plugin: https://wiki.jenkins-ci.org/display/JENKINS/Repository+Connector+Plugin
> I think we should check if it would make sense to merge the two…
> About your proxy implementation, you should have a look at
> this: https://wiki.jenkins-ci.org/display/JENKINS/Async+Http+Client+Plugin
> what do you think?
> regards Domi
>
>
> On 12.05.2012, at 22:48, Michael Rumpf wrote:
>
> Hi,
>
> I have written a Maven Repository Client Plugin and put the source code on
> github:
> https://github.com/mrumpf/repoclient-plugin
>
> My github ID is "mrumpf".
>
> ### TODOs ###
> * DONE Adapt pom.xml to Jenkins plugin structure
> * Initial Wiki page created, but the plugin id is missing
> https://wiki.jenkins-ci.org/display/JENKINS/Maven+Repository+Client
> * Add documentation
> * Classification (Wiki Labels)
> The plugin is behaving like a build wrapper, although it does not implement
> the BuildWrapper API.
> * CI Build
>
> Is there anything else left to do?
>
> Regards,
> Michael
>
>
>
