New plugin Perforce

[pallen]

Hi Devs,

Perforce would like to release a new re-architected Jenkins plugin called 'p4'.  

Please can you create a new GitHub repo 'p4' and grant me commit access, my GitHub ID is p4paul. 

The plugin development is currently hosted here:  https://swarm.workshop.perforce.com/projects/p4-jenkins/

I think I have found most of the pages for releasing a new plugin, but any tips would be nice.

Kind regards,

Paul

[Jesse Glick]

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
artifactId/shortName. If not, then the relationship between the
plugins needs to be clarified.

[Paul Allen]

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 months and are keen to involve the community as much as possible.

We would obviously like to use the 'Perforce' name space; perhaps there is a way to branch (fork) the old codebase into a legacy area?

Paul

> --
> 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-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--------------------------------------------------------------------------------
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the system manager. Please
note that any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of Perforce Software. Finally,
the recipient should check this email and any attachments for the presence of
viruses. Perforce Software accepts no liability for any damage caused by any
virus transmitted by this email.

Perforce Software UK Ltd is registered in England and Wales as company no.
3816019 at the following address: West Forest Gate, Wellington Road, Wokingham,
RG40 2AT, UK
--------------------------------------------------------------------------------

[Jesse Glick]

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, but arguably better for users, would be to include
the new refactored implementation inside the existing plugin (in trunk
versions). For a time, users of the plugin would see two SCM
options—Perforce (v1) and Perforce (v2)—with somewhat different
configuration UIs and functionality. They could experiment with
switching to v2, or go back for a while, on a project-by-project
basis. You could even decide that v1 configurations restricted to a
certain set of commonly used features would be safe to automatically
upgrade (i.e., readResolve) to a v2 configuration. Eventually the v1
implementation could be dropped, or rather exist only as a class with
a readResolve method.

This is of course assuming that the current maintainer(s) of
perforce-plugin are aware of your effort and on board with it.

[Paul Allen]

I have been discussing the plugin for sometime over email.

I'll CC Rob and the others...

Paul

[Rob Petti]

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...

[Paul Allen]

Hi Rob,

The refactoring effort would be so wide spread there would be very little, if anything, left.

By removing the underlying p4 command wrapper (Tek42) and replacing it with the p4-java api would require a re-write of all the functions. In addition the behavioural changes to the use of Perforce workspaces and authentication would change most of the user interface.

I suggest that we either create a new plugin 'p4' or fork/rename the existing plugin. A new plugin would be less disruptive to the existing user base and give the opportunity for a clean start.

Paul

[Stephen Connolly]

hope you are integrating with the credentials and the scm-api plugins

On 18 April 2014 10:33, Paul Allen <pal...@perforce.com> wrote:

Hi Rob,

The refactoring effort would be so wide spread there would be very little, if anything, left.

By removing the underlying p4 command wrapper (Tek42) and replacing it with the p4-java api would require a re-write of all the functions.  In addition the behavioural changes to the use of Perforce workspaces and authentication would change most of the user interface.

I suggest that we either create a new plugin 'p4' or fork/rename the existing plugin.  A new plugin would be less disruptive to the existing user base and give the opportunity for a clean start.

Paul

On 17 Apr 2014, at 19:23, Rob Petti <rob....@gmail.com> wrote:

> 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 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, 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, but arguably better for users, would be to include
> > the new refactored implementation inside the existing plugin (in trunk
> > versions). For a time, users of the plugin would see two SCM

> > options--Perforce (v1) and Perforce (v2)--with somewhat different

[Oleg Nenashev]

@Stephen

