You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2019/06/17 16:56:10 UTC

Tomcat-Native - Time to move to git?

Hi,

I'm starting to look at OCSP stapling for our OpenSSL based connectors
and I suspect a Tomcat Native release will be required. Even if it isn't
for this, it has been a while since the last Tomcat Native release so I
expect we'll need to do one fairly soon anyway.

The complication is the svn:external that picks up the
org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
this no longer works.

I looked at a workaround using the "GitHub makes itself look like svn"
but that timed out for the Tomcat repo. I suspect due to size.

I then looked at Git based solutions. sub-modules and sub-trees look to
be the two options. Of the two, sub-trees looks better:
- it is more suited to "read-only" importing
- it doesn't require any additional commands to populate the imported
  code

However, using sub-trees means moving Tomcat-Native to git. Before I
start a formal vote to do so, are there any objections?

The process would be:
- ensure git mirror is up to date
- break the svn->git mirror
- start using git
- update web site etc
- move svn code to archive

Given how the migration of the main repos went, I'm not expecting any
major issues.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Tomcat-Native - Time to move to git?

Posted by Mark Thomas <ma...@apache.org>.
On 18/06/2019 01:03, Igal Sapir wrote:
> On 6/17/2019 2:18 PM, Rainer Jung wrote:
>> Am 17.06.2019 um 18:56 schrieb Mark Thomas:
>>> Hi,
>>>
>>> I'm starting to look at OCSP stapling for our OpenSSL based connectors
>>> and I suspect a Tomcat Native release will be required. Even if it isn't
>>> for this, it has been a while since the last Tomcat Native release so I
>>> expect we'll need to do one fairly soon anyway.
>>>
>>> The complication is the svn:external that picks up the
>>> org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
>>> this no longer works.
>>>
>>> I looked at a workaround using the "GitHub makes itself look like svn"
>>> but that timed out for the Tomcat repo. I suspect due to size.
>>>
>>> I then looked at Git based solutions. sub-modules and sub-trees look to
>>> be the two options. Of the two, sub-trees looks better:
>>> - it is more suited to "read-only" importing
>>> - it doesn't require any additional commands to populate the imported
>>>    code
>>>
>>> However, using sub-trees means moving Tomcat-Native to git. Before I
>>> start a formal vote to do so, are there any objections?
>>>
>>> The process would be:
>>> - ensure git mirror is up to date
>>> - break the svn->git mirror
>>> - start using git
>>> - update web site etc
>>> - move svn code to archive
>>>
>>> Given how the migration of the main repos went, I'm not expecting any
>>> major issues.
>>
>> +1
> 
> +1

Given there seems to be consensus on doing this, I'm not going to hold a
formal vote. I'll just go ahead and get it done.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Tomcat-Native - Time to move to git?

Posted by Igal Sapir <is...@apache.org>.
On 6/17/2019 2:18 PM, Rainer Jung wrote:
> Am 17.06.2019 um 18:56 schrieb Mark Thomas:
>> Hi,
>>
>> I'm starting to look at OCSP stapling for our OpenSSL based connectors
>> and I suspect a Tomcat Native release will be required. Even if it isn't
>> for this, it has been a while since the last Tomcat Native release so I
>> expect we'll need to do one fairly soon anyway.
>>
>> The complication is the svn:external that picks up the
>> org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
>> this no longer works.
>>
>> I looked at a workaround using the "GitHub makes itself look like svn"
>> but that timed out for the Tomcat repo. I suspect due to size.
>>
>> I then looked at Git based solutions. sub-modules and sub-trees look to
>> be the two options. Of the two, sub-trees looks better:
>> - it is more suited to "read-only" importing
>> - it doesn't require any additional commands to populate the imported
>>    code
>>
>> However, using sub-trees means moving Tomcat-Native to git. Before I
>> start a formal vote to do so, are there any objections?
>>
>> The process would be:
>> - ensure git mirror is up to date
>> - break the svn->git mirror
>> - start using git
>> - update web site etc
>> - move svn code to archive
>>
>> Given how the migration of the main repos went, I'm not expecting any
>> major issues.
>
> +1

+1

Igal



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Tomcat-Native - Time to move to git?

Posted by Rainer Jung <ra...@kippdata.de>.
Am 17.06.2019 um 18:56 schrieb Mark Thomas:
> Hi,
> 
> I'm starting to look at OCSP stapling for our OpenSSL based connectors
> and I suspect a Tomcat Native release will be required. Even if it isn't
> for this, it has been a while since the last Tomcat Native release so I
> expect we'll need to do one fairly soon anyway.
> 
> The complication is the svn:external that picks up the
> org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
> this no longer works.
> 
> I looked at a workaround using the "GitHub makes itself look like svn"
> but that timed out for the Tomcat repo. I suspect due to size.
> 
> I then looked at Git based solutions. sub-modules and sub-trees look to
> be the two options. Of the two, sub-trees looks better:
> - it is more suited to "read-only" importing
> - it doesn't require any additional commands to populate the imported
>    code
> 
> However, using sub-trees means moving Tomcat-Native to git. Before I
> start a formal vote to do so, are there any objections?
> 
> The process would be:
> - ensure git mirror is up to date
> - break the svn->git mirror
> - start using git
> - update web site etc
> - move svn code to archive
> 
> Given how the migration of the main repos went, I'm not expecting any
> major issues.

