August 17, 2011
On 2011-08-17 11:46, torhu wrote:
> On 16.08.2011 18:46, Jacob Carlborg wrote:
>> On 2011-08-16 16:30, Jesse Phillips wrote:
>>> It is almost like that. It's just that the cloning also requires the
>>> initialization and cloning of the submodules. You'll have to keep
>>> them in
>>> sync and I've never submoduled a project that had submodules it self.
>>
>> Yeah, I've read that now.
>>
>>> I'm not user if there is much point in separating them if you can use
>>> dwt-
>>> linux or win in something else. But jface could be its own repository as
>>> that isn't required to used DWT at all. And making that a submodule is
>>> fine.
>>
>> Not all top level directories need to be submodules, that was just a
>> thought. I could include everything to make it possible to build DWT in
>> one repository (the super repository) and have everything else in
>> submodules.
>>
>
> What problem is splitting things into submodules supposed to solve? The
> current Mercurial repository with everything in it is just 50 MB. I
> suppose Git repositories take up more space, but assume that's not why
> you want to split things up?
>
> If submodules are meant for the same use cases as SVN externals, they
> are primarily for automatically pulling in stuff that is separate
> because it is actually a separate project, probably maintained by
> someone else, or maybe just hosted elsewhere for some reason. Not for
> splitting a project into parts. Which is why I'm wondering what exactly
> you want to achieve here.

In addition to what Jesse Phillips replied to your post I think that these projects actually should be separate repositories. Another reason is that currently I have only interest in DWT and JFace. I see no reason to have the other projects in the same repository.

-- 
/Jacob Carlborg
August 17, 2011
On 17.08.2011 18:42, Jacob Carlborg wrote:
> On 2011-08-17 11:46, torhu wrote:
>>  On 16.08.2011 18:46, Jacob Carlborg wrote:
>>>  On 2011-08-16 16:30, Jesse Phillips wrote:
>>>>  It is almost like that. It's just that the cloning also requires the
>>>>  initialization and cloning of the submodules. You'll have to keep
>>>>  them in
>>>>  sync and I've never submoduled a project that had submodules it self.
>>>
>>>  Yeah, I've read that now.
>>>
>>>>  I'm not user if there is much point in separating them if you can use
>>>>  dwt-
>>>>  linux or win in something else. But jface could be its own repository as
>>>>  that isn't required to used DWT at all. And making that a submodule is
>>>>  fine.
>>>
>>>  Not all top level directories need to be submodules, that was just a
>>>  thought. I could include everything to make it possible to build DWT in
>>>  one repository (the super repository) and have everything else in
>>>  submodules.
>>>
>>
>>  What problem is splitting things into submodules supposed to solve? The
>>  current Mercurial repository with everything in it is just 50 MB. I
>>  suppose Git repositories take up more space, but assume that's not why
>>  you want to split things up?
>>
>>  If submodules are meant for the same use cases as SVN externals, they
>>  are primarily for automatically pulling in stuff that is separate
>>  because it is actually a separate project, probably maintained by
>>  someone else, or maybe just hosted elsewhere for some reason. Not for
>>  splitting a project into parts. Which is why I'm wondering what exactly
>>  you want to achieve here.
>
> In addition to what Jesse Phillips replied to your post I think that
> these projects actually should be separate repositories. Another reason
> is that currently I have only interest in DWT and JFace. I see no reason
> to have the other projects in the same repository.
>

Okay, I think I get the picture now.  Sounds like a good plan, then.

Would DWT become a single repository with all platform implementations and snippets in it, that has the base Java library as a submodule?  Or would it be dwt-win, dwt-linux, dwt-snippets, etc.?  The former sounds simpler, but the latter could make it possible to get rid of the extra directory levels that DWT2 uses currently.
August 17, 2011
torhu Wrote:

> Okay, I think I get the picture now.  Sounds like a good plan, then.
> 
> Would DWT become a single repository with all platform implementations and snippets in it, that has the base Java library as a submodule?  Or would it be dwt-win, dwt-linux, dwt-snippets, etc.?  The former sounds simpler, but the latter could make it possible to get rid of the extra directory levels that DWT2 uses currently.