Yes, of course. In the case of the legacy plugin refactoring there will be a P4CredentialsProvider extension point, which will have the implementation for "Credentials Plugin" (https://github.com/jenkinsci/perforce-plugin/pull/45). AFAIK, Paul has implemented the integration in his plugin PoC. SCM-API would be useful as well.

The real issue is an approach to be used...

• Paul (from the Perforce SCM vendor) wants to create a new plugin and to sacrifice some features from the previous one.
• Seems that other discussion participants (including me) prefer the refactoring approach with a smooth migration for users.
• From my side, the Perforce plugin is relatively stable, so there is no urgent need to spend many man-weeks to integrate all required features to the new plugin and to migrate existing jobs.
  

Nobody wants to waste his efforts, hence the maintenance/development of the original Perforce plugin just hangs. This plugin definitely requires a major refactoring (the Hudson compatibility has been maintained for a long time, so there is no support of tasty Jenkins features), so we definitely need to select a way to move forward.

BR, Oleg Nenashev

[Stephen Connolly]

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 credential type. You should be able to get away with a Domain requirements/specification and the standard username/password credentials type

[Oleg Nenashev]

> 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 in away, which allows to retain the current minimal version (with an external implementation of Credentials)

If we start the development of "Perforce 2.0", all existing approaches should be re-considered together with other community members.

[Kohsuke Kawaguchi]

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 used.


If you expect both current and new plugins to co-exist going forward,
that's the least preferable outcome from users' PoV.

The next better one is that you expect the current plugin to become
dormant and all the efforts to go to the new plugin. It's still
disruptive for users, but at least there's a clarity in the direction.

The next better one is that you two agree that the current plugin will
become dormant and the new one will take over, then we work out the data
migration compatibility between the current and new plugin, without
preserving code compatibility. This is pretty good for users, as they
don't have to go through disruptive changes.

Then the final one is to try to maintain some/all of the code
compatibility. If there are plugin out there that depends on the
perforce plugin, this will make their users happy.


Without much experience of Perforce, what I'd like to encourage you to
consider is the third option, and here is one way of doing it.

We could put both current and the new in the same repo, and call the new
one "perforce plugin 2.0." They need not share the code at all. 2.0
would work toward feature parity with 1.0. Existing Jenkins devs can
help create migration shim in the 2.0 branch.

We can have alpha/beta releases of 2.0 in parallel to updates to 1.x
releases. People on the beta update center will get this 2.0 beta
versions. When 2.0 is in feature parity, we can have the official 2.0
release.

Or if we discover that feature parity is unattainable, we can rename the
new version to another name and release it as a separate plugin.

On 04/18/2014 02:33 AM, Paul Allen wrote:
> Hi Rob,
>
> The refactoring effort would be so wide spread there would be very little, if anything, left.
>
> By removing the underlying p4 command wrapper (Tek42) and replacing it with the p4-java api would require a re-write of all the functions. In addition the behavioural changes to the use of Perforce workspaces and authentication would change most of the user interface.
>
> I suggest that we either create a new plugin 'p4' or fork/rename the existing plugin. A new plugin would be less disruptive to the existing user base and give the opportunity for a clean start.
>
> Paul
>
> On 17 Apr 2014, at 19:23, Rob Petti <rob....@gmail.com> wrote:
>
>> 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 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, 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, but arguably better for users, would be to include
>> > the new refactored implementation inside the existing plugin (in trunk
>> > versions). For a time, users of the plugin would see two SCM

>> > options--Perforce (v1) and Perforce (v2)--with somewhat different

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins

[Rob Petti]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--------------------------------------------------------------------------------
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the system manager. Please
note that any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of Perforce Software. Finally,
the recipient should check this email and any attachments for the presence of
viruses. Perforce Software accepts no liability for any damage caused by any
virus transmitted by this email.

Perforce Software UK Ltd is registered in England and Wales as company no.
3816019 at the following address: West Forest Gate, Wellington Road, Wokingham,
RG40 2AT, UK
--------------------------------------------------------------------------------

[Jesse Glick]

On Fri, Apr 18, 2014 at 1:31 PM, Kohsuke Kawaguchi
<kkawa...@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 center will get this 2.0 beta versions.
> When 2.0 is in feature parity, we can have the official 2.0 release.

Is there some advantage of this over my suggestion—to add the new SCM
implementation to a single release line of the same plugin, marking
the original one as somehow deprecated in labels & help text? There
are clearly some disadvantages:

· Users will not know they even have the option of using a new system
unless they enable the experimental UC, drastically reducing the
number of people who will try it.
· Users would not be able to try out the new implementation on one or
two experimental jobs while leaving more important jobs in a stable
configuration. They would have to update the plugin to 2.0 beta <n>,
restart Jenkins, then update the configuration of all of their jobs
not yet handled by automatic data migration, and hope there are no
critical regressions.
· Similarly, users deciding that 2.0 is not yet ready would have to
deal with downgrading to 1.0 via Plugin Manager (*), restarting
Jenkins, then probably reconfiguring all Perforce-based jobs even if
they did not use any 2.x features (since 1.x would presumably not be
able to read any 2.x data).

In a nutshell, I am suggesting to move linearly forward, rather than
using branches, making the parallel options available via two
SCMDescriptor’s in independent package hierarchies.


(*) Which is not straightforward if they went from 1.x to 2.0 beta 1
to 2.0 beta 2, since PM would offer to downgrade only to 2.0 beta 1.
They would have to manually download 1.x and install it via the
Advanced tab.

[Paul Allen]

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, but this would simplify adoption.

... Just seen Jesse's post; perhaps I don't appreciate the differences. Allowing the two code bases to co-exist (effectively two plugins in one). The UI can than just show Perforce-1 / Perforce-2; as we progress this could change to Perforce-Deprecated / Perforce, then finally just Perforce.


[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 and SSL credentials, but Perforce has some specifics P4TICKETS etc..

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. I was not aware of the 'SCM-API', is there any docs/guide like:

https://wiki.jenkins-ci.org/display/JENKINS/SCM+plugin+architecture

As Oleg mentioned there are features that I haven't had time to port; these shouldn't take long but I would like to involve the community and especially the authors.

I'm back in on Tuesday; will try and keep an eye on the posts...

Thank you all for your involvement, I'm pleased there is so much interest and help.

Kind regards,
Paul

> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Jenkins Enterprise, our professional version of Jenkins
>

[Rob Petti]

> 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 of automation. If you mean using the build workspace to determine if there are any changes, this won't work for several reasons, which is why the current plugin implements polling by tracking and comparing the latest changeset number.

[Stephen Connolly]

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 be to provide a migration path for each Build Job's configuration, but this would simplify adoption.

... Just seen Jesse's post; perhaps I don't appreciate the differences.  Allowing the two code bases to co-exist (effectively two plugins in one).  The UI can than just show Perforce-1 / Perforce-2; as we progress this could change to Perforce-Deprecated / Perforce, then finally just Perforce.


[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 and SSL credentials, but Perforce has some specifics P4TICKETS etc..

Sounds like you've implemented one too many.

You should not be implementing a user+pass credential type at all. The ticket credential type is fair enough... In principle (I have not looked at your code mind)

 

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.  I was not aware of the 'SCM-API', is there any docs/guide like:

  https://wiki.jenkins-ci.org/display/JENKINS/SCM+plugin+architecture

No docs yet. It's needed to allow multi-branch support ala literate project type (though no limited to literate)

Subversion, git and hg all have implementations of the SCM-api.

It impacts polling as you want to expand the scope of what you find info about, so eg

* subversion maintains a map of latest revisions of various paths... This map will in future be used to reduce the amount of polling that jobs need... At present only literate takes advantage of the map (waiting until I feel the credentials support has bedded down)

* git and hg maintain a local checkout which (git) can be used / (hg) is used to speed up checkout on slaves and reduce the amount of querying

Once SCM-api us fully integrated these plugins will have effectively much more performant polling whereby eg push notifications get merged into local stores so that 99% of polling operations are served from a local cache (fed by both other jobs off same repo and push notifications)

--
Sent from my phone

[Paul Allen]

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 and SSL credentials, but Perforce has some specifics P4TICKETS etc..
>
> Sounds like you've implemented one too many.
>
> You should not be implementing a user+pass credential type at all. The ticket credential type is fair enough... In principle (I have not looked at your code mind)

I may have taken the use of your credentials too far, but it makes a very neat solution for Perforce authentication. We can even extend the pattern to Perforce cert based SSO later. Do try it out if you have a moment or I can send a screen shot if you are interested.

We try to discourage the user of passwords from a security perspective and encourage our users to use session tickets. Tickets are bound to a connection, this is why I store the Perforce connection. I also allows users to test the credential with the validate button.

> 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. I was not aware of the 'SCM-API', is there any docs/guide like:
>
> https://wiki.jenkins-ci.org/display/JENKINS/SCM+plugin+architecture
>
> No docs yet. It's needed to allow multi-branch support ala literate project type (though no limited to literate)
>
> Subversion, git and hg all have implementations of the SCM-api.
>
> It impacts polling as you want to expand the scope of what you find info about, so eg
>
> * subversion maintains a map of latest revisions of various paths... This map will in future be used to reduce the amount of polling that jobs need... At present only literate takes advantage of the map (waiting until I feel the credentials support has bedded down)
>
> * git and hg maintain a local checkout which (git) can be used / (hg) is used to speed up checkout on slaves and reduce the amount of querying
>
> Once SCM-api us fully integrated these plugins will have effectively much more performant polling whereby eg push notifications get merged into local stores so that 99% of polling operations are served from a local cache (fed by both other jobs off same repo and push notifications)

I'll take a look at your code/implementations when I'm back in the office, so I can understand if this polling is needed this way in Perforce. Perforce is unique in the way that stores (server side) a lot of information about what is in a client's workspace.

Kind regards,
Paul

[Niksan]

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 that the current plugin has been through its cycle of real world usage for bug finding, a new plugin to me means that cycle has to happen again. Like I say, I'm curious what's being brought to the table here, I'd hate to see the current plugin go stale as it's the only reason we're currently using Jenkins at all is because it's one of the few CIs that have streamed depots working out of the box.

[Paul Allen]

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 old/deprecated; large portions are based on Hudson not Jenkins
2. Efficiency - Slow and inefficient use for workspaces and sync
3. Perforce API - New plugin will support P4Java and not the command wrapper
4. ExtensionPoints - Split the code base into multiple extension points for clarity
5. Shelving Support - Allow shelving for building code reviews before submit
6. Credentials - Support Jenkins Credentials for managing many jobs

The current plan is to release the two plugins in parallel, allowing users to try out the new plugin. Then migrating the old to new plugin over a few releases to smooth over any rough edges. Shelving is already in and we hope to add many of the new features available in Perforce.

If you have any specific concerns or feature you would like, do please let us know.

Kind regards,
Paul

On 23 Apr 2014, at 14:26, Niksan <sumo...@googlemail.com> wrote:

> 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 that the current plugin has been through its cycle of real world usage for bug finding, a new plugin to me means that cycle has to happen again. Like I say, I'm curious what's being brought to the table here, I'd hate to see the current plugin go stale as it's the only reason we're currently using Jenkins at all is because it's one of the few CIs that have streamed depots working out of the box.
>

> --
> 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-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Niksan]

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 replacement is on its way.

In regards to your points, 1 and 3 pretty much boil down to the same thing.
Point 2 I've not personally seen and I'm not sure how a sync can be more efficient than calling p4 sync, as for efficient use of workspaces you'd have to elaborate on that.
Point 6 I've no idea how that would make it easier to manage many jobs but interested to hear.
Point 5 seems like something that could easily be added to the existing plugin.

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 what the API provides, you don't have this issue using the command line wrappers and in general you have more power at your hands without the need for the API to be fixed or expose functionality.

I may be in a minority on the point above, I just have concerns that when it comes to new features, P4Api will get in the way.

[Niksan]

I meant point 1 and 4 are the same, not point 1 and 3. :)

[Paul Allen]

Hi Niksan,

On 23 Apr 2014, at 15:48, Niksan <sumo...@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 what the API provides, you don't have this issue using the command line wrappers and in general you have more power at your hands without the need for the API to be fixed or expose functionality.
>
> I may be in a minority on the point above, I just have concerns that when it comes to new features, P4Api will get in the way.

You will be pleased to hear that the .NET API is now open source and p4-java is in the process of being opened.

They are on our Workshop: https://swarm.workshop.perforce.com/projects/perforce-software-p4api-net/

Paul

[Paul Allen]

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 the POM.

Kind regards,
Paul

[Oleg Nenashev]

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 various versions. Since you don't provide migration features, such approach will destroy many Jenkins installations with P4 when you release the plugin to the main repo
  
• As you know, we've decided to continue the development of the original Perforce plugin.
  

In my company several groups concluded that the new P4 plugin cannot be adopted in the medium-term perspective. 
Probably, you should reconsider your approach if you want to improve the overall user experience of existing customers.

Best regards,
Oleg Nenashev

понедельник, 28 апреля 2014 г., 13:35:34 UTC+4 пользователь pallen написал:

[Paul Allen]

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 parade with the old plugin and to look at a way to ease the migration process.

With some maturing of the new plugin, I still hope to be able to release it under the Jenkins community. If you have identified missing features or have suggestions on the migration please let me know. I am keen to bring in as much help as possible.

Kind regards,
Paul

[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.

[Marc Wensauer]

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

[Paul Allen]

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 screen shots, so it won't take log):

https://swarm.workshop.perforce.com/projects/p4-jenkins/view/main/docs/UserGuide.pdf

I would like to get this out into the Jenkins community, but I am going to need your help.

If any one is keen to use the existing 'Perforce' name space then I will need help to deploy this (whether under the beta update centre, or as a branch). Alternatively, I could use a new 'p4' name space, but again I would appreciate help with deploying this.

Kind regards,
Paul

On 21 May 2014, at 10:06, Paul Allen <pal...@perforce.com> wrote:

> Hi Oleg,

[Rob Petti]

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 ignorance as to how that would work with the release plugins and tagging. If nobody sees any issues with this plan, then I say go ahead with it.

[Jesse Glick]

On Thu, Jun 12, 2014 at 11:13 AM, Rob Petti <rob....@gmail.com> wrote:
> publish to the beta update center under
> the same namespace, though I admit some ignorance as to how that would work
> with the release plugins and tagging.

I think everything would “just work” if (1) the new code is in a
branch such as ‘v2’, (2) it uses a newer version, and (3) that new
version includes ‘beta’ in the name: so start with
2.0-beta-1-SNAPSHOT. You can still cut 1.x releases from the ‘master’
branch as usual, but if you

git checkout v2 && mvn -B release:{prepare,perform}

then you will produce 2.0-beta-1, 2.0-beta-2, etc. tagged
appropriately on the branch and visible only on the experimental
update center. maven-release-plugin is smart enough to stay on the
current branch, and update only the last numeric component. If and
when you want to switch to v2 for real, just merge to master, change
2.0-beta-<n>-SNAPSHOT to 2.0-SNAPSHOT, and release.

[Daniel Beck]

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.

[Oleg Nenashev]

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.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/v-u3HRvFCi8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

[Paul Allen]

Hi Guys,

Please can someone help create the branch on GitHub and detail how you would like me to add the code.
Strangely enough I know very little about git and GitHub ;-)

My GitHub id is p4paul

In addition to the Wiki notes on version, I could add another page for the user guide and details of the new plugin.

Thanks,
Paul

> 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-de...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[Jesse Glick]

On Thu, Jun 12, 2014 at 4:20 PM, Oleg Nenashev <o.v.ne...@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 same).