+1

Rainer


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Tomcat-Native - Time to move to git?

Posted by Mark Thomas <ma...@apache.org>.
On 18/06/2019 12:42, Emmanuel Bourg wrote:
> Le 17/06/2019 à 18:56, Mark Thomas a écrit :
> 
>> The complication is the svn:external that picks up the
>> org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
>> this no longer works.
> 
> Has it been considered to move the org.apache.tomcat.jni package from
> tomcat to tomcat-native? Since these Java classes are the counterpart of
> the native code, always evolving in sync, it would be sensible to have
> them in the same project.

That hasn't been considered for a while but that doesn't stop it being
considered now. I don't recall off-hand why this was set up the way it
was. Time for some svn archaeology.

>> I looked at a workaround using the "GitHub makes itself look like svn"
>> but that timed out for the Tomcat repo. I suspect due to size.
>>
>> I then looked at Git based solutions. sub-modules and sub-trees look to
>> be the two options. Of the two, sub-trees looks better:
>> - it is more suited to "read-only" importing
>> - it doesn't require any additional commands to populate the imported
>>   code
> 
> What is the workflow to use git subtrees? I googled quickly yesterday
> and it didn't seem that simple, but maybe I'm missing something. My
> understanding is that the subtree has to be explicitly configured with
> non trivial commands after a 'git clone'.

The initial setup is done once (I'll do it). After that, it appears to
be part of the repo to anyone cloning the repo. There would be a process
to update the subtree. Again, that should be transparent to everyone
apart from the person doing the update.

Making the change above would remove the need for the subtree.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Tomcat-Native - Time to move to git?

Posted by Emmanuel Bourg <eb...@apache.org>.
Le 17/06/2019 à 18:56, Mark Thomas a écrit :

> The complication is the svn:external that picks up the
> org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
> this no longer works.

Has it been considered to move the org.apache.tomcat.jni package from
tomcat to tomcat-native? Since these Java classes are the counterpart of
the native code, always evolving in sync, it would be sensible to have
them in the same project.


> I looked at a workaround using the "GitHub makes itself look like svn"
> but that timed out for the Tomcat repo. I suspect due to size.
> 
> I then looked at Git based solutions. sub-modules and sub-trees look to
> be the two options. Of the two, sub-trees looks better:
> - it is more suited to "read-only" importing
> - it doesn't require any additional commands to populate the imported
>   code

What is the workflow to use git subtrees? I googled quickly yesterday
and it didn't seem that simple, but maybe I'm missing something. My
understanding is that the subtree has to be explicitly configured with
non trivial commands after a 'git clone'.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Tomcat-Native - Time to move to git?

Posted by Coty Sutherland <cs...@apache.org>.
On Mon, Jun 17, 2019 at 12:56 PM Mark Thomas <ma...@apache.org> wrote:

> Hi,
>
> I'm starting to look at OCSP stapling for our OpenSSL based connectors
> and I suspect a Tomcat Native release will be required. Even if it isn't
> for this, it has been a while since the last Tomcat Native release so I
> expect we'll need to do one fairly soon anyway.
>
> The complication is the svn:external that picks up the
> org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
> this no longer works.
>
> I looked at a workaround using the "GitHub makes itself look like svn"
> but that timed out for the Tomcat repo. I suspect due to size.
>
> I then looked at Git based solutions. sub-modules and sub-trees look to
> be the two options. Of the two, sub-trees looks better:
> - it is more suited to "read-only" importing
> - it doesn't require any additional commands to populate the imported
>   code
>
> However, using sub-trees means moving Tomcat-Native to git. Before I
> start a formal vote to do so, are there any objections?
>
> The process would be:
> - ensure git mirror is up to date
> - break the svn->git mirror
> - start using git
> - update web site etc
> - move svn code to archive
>
> Given how the migration of the main repos went, I'm not expecting any
> major issues.
>

No objections from me :)


>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Re: Tomcat-Native - Time to move to git?

Posted by Rémy Maucherat <re...@apache.org>.
On Mon, Jun 17, 2019 at 6:56 PM Mark Thomas <ma...@apache.org> wrote:

> Hi,
>
> I'm starting to look at OCSP stapling for our OpenSSL based connectors
> and I suspect a Tomcat Native release will be required. Even if it isn't
> for this, it has been a while since the last Tomcat Native release so I
> expect we'll need to do one fairly soon anyway.
>
> The complication is the svn:external that picks up the
> org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git,
> this no longer works.
>
> I looked at a workaround using the "GitHub makes itself look like svn"
> but that timed out for the Tomcat repo. I suspect due to size.
>
> I then looked at Git based solutions. sub-modules and sub-trees look to
> be the two options. Of the two, sub-trees looks better:
> - it is more suited to "read-only" importing
> - it doesn't require any additional commands to populate the imported
>   code
>
> However, using sub-trees means moving Tomcat-Native to git. Before I
> start a formal vote to do so, are there any objections?
>
> The process would be:
> - ensure git mirror is up to date
> - break the svn->git mirror
> - start using git
> - update web site etc
> - move svn code to archive
>
> Given how the migration of the main repos went, I'm not expecting any
> major issues.
>

+1

Rémy