Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cbi-dev] Ideas for CBI git repositories

Aha, great. Thanks for clarification :-)




From: "Mikael Barbero" <mikael@xxxxxxxxxxx>
To: "Common-build Developers discussion" <cbi-dev@xxxxxxxxxxx>
Sent: Thursday, 11 June, 2015 11:37:21 AM
Subject: Re: [cbi-dev] Ideas for CBI git repositories

Thanks Mat for the tips. 

I think we misunderstood. I was not talking about creating an "aggregator" repository with submodule but just keep a single one and move the all the code to it. When I was talking about modules, I was talking about maven ones ;) 

Mikael

Le 11 juin 2015 à 12:13, Mat Booth <mat.booth@xxxxxxxxxx> a écrit :

----- Original Message -----
From: "Aleksandar Kurtakov" <akurtako@xxxxxxxxxx>
To: "Common-build Developers discussion" <cbi-dev@xxxxxxxxxxx>
Sent: Thursday, 11 June, 2015 10:15:10 AM
Subject: Re: [cbi-dev] Ideas for CBI git repositories


----- Original Message -----
From: "Mikael Barbero" <mikael@xxxxxxxxxxx>
To: "Common-build Developers discussion" <cbi-dev@xxxxxxxxxxx>
Sent: Thursday, 11 June, 2015 11:48:59 AM
Subject: [cbi-dev] Ideas for CBI git repositories

Dear CBI committers,

After the refactoring of the maven plugins and the implementation of
signing
services as embedded Jetty servers I made, I end up with some dependencies
between the webservices to the "common" module of the
eclispe.cbi.maven.plugins repo. As such, I would like to create a "common"
git repo that will host a shared parent pom for signing services and maven
plugins and also host the "common" module. This way, we will be able to
easily publish new version of the common utilities.

Then, for consistencies concerns, I would like to rename the
"signing-service.git" repo to "org.eclipse.cbi.webservices.git" as it now
hosts DMG packaging service and as such more general that just "signing".

Another solution would be to merge the two repos to a "org.eclipse.cbi.git"
with two submodules: "maven-plugins" and "webservices". This solution would
even more simplify management of dependencies and deployment.

One repo sounds slightly better to me as I having a git repo for every 10
classes is a bit too much of an overhead for my taste.

Alexander Kurtakov
Red Hat Eclipse team


FWIW, due to limitations with cgit repositories with submodules are harder to consume from a downstream linux distro integration point of view -- i.e. we can't simply point to the url of a tarball, it forces us to generate tarballs ourselves by writing scripts to clone and populate the submodules. 

Mat


Denis, Alexander, as project leads, would you agree with that? Other
committers, any opinion?

Thanks
Mikael

PS: of course, I won't change the coordinates of the maven plugins so these
changes won't break anyone but the committers who would need to clone new
repos.
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cbi-dev

_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cbi-dev

_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cbi-dev


_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cbi-dev


Back to the top