[Kanstantsin Shautsou]

> --
> You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/v-u3HRvFCi8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

If it won’t have automatic migration and config compatibility, then better put it as a separate plugin.
Plus I am afraid that the developers will not support some features in future In this case people may live and support current plugin.

[Rob Petti]

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?

[Oleg Nenashev]

> 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, hence I would like to keep plugins separately.

If the new plugin becomes a mainline, we can always deprecate the existing plugin or to replace it by the migration assistant (which will depend from the new plugin).

[Paul Allen]

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 think I can guarantee a smooth migration, unless you want to help out.

For the short term a separate namespace might be best, but I will leave that with you. If we don't end up using the Perforce namespace, I had thought about splitting the plugin into separate projects:

p4-core [required] sync, change logging, and repo browsing
p4-credentials [required] server auth
p4-review [optional] Swarm code review
p4-tagging [optional] Labels

Kind regards,
Paul

[Oleg Nenashev]

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 don't want to spend my spare time for such activity.

If we don't end up using the Perforce namespace, I had thought about splitting the plugin into separate projects

• Is there any need to keep p4-credentials and p4-core separately?
• Probably, it could be useful to have p4-api (Credentials, P4Java wrappers, etc.) and p4-scm plugins
• p4-labels could be merged with p4-scm

I suppose we can go forward with independent workspaces since you agree with such approach

