You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Oliver Lietz <ap...@oliverlietz.de> on 2016/02/22 10:49:58 UTC
jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
On Monday 22 February 2016 05:54:51 cziegeler@apache.org wrote:
> Author: cziegeler
> Date: Mon Feb 22 05:54:51 2016
> New Revision: 1731592
>
> URL: http://svn.apache.org/viewvc?rev=1731592&view=rev
> Log:
> Use latst jcr.base snapshot
>
> Modified:
> sling/trunk/bundles/jcr/jackrabbit-server/pom.xml
>
> Modified: sling/trunk/bundles/jcr/jackrabbit-server/pom.xml
> URL:
> http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/jackrabbit-server/pom.
> xml?rev=1731592&r1=1731591&r2=1731592&view=diff
> ===========================================================================
> === --- sling/trunk/bundles/jcr/jackrabbit-server/pom.xml (original)
> +++ sling/trunk/bundles/jcr/jackrabbit-server/pom.xml Mon Feb 22 05:54:51
> 2016 @@ -167,7 +167,7 @@
> <dependency>
> <groupId>org.apache.sling</groupId>
> <artifactId>org.apache.sling.jcr.base</artifactId>
> - <version>2.3.1-SNAPSHOT</version>
> + <version>2.3.3-SNAPSHOT</version>
> <scope>provided</scope>
> </dependency>
Hi Carsten,
as we do no longer support Jackrabbit shouldn't we move jackrabbit-server to
attic or contrib or simply remove it from SVN?
If we do we can straighten it-jackrabbit-oak which fails right now with latest
releases (AFAIR due to eventing/observation).
Regards,
O.
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Wednesday 24 February 2016 10:15:32 Carsten Ziegeler wrote:
> Oliver Lietz wrote
>
> >> We can move it to contrib for the time being
> >
> > Well, there was a discussion at dev@felix some months ago about moving to
> > Git successively and using one Git repo per module. I'm not sure what's
> > the current state there (@Benson: can you tell us?), but in my opinion
> > jackrabbit- server would be a perfect candidate to find out if it would
> > work for us without breaking anything.
> >
> > If you agree I would file an issue at infra and start moving
> > jackrabbit-server to Git.
>
> Sorry, but I don't understand the logic behind this. Why should we move
> a module which don't care about anymore to git? Shouldn't we rather have
> the modules we work on on git - if at all?
If we don't care we can remove it from SVN entirely.
If we do care (if we want our users to still work with it) we can move it to
contrib or attic. Or we can move it to Git (lock it in SVN) and use it as
guinea pig.
O.
btw, moving a module between bundles, contrib, attic or whatever will be just
adding/removing it to a different builder/reactor and/or (Google) repo in Git
- no move in SCM.
> Carsten
Re: jackrabbit-server [Re: svn commit: r1731592 -
/sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Robert Munteanu <ro...@apache.org>.
On Thu, 2016-02-25 at 20:39 +0100, Oliver Lietz wrote:
> > Yes, there are a couple of more things, and I have a script lying
> > around somewhere from the last big git migration that I went
> through.
>
> Robert, can you share your script?
>
> https://issues.apache.org/jira/browse/SLING-3987
>
> Thanks,
> O.
I will do that (hopefully by next week) but I need to clean up the
scripts first to remove some bits which are not needed here.
Robert
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Wednesday 24 February 2016 22:20:10 Robert Munteanu wrote:
> On Wed, 2016-02-24 at 14:43 +0100, Oliver Lietz wrote:
> > On Wednesday 24 February 2016 14:59:46 Robert Munteanu wrote:
> > > On Wed, 2016-02-24 at 10:54 +0100, Oliver Lietz wrote:
> > > > On Wednesday 24 February 2016 10:26:24 Bertrand Delacretaz wrote:
> > > > > On Wed, Feb 24, 2016 at 10:02 AM, Oliver Lietz <apache@oliverli
> > > > > etz.
> > > > > de>
> > > >
> > > > wrote:
> > > > > > ...We do have roughly 250 modules (and counting) in SVN and I
> > > > > > don't think
> > > > > > we can switch at once...
> > > > >
> > > > > We can, if we use a computer ;-)
> > > > >
> > > > > If we decide to move to Git we might first reorganize modules
> > > > > and
> > > > > poms
> > > > > as needed, and create scripts to move things so we can do dry
> > > > > runs.
> > > > > Then, when the scripts are tested, switch everything at once.
> > > >
> > > > It takes "ages" even with computers and they only have one big
> > > > repo:
> > > > https://www.linux.com/news/featured-blogs/196-zonker/787127-apach
> > > > e-ha
> > > > doop-transitions-to-git
> > > >
> > > > Should we ask infra for support? Do we need a vote?
> > >
> > > _If_ we decide to move to Git ( including how and when ) we can
> > > perform
> > > some dry-runs which create git repos out of Maven modules and push
> > > them
> > > to a unofficial account on github.
> > >
> > > I suggest we involve infra only when we know exactly what we want
> > > to
> > > do.
> >
> > I think infra can help in finding out what we want to do and how.
> >
> > > As for an the duration of the conversion, here's what I did for the
> > > jackrabbit-server bundle:
> > >
> > > $ git clone https://github.com/apache/sling.git sling-import
> > > $ cd sling-import
> > > $ git filter-branch --subdirectory-filter bundles/jcr/jackrabbit-
> > > server
> > > Rewrite eb7e75b8f92ce96f1a4f804676b90fc08a377834 (115/143) (1
> > > seconds
> > > passed, remaining 0 predicted)
> > > Ref 'refs/heads/trunk' was rewritten
> > >
> > > Clock time was about 3 seconds for the git filter-branch call.
> >
> > That is for sure not all we have to do. The resulting repo contains
> > 1018 tags
> > where it should only contain the ones for jackrabbit-server itself.
>
> Yes, there are a couple of more things, and I have a script lying
> around somewhere from the last big git migration that I went through.
Robert, can you share your script?
https://issues.apache.org/jira/browse/SLING-3987
Thanks,
O.
> > > Do you have some references about migrating to git at Apache? The
> > > durations mentioned in the article seem like _a lot_.
> >
> > No, but we can ask infra. They have done several conversions to Git
> > and we
> > should really lean on them instead of trying to do the migration
> > ourselves.
>
> Well, asking never hurt :-) so feel free to do so.
>
> My argument was that going through with the migration ourselves would
> allow a lot more flexibility and faster iteration. Of course, the final
> process needs to be handled by infra ( e.g. making the SVN repo
> read/only, turning on the Git repos, etc ) but we should try to settle
> down on the details ourselves, rather than going to infra for
> everythings.
>
> Thanks,
>
> Robert
>
> > Regards,
> > O.
> >
> > > Thanks,
> > >
> > > Robert
> > >
> > > > O.
> > > >
> > > > > -Bertrand
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Chetan Mehrotra <ch...@gmail.com>.
May be its just me - But I find current setup of Sling and git svn on
client just fine for my usage and working in this project. So do not
see a compelling reason for switch with all the changes involved.
Intention is not to discourage other from trying - Just want to
mention my thoughts :)
Chetan Mehrotra
On Fri, Feb 26, 2016 at 2:07 PM, Oliver Lietz <ap...@oliverlietz.de> wrote:
> On Friday 26 February 2016 08:59:02 Carsten Ziegeler wrote:
>> Oliver Lietz wrote
>>
>> > https://issues.apache.org/jira/browse/SLING-3987
>> >
>> > I think we already have consensus on having one repo per module if we use
>> > Git.
>> Ah great :)
>>
>> How would we do the Jenkins setup? One Jenkins job per module? Which I
>> think would be way better than what we have today: currently some
>> modules fail randomly and prevent building the whole project. Hunting
>> these things should be easier.
>
> big +1
>
> Regards,
> O.
>
>> Regards
>> Carsten
>
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Friday 26 February 2016 08:59:02 Carsten Ziegeler wrote:
> Oliver Lietz wrote
>
> > https://issues.apache.org/jira/browse/SLING-3987
> >
> > I think we already have consensus on having one repo per module if we use
> > Git.
> Ah great :)
>
> How would we do the Jenkins setup? One Jenkins job per module? Which I
> think would be way better than what we have today: currently some
> modules fail randomly and prevent building the whole project. Hunting
> these things should be easier.
big +1
Regards,
O.
> Regards
> Carsten
Re: jackrabbit-server [Re: svn commit: r1731592 -
/sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Carsten Ziegeler <cz...@apache.org>.
Oliver Lietz wrote
>
> https://issues.apache.org/jira/browse/SLING-3987
>
> I think we already have consensus on having one repo per module if we use Git.
>
Ah great :)
How would we do the Jenkins setup? One Jenkins job per module? Which I
think would be way better than what we have today: currently some
modules fail randomly and prevent building the whole project. Hunting
these things should be easier.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Wednesday 24 February 2016 22:22:01 Carsten Ziegeler wrote:
> We had a very long back and forth discussion on the Felix mailing list
> about moving to git - main point being whether to go for a single git
> repo or one git repo per module or a faulty compromise in between.
> Which then let to the interesting discussion about what the real problem
> a move to git solves and if there are any real advantages.
>
> Now, I'm not saying we shouldn't do it, but before doing anything in
> that direction, we should be clear that we all agree on what the end
> result would be: a git repo per module. If we don't agree on that, we'll
> end up in the same situation as the Felix project and do not migrate
> anything (which isn't that bad imho)
https://issues.apache.org/jira/browse/SLING-3987
I think we already have consensus on having one repo per module if we use Git.
Regards,
O.
> Regards
> Carsten
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Feb 24, 2016 at 10:22 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...but before doing anything in
> that direction, we should be clear that we all agree on what the end
> result would be: a git repo per module....
Agreed.
-Bertrand
Re: jackrabbit-server [Re: svn commit: r1731592 -
/sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Carsten Ziegeler <cz...@apache.org>.
We had a very long back and forth discussion on the Felix mailing list
about moving to git - main point being whether to go for a single git
repo or one git repo per module or a faulty compromise in between.
Which then let to the interesting discussion about what the real problem
a move to git solves and if there are any real advantages.
Now, I'm not saying we shouldn't do it, but before doing anything in
that direction, we should be clear that we all agree on what the end
result would be: a git repo per module. If we don't agree on that, we'll
end up in the same situation as the Felix project and do not migrate
anything (which isn't that bad imho)
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: jackrabbit-server [Re: svn commit: r1731592 -
/sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2016-02-24 at 14:43 +0100, Oliver Lietz wrote:
> On Wednesday 24 February 2016 14:59:46 Robert Munteanu wrote:
> >
> > On Wed, 2016-02-24 at 10:54 +0100, Oliver Lietz wrote:
> > >
> > > On Wednesday 24 February 2016 10:26:24 Bertrand Delacretaz wrote:
> > > >
> > > > On Wed, Feb 24, 2016 at 10:02 AM, Oliver Lietz <apache@oliverli
> > > > etz.
> > > > de>
> > > wrote:
> > > >
> > > > >
> > > > > ...We do have roughly 250 modules (and counting) in SVN and I
> > > > > don't think
> > > > > we can switch at once...
> > > > We can, if we use a computer ;-)
> > > >
> > > > If we decide to move to Git we might first reorganize modules
> > > > and
> > > > poms
> > > > as needed, and create scripts to move things so we can do dry
> > > > runs.
> > > > Then, when the scripts are tested, switch everything at once.
> > > It takes "ages" even with computers and they only have one big
> > > repo:
> > > https://www.linux.com/news/featured-blogs/196-zonker/787127-apach
> > > e-ha
> > > doop-transitions-to-git
> > >
> > > Should we ask infra for support? Do we need a vote?
> > _If_ we decide to move to Git ( including how and when ) we can
> > perform
> > some dry-runs which create git repos out of Maven modules and push
> > them
> > to a unofficial account on github.
> >
> > I suggest we involve infra only when we know exactly what we want
> > to
> > do.
> I think infra can help in finding out what we want to do and how.
>
> >
> > As for an the duration of the conversion, here's what I did for the
> > jackrabbit-server bundle:
> >
> > $ git clone https://github.com/apache/sling.git sling-import
> > $ cd sling-import
> > $ git filter-branch --subdirectory-filter bundles/jcr/jackrabbit-
> > server
> > Rewrite eb7e75b8f92ce96f1a4f804676b90fc08a377834 (115/143) (1
> > seconds
> > passed, remaining 0 predicted)
> > Ref 'refs/heads/trunk' was rewritten
> >
> > Clock time was about 3 seconds for the git filter-branch call.
> That is for sure not all we have to do. The resulting repo contains
> 1018 tags
> where it should only contain the ones for jackrabbit-server itself.
Yes, there are a couple of more things, and I have a script lying
around somewhere from the last big git migration that I went through.
>
> >
> > Do you have some references about migrating to git at Apache? The
> > durations mentioned in the article seem like _a lot_.
> No, but we can ask infra. They have done several conversions to Git
> and we
> should really lean on them instead of trying to do the migration
> ourselves.
Well, asking never hurt :-) so feel free to do so.
My argument was that going through with the migration ourselves would
allow a lot more flexibility and faster iteration. Of course, the final
process needs to be handled by infra ( e.g. making the SVN repo
read/only, turning on the Git repos, etc ) but we should try to settle
down on the details ourselves, rather than going to infra for
everythings.
Thanks,
Robert
>
> Regards,
> O.
>
> >
> > Thanks,
> >
> > Robert
> >
> > >
> > > O.
> > >
> > > >
> > > > -Bertrand
>
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Wednesday 24 February 2016 14:59:46 Robert Munteanu wrote:
> On Wed, 2016-02-24 at 10:54 +0100, Oliver Lietz wrote:
> > On Wednesday 24 February 2016 10:26:24 Bertrand Delacretaz wrote:
> > > On Wed, Feb 24, 2016 at 10:02 AM, Oliver Lietz <apache@oliverlietz.
> > > de>
> >
> > wrote:
> > > > ...We do have roughly 250 modules (and counting) in SVN and I
> > > > don't think
> > > > we can switch at once...
> > >
> > > We can, if we use a computer ;-)
> > >
> > > If we decide to move to Git we might first reorganize modules and
> > > poms
> > > as needed, and create scripts to move things so we can do dry runs.
> > > Then, when the scripts are tested, switch everything at once.
> >
> > It takes "ages" even with computers and they only have one big repo:
> > https://www.linux.com/news/featured-blogs/196-zonker/787127-apache-ha
> > doop-transitions-to-git
> >
> > Should we ask infra for support? Do we need a vote?
>
> _If_ we decide to move to Git ( including how and when ) we can perform
> some dry-runs which create git repos out of Maven modules and push them
> to a unofficial account on github.
>
> I suggest we involve infra only when we know exactly what we want to
> do.
I think infra can help in finding out what we want to do and how.
> As for an the duration of the conversion, here's what I did for the
> jackrabbit-server bundle:
>
> $ git clone https://github.com/apache/sling.git sling-import
> $ cd sling-import
> $ git filter-branch --subdirectory-filter bundles/jcr/jackrabbit-server
> Rewrite eb7e75b8f92ce96f1a4f804676b90fc08a377834 (115/143) (1 seconds
> passed, remaining 0 predicted)
> Ref 'refs/heads/trunk' was rewritten
>
> Clock time was about 3 seconds for the git filter-branch call.
That is for sure not all we have to do. The resulting repo contains 1018 tags
where it should only contain the ones for jackrabbit-server itself.
> Do you have some references about migrating to git at Apache? The
> durations mentioned in the article seem like _a lot_.
No, but we can ask infra. They have done several conversions to Git and we
should really lean on them instead of trying to do the migration ourselves.
Regards,
O.
> Thanks,
>
> Robert
>
> > O.
> >
> > > -Bertrand
Re: jackrabbit-server [Re: svn commit: r1731592 -
/sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2016-02-24 at 10:54 +0100, Oliver Lietz wrote:
> On Wednesday 24 February 2016 10:26:24 Bertrand Delacretaz wrote:
> >
> > On Wed, Feb 24, 2016 at 10:02 AM, Oliver Lietz <apache@oliverlietz.
> > de>
> wrote:
> >
> > >
> > > ...We do have roughly 250 modules (and counting) in SVN and I
> > > don't think
> > > we can switch at once...
> > We can, if we use a computer ;-)
> >
> > If we decide to move to Git we might first reorganize modules and
> > poms
> > as needed, and create scripts to move things so we can do dry runs.
> > Then, when the scripts are tested, switch everything at once.
> It takes "ages" even with computers and they only have one big repo:
> https://www.linux.com/news/featured-blogs/196-zonker/787127-apache-ha
> doop-transitions-to-git
>
> Should we ask infra for support? Do we need a vote?
_If_ we decide to move to Git ( including how and when ) we can perform
some dry-runs which create git repos out of Maven modules and push them
to a unofficial account on github.
I suggest we involve infra only when we know exactly what we want to
do.
As for an the duration of the conversion, here's what I did for the
jackrabbit-server bundle:
$ git clone https://github.com/apache/sling.git sling-import
$ cd sling-import
$ git filter-branch --subdirectory-filter bundles/jcr/jackrabbit-server
Rewrite eb7e75b8f92ce96f1a4f804676b90fc08a377834 (115/143) (1 seconds
passed, remaining 0 predicted)
Ref 'refs/heads/trunk' was rewritten
Clock time was about 3 seconds for the git filter-branch call.
Do you have some references about migrating to git at Apache? The
durations mentioned in the article seem like _a lot_.
Thanks,
Robert
>
> O.
>
> >
> > -Bertrand
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Wednesday 24 February 2016 10:26:24 Bertrand Delacretaz wrote:
> On Wed, Feb 24, 2016 at 10:02 AM, Oliver Lietz <ap...@oliverlietz.de>
wrote:
> > ...We do have roughly 250 modules (and counting) in SVN and I don't think
> > we can switch at once...
>
> We can, if we use a computer ;-)
>
> If we decide to move to Git we might first reorganize modules and poms
> as needed, and create scripts to move things so we can do dry runs.
> Then, when the scripts are tested, switch everything at once.
It takes "ages" even with computers and they only have one big repo:
https://www.linux.com/news/featured-blogs/196-zonker/787127-apache-hadoop-transitions-to-git
Should we ask infra for support? Do we need a vote?
O.
> -Bertrand
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Feb 24, 2016 at 10:02 AM, Oliver Lietz <ap...@oliverlietz.de> wrote:
> ...We do have roughly 250 modules (and counting) in SVN and I don't think we can
> switch at once...
We can, if we use a computer ;-)
If we decide to move to Git we might first reorganize modules and poms
as needed, and create scripts to move things so we can do dry runs.
Then, when the scripts are tested, switch everything at once.
-Bertrand
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Wednesday 24 February 2016 09:51:09 Bertrand Delacretaz wrote:
> Hi,
>
> On Wed, Feb 24, 2016 at 9:35 AM, Oliver Lietz <ap...@oliverlietz.de> wrote:
> > ...If you agree I would file an issue at infra and start moving
> > jackrabbit-server to Git...
>
> So we'd have some modules on Git and the rest in svn?
>
> I don't think it's a good idea.
>
> Moving to Git why not but we need to agree on a plan for that first -
> but having a mix is not good IMO.
We do have roughly 250 modules (and counting) in SVN and I don't think we can
switch at once. Starting with some uncritical modules and learn from them
seems to be a feasible way.
O.
> -Bertrand
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Feb 24, 2016 at 9:35 AM, Oliver Lietz <ap...@oliverlietz.de> wrote:
> ...If you agree I would file an issue at infra and start moving jackrabbit-server
> to Git...
So we'd have some modules on Git and the rest in svn?
I don't think it's a good idea.
Moving to Git why not but we need to agree on a plan for that first -
but having a mix is not good IMO.
-Bertrand
Re: jackrabbit-server [Re: svn commit: r1731592 -
/sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Carsten Ziegeler <cz...@apache.org>.
Oliver Lietz wrote
>>
>> We can move it to contrib for the time being
>
> Well, there was a discussion at dev@felix some months ago about moving to Git
> successively and using one Git repo per module. I'm not sure what's the
> current state there (@Benson: can you tell us?), but in my opinion jackrabbit-
> server would be a perfect candidate to find out if it would work for us
> without breaking anything.
>
> If you agree I would file an issue at infra and start moving jackrabbit-server
> to Git.
Sorry, but I don't understand the logic behind this. Why should we move
a module which don't care about anymore to git? Shouldn't we rather have
the modules we work on on git - if at all?
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Monday 22 February 2016 18:39:23 Carsten Ziegeler wrote:
> Bertrand Delacretaz wrote
>
> > On Mon, Feb 22, 2016 at 10:59 AM, Carsten Ziegeler <cz...@apache.org>
wrote:
> >> Oliver Lietz wrote
> >>
> >>> as we do no longer support Jackrabbit shouldn't we move
> >>> jackrabbit-server to attic or contrib or simply remove it from SVN?
> >>
> >> Very good point, +1 - let's remove it. ...
> >
> > I would prefer that we keep such modules around, suggest a /attic folder.
> >
> > If someone is using such a module that we don't support anymore and
> > needs to fix something in it, it's much easier if it's still in our
> > source code tree. Not included in the main pom.xml, so we don't even
> > care if it builds or not, but still there.
>
> We can move it to contrib for the time being
Well, there was a discussion at dev@felix some months ago about moving to Git
successively and using one Git repo per module. I'm not sure what's the
current state there (@Benson: can you tell us?), but in my opinion jackrabbit-
server would be a perfect candidate to find out if it would work for us
without breaking anything.
If you agree I would file an issue at infra and start moving jackrabbit-server
to Git.
Regards,
O.
> Regards
> Carsten
Re: jackrabbit-server [Re: svn commit: r1731592 -
/sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote
> On Mon, Feb 22, 2016 at 10:59 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Oliver Lietz wrote
>>> as we do no longer support Jackrabbit shouldn't we move jackrabbit-server to
>>> attic or contrib or simply remove it from SVN?
>>
>> Very good point, +1 - let's remove it. ...
>
> I would prefer that we keep such modules around, suggest a /attic folder.
>
> If someone is using such a module that we don't support anymore and
> needs to fix something in it, it's much easier if it's still in our
> source code tree. Not included in the main pom.xml, so we don't even
> care if it builds or not, but still there.
>
We can move it to contrib for the time being
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: jackrabbit-server [Re: svn commit: r1731592 - /sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Feb 22, 2016 at 10:59 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Oliver Lietz wrote
>> as we do no longer support Jackrabbit shouldn't we move jackrabbit-server to
>> attic or contrib or simply remove it from SVN?
>
> Very good point, +1 - let's remove it. ...
I would prefer that we keep such modules around, suggest a /attic folder.
If someone is using such a module that we don't support anymore and
needs to fix something in it, it's much easier if it's still in our
source code tree. Not included in the main pom.xml, so we don't even
care if it builds or not, but still there.
-Bertrand
Re: jackrabbit-server [Re: svn commit: r1731592 -
/sling/trunk/bundles/jcr/jackrabbit-server/pom.xml]
Posted by Carsten Ziegeler <cz...@apache.org>.
Oliver Lietz wrote
>
> as we do no longer support Jackrabbit shouldn't we move jackrabbit-server to
> attic or contrib or simply remove it from SVN?
Very good point, +1 - let's remove it.
Carsten
>
> If we do we can straighten it-jackrabbit-oak which fails right now with latest
> releases (AFAIR due to eventing/observation).
>
> Regards,
> O.
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org