My thought is:
Java runtime
Eclipse runtime
jface
DWT (Submodules for Java, Eclipse, Jface)
snippets (dwt and jface) (submodules for DWT)
August 17, 2011
On 2011-08-17 18:58, torhu wrote:
> Okay, I think I get the picture now. Sounds like a good plan, then.
>
> Would DWT become a single repository with all platform implementations
> and snippets in it, that has the base Java library as a submodule? Or
> would it be dwt-win, dwt-linux, dwt-snippets, etc.? The former sounds
> simpler, but the latter could make it possible to get rid of the extra
> directory levels that DWT2 uses currently.

I haven't decided this yet and it's this I'm trying to figure out, what will be the best. This is also why I'm asking here what people think.

I'm not sure what you mean with "extra directory levels that DWT2 uses currently". Do you mean that org.eclipse.swt.gtk.linux.x86 contains:

src
  org
    eclipse
      swt
        ...

This will most likely not change. When all platforms were in their own repositories (DWT1) we just had "dwt" as the root directory. The current package layout, in DWT2, is what the original SWT sources use and it was decided that it was best to follow the original sources as closely as possible to ease porting future versions of SWT.

In DWT1 most classes containing "SWT" was renamed to "DWT" but this just caused more problems. I guess it would be easier to rename the root package to DWT then renaming all classes containing "SWT". But it would be an additional step when porting future versions. I do agree that this deep package level is annoying.

-- 
/Jacob Carlborg
August 17, 2011
On 2011-08-17 20:18, Jesse Phillips wrote:
> torhu Wrote:
>
>> Okay, I think I get the picture now.  Sounds like a good plan, then.
>>
>> Would DWT become a single repository with all platform implementations
>> and snippets in it, that has the base Java library as a submodule?  Or
>> would it be dwt-win, dwt-linux, dwt-snippets, etc.?  The former sounds
>> simpler, but the latter could make it possible to get rid of the extra
>> directory levels that DWT2 uses currently.
>
> My thought is:
> Java runtime
> Eclipse runtime
> jface
> DWT (Submodules for Java, Eclipse, Jface)
> snippets (dwt and jface) (submodules for DWT)

That looks reasonable. But shouldn't it look something like this, submodules in parentheses:

Java runtime
Eclipse runtime (java runtime)
DWT (Eclipse runtime)
JFace (DWT)
snippets (jface)

This is how the dependencies look like. Read "->" as depends on

Java runtime ->
Eclipse runtime -> java runtime
DWT -> Eclipse runtime, java runtime
JFace -> DWT, Eclipse runtime, java runtime
snippets -> JFace, DWT, Eclipse runtime, java runtime

All of these dependencies are not direct dependencies.

I mean, if the Eclipse runtime repository doesn't contain a submodule for the Java runtime it can't work on its own.

-- 
/Jacob Carlborg
August 18, 2011
On Wed, 17 Aug 2011 21:26:14 +0200, Jacob Carlborg wrote:

> Java runtime
> Eclipse runtime (java runtime)
> DWT (Eclipse runtime)
> JFace (DWT)
> snippets (jface)
> 
> This is how the dependencies look like. Read "->" as depends on
> 
> Java runtime ->
> Eclipse runtime -> java runtime
> DWT -> Eclipse runtime, java runtime
> JFace -> DWT, Eclipse runtime, java runtime snippets -> JFace, DWT,
> Eclipse runtime, java runtime
> 
> All of these dependencies are not direct dependencies.
> 
> I mean, if the Eclipse runtime repository doesn't contain a submodule for the Java runtime it can't work on its own.

This does look right. Though I'll bring up this thought which also goes against my proposal. Not that I'm against the idea.

Suppose you have a project which uses DWT, then later I want to make use of JFace. Since JFace comes with DWT you'd rework your build to include the new location rather than just add JFace too it. However as you don't have to pull in JFaces DWT you can just leave it. But what about the other direction, you start by using JFace and decide to phase it out, either to use DWT itself or another layer library.

Anyway these are uncommon, already require proper redesign and yadda so I like your reasoning.
1 2
Next ›   Last »