Best regards, Oleg Nenashev

[Paul Allen]

Hi Oleg,

On 26 Jun 2014, at 15:53, Oleg Nenashev <o.v.ne...@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 to spend my spare time for such activity.

I totally understand; the migration is in the back log, but not something I will be able to work on right now. Migrations can be tricky, especially if the dataset has had older versions or not totally clean.

I would need to learn about configuration migration, if you know of another tool or example that performs this task please let me know.

> If we don't end up using the Perforce namespace, I had thought about splitting the plugin into separate projects
> • Is there any need to keep p4-credentials and p4-core separately?
> • Probably, it could be useful to have p4-api (Credentials, P4Java wrappers, etc.) and p4-scm plugins
> • p4-labels could be merged with p4-scm

> I suppose we can go forward with independent workspaces since you agree with such approach

I would have preferred a branch on the 'Perforce' name-space, but rather than delay the release any longer I am happy to go with an alternate name. Perhaps later on, if we can provide a suitable migration path, we could look to merge the two name spaces.

Kind regards,
Paul

[Oleg Nenashev]

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 implementation, it may be possible to migrate configs by redirecting XStreams. Legacy configurations can be handled by existing routines in PerforceSCM (e.g. "update to the version XXX before the migration")

I would have preferred a branch on the 'Perforce' name-space, but rather than delay the release any longer I am happy to go with an alternate name.

