Hi domi,
I merged the 2 plugins, as discussed almost 2 years ago :)
Any chance that you merge the pull request and release a new version of the
repository-connector-plugin any timme soon?
After the merge I would remove my repoclient-plugin Wiki page and update
the Wiki page of the repository-connector-plugin.
Regards,
Michael
On Tue, May 15, 2012 at 3:13 PM, Michael Rumpf <[email protected]>wrote:
> 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
> >
> >
> >
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
