I'm having issues with my IRC client since I switched machines... somebody
else might be able to help
On 3 July 2014 10:18, Paul Allen pal...@perforce.com wrote:
Hi Stephen,
Please can you create a new plugin entry for 'p4'.
github repo:jenkinsci/p4-plugin
artifactId:
Ulli,
Any chance you could create this for me?
Paul
On 3 Jul 2014, at 11:06, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
I'm having issues with my IRC client since I switched machines... somebody
else might be able to help
On 3 July 2014 10:18, Paul Allen
Hi Rob,
Was that the 'jenkinsci/perforce-plugin' you were trying to fork?
I was going to attempt a release under a new 'jenkinsci/p4-plugin' to avoid the
migration issues and use of the beta update centre. If I can work out a
migration route for old build Jobs then I could look to merge the
I was trying to fork p4paul/p4-jenkins
https://github.com/p4paul/p4-jenkins to jenkinsci/p4-plugin, as
requested. The bot seems to be having issues.
On Thu, Jul 3, 2014 at 9:57 AM, Paul Allen pal...@perforce.com wrote:
Hi Rob,
Was that the 'jenkinsci/perforce-plugin' you were trying to fork?
Thanks Rob!
I create a jenkins account too 'p4paul'. Does this need to be linked to the
project?
Just reading up on the page:
https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins
I'll need to refactor some code and update the POM so the names and packages
match.
Kind regards,
Paul
Sure; thanks for the clarification of the pattern.
Paul
On 30 Jun 2014, at 11:26, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
please do not put `-plugin` in the artifactId.
The pattern is:
github repo name is: X-plugin
artifactId is: X
groupId is: org.jenkins-ci.plugins
Hi Oleg,
On 27 Jun 2014, at 17:11, Oleg Nenashev o.v.nenas...@gmail.com wrote:
I would need to learn about configuration migration, if you know of another
tool or example that performs this task please let me know.
please do not put `-plugin` in the artifactId.
The pattern is:
github repo name is: X-plugin
artifactId is: X
groupId is: org.jenkins-ci.plugins
package name is one of:
* org.jenkinsci.plugins.X; or
* jenkins.plugins.X; or
* com.mycompany.jenkins.X (if you want to credit a company providing
I would need to learn about configuration migration, if you know of
another tool or example that performs this task please let me know.
https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+retaining+backward+compatibility
describes common cases, which may be used. When you finish the
Hi Guys,
Sorry I missed your earlier emails; it got buried in hundreds of Jenkins dev
emails.
I'm in the process of moving the project out of the Perforce Workshop into
GitHub. When I'm done you should be able to view the code under:
https://github.com/p4paul/p4-jenkins
Oleg: I don't
Hi Paul,
Oleg: I don't think I can guarantee a smooth migration, unless you want to
help out.
My managers don't want to invest into such migration without a middle-term
advantage.
They think that Perforce guys should be responsible for the compatibility
since we pay you money ;)
I definitely
Hi Oleg,
On 26 Jun 2014, at 15:53, Oleg Nenashev o.v.nenas...@gmail.com wrote:
My managers don't want to invest into such migration without a middle-term
advantage.
They think that Perforce guys should be responsible for the compatibility
since we pay you money ;)
I definitely don't want
Let's start with actually uploading it to github. Just create a new project
on your account and push the source to it.
Oleg, it sounds like having it in the same namespace might not be ideal
after all? Would you prefer to have it as a separate plugin entirely?
On Friday, 13 June 2014 11:46:50
Oleg, it sounds like having it in the same namespace might not be ideal
after all? Would you prefer to have it as a separate plugin entirely?
Yes, I think that the same workspace can be used only if Perforce guys
guarantee the smooth migration for users. AFAIK, there's no such short-term
plans,
On Thu, Jun 12, 2014 at 4:20 PM, Oleg Nenashev o.v.nenas...@gmail.com wrote:
I'm not sure about the behavior for
common update centers if the 2.x version goes to the main repo.
This might be an issue—1.x updates would not be offered to anyone
(assuming the core baselines for 1.x and 2.x are the
On Jun 16, 2014, at 22:32 , Jesse Glick jgl...@cloudbees.com wrote:
On Thu, Jun 12, 2014 at 4:20 PM, Oleg Nenashev o.v.nenas...@gmail.com wrote:
I'm not sure about the behavior for
common update centers if the 2.x version goes to the main repo.
This might be an issue--1.x updates would not
Hi Guys,
I have done some more work on the new Perforce plugin (see:
https://swarm.workshop.perforce.com/projects/p4-jenkins/files/main).
I hope that this now brings it up to the same level of features as the old one.
Please take a few minutes to skim through the user guide (there are lots of
We'll need it in github before we can really do anything at all with it, so
that's still the first step.
Personally, I think it should be put into a separate branch within the
perforce-plugin repo, and have it publish to the beta update center under
the same namespace, though I admit some
On 12.06.2014, at 18:07, Jesse Glick jgl...@cloudbees.com wrote:
just merge to master, change
2.0-beta-n-SNAPSHOT to 2.0-SNAPSHOT, and release
And maybe indicate incompatibility of existing configurations.
--
You received this message because you are subscribed to the Google Groups
Jenkins
2.0 should be indicate it, but the additional entry on Wiki is required to
explicitly describe the situation.
However, the 1.x version is not dead. I'm not sure about the behavior for
common update centers if the 2.x version goes to the main repo.
2014-06-12 23:58 GMT+04:00 Daniel Beck
Hi there,
P4Java 2013.1 (and 2013.2) supports Perforce servers as old as 2005.2:
ftp://ftp.perforce.com/perforce/r13.1/doc/user/p4javanotes.txt
Requirements
* Perforce server at Release 2005.2 or higher.
Hope this helps!
-Marc
On Monday, May 26, 2014 4:39:58 AM UTC-7, Kanstantsin Shautsou
Does the p4java support all perforce server versions?
For example, will 2013.1 p4java support connections with 2009.1 server?
Because with current wrapper i can select different binaries.
--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To
Hi Oleq,
Sorry for any delay in communication; I have been out on holiday and catching
up with some other projects.
For the moment we are releasing the beta version of the plugin from our own
Workshop for early adopters to try out and provide feedback. My current focus
is to provide feature
Hi Paul,
Is there any update on the topic?
- I don't see any new Perforce plugins in the repo, the development is
not very active as well
- I still think that usage of the same [plugin name/id] is a good idea.
All users with a default update center won't be able to select from
Hi Guys,
I know there has been a lot of discussion around the new plugin, but referring
to Kawaguchi-san's email (below) I am happy to go with option 3 and distribute
through the beta update centre for the time being.
Please let me know where to deploy the code and any changes that are need in
Unless I've missed a post, can someone tell me what's currently wrong with
the current plugin that warrants a pretty much from the ground up new
plugin? Speaking as a heavy user of Perforce if people are currently using
the existing plugin what issues are people having?
What worries me is
Hi Niksan,
The Jenkins plugin had popped up on Perforce's radar a few times; often for
performance issues. With our new Swarm tool we wanted a better Continuous
Build experience and needed to update the plugin. Starting that process we
identified a few issues:
1. Maintainability - It's
I don't have have any issues with the current plugin bar a few cosmetic
fixes that can be overcome by using groovy the issues are mainly with p4
itself but you have your own forum where we highlight those. :)
My biggest concern is the onus to keep the current plugin in development
when a known
I meant point 1 and 4 are the same, not point 1 and 3. :)
--
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 jenkinsci-dev+unsubscr...@googlegroups.com.
For
Hi Niksan,
On 23 Apr 2014, at 15:48, Niksan sumot...@googlemail.com wrote:
Point 3, this is the big one for me, I'm an advocate for using a command line
wrapper in regards to Perforce, this is with experience of using the .NET API
and the fact the APIs are closed source so you're at mercy to
Hi Steve,
Thanks for your reply, I have added comments below...
[Steve RE: Credentials]
The new plugin extends Jenkins Credentials into two new types. Perforce
Password credential and Perforce Ticket credential; these both support SSL
and P4TRUST finger prints. I did look at the password
Hi Guys,
Sorry I han't been checking email over the Easter break.
I like Kohsuke Kawaguchi's idea of running the two together, it will allow user
to try out the now plugin and provide feedback. I'm not sure how easy it would
be to provide a migration path for each Build Job's configuration,
I had tried to make the SCM polling more efficient and letting Perforce
manage it's own workspaces, after all this is what Perforce was designed to
do.
Can you please explain this statement? Perforce has always forced the user
to manage workspaces by hand, and is a major pain point for any sort
On Sunday, 20 April 2014, Paul Allen pal...@perforce.com wrote:
Hi Guys,
Sorry I han't been checking email over the Easter break.
I like Kohsuke Kawaguchi's idea of running the two together, it will allow
user to try out the now plugin and provide feedback. I'm not sure how easy
it would
I'm just putting those two things out there as it is better to integrate
credentials from the beginning... and a smart SCM-API implementation can be
leveraged to deliver better polling support for regular job types... which
again calls for early integration.
You probably don't need P4 specific
You probably don't need P4 specific credential type. You should be able
to get away with a Domain requirements/specification and the standard
username/password credentials type
You are right, but such migration requires 1.509.x to be a minimal
supported version.
The proposed PR has been created
I'm waiting for Rob and Paul to agree on the approach forward. I think
we'd be happy to honor that, since you guys are the ones that are doing
the actual work.
Where Jesse and I are coming from is to try to understand the message to
the existing users, because Perforce plugin is widely
I didn't realize that you could release two versions of a plugin at the
same time to two different update centers. I think your proposal is
probably the best option here.
On Fri, Apr 18, 2014 at 11:31 AM, Kohsuke Kawaguchi
kkawagu...@cloudbees.com wrote:
I'm waiting for Rob and Paul to agree
On Fri, Apr 18, 2014 at 1:31 PM, Kohsuke Kawaguchi
kkawagu...@cloudbees.com wrote:
We could put both current and the new in the same repo, and call the new one
perforce plugin 2.0. […]
We can have alpha/beta releases of 2.0 in parallel to updates to 1.x
releases. People on the beta update
On Thu, Apr 17, 2014 at 5:20 AM, pallen pal...@perforce.com wrote:
Perforce would like to release a new re-architected Jenkins plugin called
'p4'.
Is this intended to be a full replacement for the existing
jenkinsci/perforce-plugin? If so, it should reuse that repository and
The existing 'perforce' plugin is used by many of our customers and I was
concerned that effectively replacing it with the new plugin may upset some
users.
Whilst the new plugin provides all the basic SCM functions, it is not yet as
feature rich. We plan to add features over the next few
On Thu, Apr 17, 2014 at 11:51 AM, Paul Allen pal...@perforce.com wrote:
Whilst the new plugin provides all the basic SCM functions, it is not yet as
feature rich. We plan to add features […]
[…] perhaps there is a way to branch (fork) the old codebase into a legacy
area?
A bit more work,
I have been discussing the plugin for sometime over email.
I'll CC Rob and the others...
Paul
On 17 Apr 2014, at 16:59, Jesse Glick jgl...@cloudbees.com wrote:
On Thu, Apr 17, 2014 at 11:51 AM, Paul Allen pal...@perforce.com wrote:
Whilst the new plugin provides all the basic SCM functions,
I thought it was decided that refactoring the old plugin was the better way
to go? It's less of an impact on users, and preserves all of the required
functionality.
If not, then just make a new repo, I guess...
On Thursday, 17 April 2014 10:52:20 UTC-6, pallen wrote:
I have been discussing
44 matches
Mail list logo