I'd guess you would prefer org.jenkinsci.plugins.perforce.X (or even com.perforce.jenkinsci.plugins.perforce.X) instead of the legacy hudson.plugins.perforce.X

2014-06-27 0:11 GMT+04:00 Paul Allen <pal...@perforce.com>:

Hi Oleg,

On 26 Jun 2014, at 15:53, Oleg Nenashev <o.v.ne...@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 to spend my spare time for such activity.

I totally understand; the migration is in the back log, but not something I will be able to work on right now.  Migrations can be tricky, especially if the dataset has had older versions or not totally clean.

I would need to learn about configuration migration, if you know of another tool or example that performs this task please let me know.

> If we don't end up using the Perforce namespace, I had thought about splitting the plugin into separate projects

>       * Is there any need to keep p4-credentials and p4-core separately?
>       * Probably, it could be useful to have p4-api (Credentials, P4Java wrappers, etc.) and p4-scm plugins
>       * p4-labels could be merged with p4-scm

> I suppose we can go forward with independent workspaces since you agree with such approach

I would have preferred a branch on the 'Perforce' name-space, but rather than delay the release any longer I am happy to go with an alternate name.  Perhaps later on, if we can provide a suitable migration path, we could look to merge the two name spaces.

Kind regards,
Paul

--------------------------------------------------------------------------------
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the system manager. Please
note that any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of Perforce Software. Finally,
the recipient should check this email and any attachments for the presence of
viruses. Perforce Software accepts no liability for any damage caused by any
virus transmitted by this email.

