Home » Eclipse Projects » Oomph » Cloning git , importing and connecting to egit
|
| Re: Cloning git , importing and connecting to egit [message #1430991 is a reply to message #1430714] |
Thu, 25 September 2014 04:35   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Andreas,
Comments below.
On 24/09/2014 8:07 PM, Andreas Graf wrote:
> Dear all,
>
> we have a setup where we clone a git and import the projects with the
> projects import task. However, egit does not recognize them as being
> part of a git.
Normally this is done automatically because
"Windows->Preferences->Team->Git->Projects->Automatically share projects
located in a git repository" is enabled by default, and we make sure in
the Git clone task to activate the EGit UI bundle to ensure the behavior
will kick in.
>
> What would be the best way to fix it.
We did have issues in the past with this not working, which is why we
active the EGit UI bundle. Then one time I encountered a case that
still wasn't working and debugged EGit itself to see what was going on,
only to discover that somewhere in the folder hierarchy above the folder
of the git clone itself, there was another folder with a .git folder in
it and that this confused EGit into thinking that should be the clone
and because that wasn't a valid/well-formed clone, it did nothing. So I
deleted that bogus .git folder and then it worked properly.
Here's what I suggest you try. Import one of the projects manually
from the automatic git clone. But don't use the git UI, just do import
existing projects using Eclipse itself, finding the physical project in
the clone. EGit should see that workspace even and auto share the
project. If that doesn't work, my guess would be you've run into this
nested clone problem I described above.
> Would using a targlet help here?
No, nothing in Oomph automatically team shares the projects. That
should just happen if something/anything causes the project to be in the
workspace.
> And would it be mandatory to have features to import projects into the
> workspace by a target?
No. The targlet will follow dependencies of bundles or features so you
only have to list as many things as there are separate dependency
roots. Not only that, you can create a Component Extension in any
bundle/feature to specify additional development time requirements and
even Component Definitions to turn any project into an installable unit
(and it too can specify requirements). So in the end, you can
accomplish the same thing as having features with Component Extensions
and Component Definitions.
> It would be a little tedious, since we have a lot of Eclipse projects
> in that git.
It's hard to imagine a good reason for not using a targlet task. 99% of
the time you need a target platform and *.target files are a bit of a
disaster area in terms of authoring and performance. And even if you
need a *.target for some other purpose (i.e., Oomph itself uses one for
its Tycho build), annotations on the targlets can be used to induce a
*.target file...
>
> Thanks for the help,
>
> Andreas
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Cloning git , importing and connecting to egit [message #1431820 is a reply to message #1430991] |
Fri, 26 September 2014 07:26 |
Andreas Graf
Messages: 211
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
thanks for the reply.
Ed Merks wrote on Thu, 25 September 2014 00:35Andreas,
Then one time I encountered a case that
still wasn't working and debugged EGit itself to see what was going on,
only to discover that somewhere in the folder hierarchy above the folder
of the git clone itself, there was another folder with a .git folder in
it and that this confused EGit into thinking that should be the clone
and because that wasn't a valid/well-formed clone, it did nothing. So I
deleted that bogus .git folder and then it worked properly.
I noticed the same in my directory structured when sharing manually. I removed the top-level .git and assume that everything will work now. Thanks for the info!
Quote:
> It would be a little tedious, since we have a lot of Eclipse projects
> in that git.
It's hard to imagine a good reason for not using a targlet task. 99% of
the time you need a target platform and *.target files are a bit of a
disaster area in terms of authoring and performance. And even if you
need a *.target for some other purpose (i.e., Oomph itself uses one for
its Tycho build), annotations on the targlets can be used to induce a
*.target file...
>
>
Currently, we avoid the .target concept and build a directory based target platform, since we also want to be able to reproduce the build if the update sites are gone.
Rgards,
Andreas
|
|
|
| Re: Cloning git , importing and connecting to egit [message #1431954 is a reply to message #1431820] |
Fri, 26 September 2014 11:43 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Andreas,
Oomph's targlets don't yet support folder-based "locators", but in
addition to source locators and p2 repositories, I could certainly
imagine a "binary IU locator" that could be pointed at a folder that
would be scanned for IUs. The underlying p2 publisher infrastructure
should have all the facilities for inducing IUs from their binary
representation. You could open up an enhancement request for that...
Note that mirroring is another potentially good solution for this type
of "stable TP" problem. I.e., you can always mirror a whole bunch of
repositories into a single unified repository and have both the builds
and the developers point at the appropriate mirror, which in a corporate
setting could be inside the firewall and very fast...
On 26/09/2014 9:26 AM, Andreas Graf wrote:
> Hi Ed,
>
> thanks for the reply.
>
> Ed Merks wrote on Thu, 25 September 2014 00:35
>> Andreas,
>>
>> Then one time I encountered a case that still wasn't working and
>> debugged EGit itself to see what was going on, only to discover that
>> somewhere in the folder hierarchy above the folder of the git clone
>> itself, there was another folder with a .git folder in it and that
>> this confused EGit into thinking that should be the clone and because
>> that wasn't a valid/well-formed clone, it did nothing. So I deleted
>> that bogus .git folder and then it worked properly.
>
> I noticed the same in my directory structured when sharing manually. I
> removed the top-level .git and assume that everything will work now.
> Thanks for the info!
> Quote:
>> > It would be a little tedious, since we have a lot of Eclipse
>> projects > in that git.
>> It's hard to imagine a good reason for not using a targlet task. 99%
>> of the time you need a target platform and *.target files are a bit
>> of a disaster area in terms of authoring and performance. And even
>> if you need a *.target for some other purpose (i.e., Oomph itself
>> uses one for its Tycho build), annotations on the targlets can be
>> used to induce a *.target file...
>> >
>> >
>
>
> Currently, we avoid the .target concept and build a directory based
> target platform, since we also want to be able to reproduce the build
> if the update sites are gone.
>
> Rgards,
>
> Andreas
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Cloning git , importing and connecting to egit [message #1432545 is a reply to message #1431954] |
Sat, 27 September 2014 09:15 |
Andreas Graf
Messages: 211
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Ed Merks wrote on Fri, 26 September 2014 07:43Andreas,
Oomph's targlets don't yet support folder-based "locators", but in
addition to source locators and p2 repositories, I could certainly
imagine a "binary IU locator" that could be pointed at a folder that
would be scanned for IUs. The underlying p2 publisher infrastructure
should have all the facilities for inducing IUs from their binary
representation. You could open up an enhancement request for that...
Will do that next week!
Quote:
Note that mirroring is another potentially good solution for this type
of "stable TP" problem. I.e., you can always mirror a whole bunch of
repositories into a single unified repository and have both the builds
and the developers point at the appropriate mirror, which in a corporate
setting could be inside the firewall and very fast...
Yes, we were aware of the mirroring approach but due to the specific setup on the customer side we decided to go for the file based approach in the moment. So it is a P2 Repo, just that it is accessed on disk, not through http. Might be changed in the future.
Regards,
Andreas
[Updated on: Sat, 27 September 2014 09:16] Report message to a moderator |
|
|
Goto Forum:
Current Time: Fri Apr 26 14:01:10 GMT 2024
Powered by FUDForum. Page generated in 0.03170 seconds |
] 
Search
Help
Register
Login
Home