Perforce Software UK Ltd is registered in England and Wales as company no.
3816019 at the following address: West Forest Gate, Wellington Road, Wokingham,
RG40 2AT, UK
--------------------------------------------------------------------------------

[Paul Allen]

Hi Oleg,

On 27 Jun 2014, at 17:11, Oleg Nenashev <o.v.ne...@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.
>
> https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+retaining+backward+compatibility describes common cases, which may be used. When you finish the implementation, it may be possible to migrate configs by redirecting XStreams. Legacy configurations can be handled by existing routines in PerforceSCM (e.g. "update to the version XXX before the migration")

Thanks for the link on backwards compatibility.

> I would have preferred a branch on the 'Perforce' name-space, but rather than delay the release any longer I am happy to go with an alternate name.
> I'd guess you would prefer org.jenkinsci.plugins.perforce.X (or even com.perforce.jenkinsci.plugins.perforce.X) instead of the legacy hudson.plugins.perforce.X

org.jenkinsci.plugins.perforce, jenkins.plugins.perforce or something like that. Is there a standard format for new plugins?

The other issue is the plugin name 'perforce-plugin'; I could use 'p4-plugin', so the namespace would be org.jenkinsci.plugins.p4 or similar?


Kind regards,
Paul

> 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-de...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[Stephen Connolly]

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 the vast bulk of the contribution *and* intending to maintain the plugin going foward)

HTH

[Paul Allen]

Sure; thanks for the clarification of the pattern.

Paul

[Paul Allen]

Hi Stephen,

Please can you create a new plugin entry for 'p4'.

github repo: jenkinsci/p4-plugin
artifactId: p4
package: com.perforce.jenkins.p4

My GitHub id is 'p4paul'.


I will need to do some refactoring to match the names above, but the code is currently here:

https://github.com/p4paul/p4-jenkins

Thanks,

Paul



On 30 Jun 2014, at 11:26, Stephen Connolly <stephen.al...@gmail.com> wrote:

[Stephen Connolly]

I'm having issues with my IRC client since I switched machines... somebody else might be able to help

[Paul Allen]

Ulli,

Any chance you could create this for me?

Paul

[Rob Petti]

I just tried to fork it, but jenkins-admin apparently died in the process.

[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 two plugins together.

Paul

[Rob Petti]

I was trying to fork p4paul/p4-jenkins to jenkinsci/p4-plugin, as requested. The bot seems to be having issues.

[Rob Petti]

Done. https://github.com/jenkinsci/p4-plugin

[Paul Allen]

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

[Paul Allen]

It seems the "p4-plugin" project is not showing up in the update centre?

I forgot to add the wiki page prior to release, however the POM did have the correct URL. I have since added the actual wiki page to match the POM, do I need to re-release even though there were no changes?

https://github.com/jenkinsci/p4-plugin/blob/master/pom.xml

I have checked both the updates centre json file and the latest build, both are are missing the "labels" and "wiki" entries.

http://updates.jenkins-ci.org/update-center.json
https://ci.jenkins-ci.org/job/infra_update_center/ws/www2/update-center.json

"p4":
{ "buildDate":"Jul 05, 2014",
"dependencies": [
{ "name":"credentials",
"optional":false,
"version":"1.9.4"
}],
"developers":[
{ "developerId":"p4paul",
"email":"pal...@perforce.com",
"name":"Paul Allen"
}],
"excerpt":"Perforce Client plugin for the Jenkins SCM provider.",
"gav":"org.jenkins-ci.plugins:p4:1.0",
"name":"p4","releaseTimestamp":"2014-07-05T21:51:28.00Z",
"requiredCore":"1.532.3",
"scm":"github.com",
"sha1":"xVOyF/L8O97+pys5fX/HAJZcUBo=",
"title":"Perforce plugin",
"url":"http://updates.jenkins-ci.org/download/plugins/p4/1.0/p4.hpi",
"version":"1.0"},

[Rob Petti]

Have you released it already? If so, it takes up to 6 hours to show up in the update center. If not, then that would be why.

[Oleg Nenashev]

I've got a notification from RSS about the release, hence the plugin should be available on Jenkins Artifactory

BTW, the plugin's Display Name is "Perforce Plugin", hence there can be various conflicts.

I'd recommend to change the display name

[Paul Allen]

Sure I can change it to a display name of "P4 Plugin".

I tried the release over the weekend, so it has been way longer than 6 hours. However, as I have only added the wiki page perhaps I will have to wait a further 6h or (11h 59m if I was unlucky).

> 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-de...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[Rob Petti]

Wiki pages aren't required for plugins to show up on the updatecenter.

[Rob Petti]

I just checked, and I can see it on the updatecenter, both in the jenkins UI and in the raw json.

[Paul Allen]

It was the name that Oleg pointed out. I was looking for p4, but it is called perforce. I'll spin a new release.

[Ali Raza]

Hi Paul,
I don't see any support for Shelving in the new P4 plugin? Is this coming any time soon? If so, can you discuss this feature?

Thanks

Ali