maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
Subject Re: Best strategy for using lots of modules/projects with some private and some OSS
Date Tue, 22 Sep 2015 20:03:07 GMT
I turned off the block.

Ron
On 22/09/2015 3:40 PM, Kevin Burton wrote:
> Weird. Looks like the blog.artifact-software.com isn’t responding to DNS .
> At least on our network..
>
> On Tue, Sep 22, 2015 at 11:29 AM, Ron Wheeler <
> rwheeler@artifact-software.com> wrote:
>
>> You have clearly given this a lot of thought and your project is just a
>> bit less than twice as large as ours so I am not sure about giving advice.
>>
>> http://blog.artifact-software.com/tech/?p=84 is an article that I wrote a
>> few years ago dealing with our approach to the same problem.
>>
>> Our solution to the version management problem may not be to your tastes
>> but it did save us a lot of grief and served us well once we got through
>> the first few releases where we were touching every piece of source code on
>> each release.
>>
>> We essentially started treating our own code as if it was OSS.
>> This made us think about modularity and functional separation into
>> projects and changed our ideas about versions.
>>
>> Ron
>>
>>
>>
>> On 22/09/2015 1:47 PM, Kevin Burton wrote:
>>
>>> We have a multi-module setup whereby we have about 150 independent
>>> modules.
>>>
>>> Our build takes a long time and actually slows down development as we have
>>> to do a compile of a LOT of source code to rebuild the project.
>>>
>>> Additionally, we have a lot of code that we want to Open Source.
>>>
>>> This has meant git submodules the IMO git submodules really don’t work
>>> when
>>> using branches.  They break and require a whole bunch of custom works and
>>> hack and when they DO break it’s confusing how to resolve them.
>>>
>>> This has meant that we’ve not really done a good job of OSSing our code
>>> base as its just too hard.
>>>
>>> What we’ve done to date is just have one major version number across all
>>> our projects.  So upgrading them and fixing their dependencies means that
>>> I
>>> just have to change a version number everywhere and I’m done.
>>>
>>> What I was thinking of is changing this strategy to use the maven
>>> "versions:use-latest-versions” plugin.
>>>
>>> What i would do is have a parent directory named ‘spinn3r’ which just has
>>> a
>>> bunch of git submodules.  We NEVER branch in this directory.
>>>
>>> It also means that any of our developers can check it out so that they
>>> have
>>> all of our source code.
>>>
>>> At this point I can use a normal development strategy for each project.
>>> They don’t use submodules which enables us to branch/merge easily.
>>>
>>> I can also have a dedicated IntelliJ or Eclipse project for each one and
>>> switch between them.
>>>
>>> Now the main issue I have is how do I bump releases easily and make sure
>>> all my code is using the latest version of its sibling projects.
>>>
>>> In the parent directory I can just run versions:use-latest-versions … on
>>> each one of the projects so that it automatically pulled in the latest
>>> version after a release.
>>>
>>> The only problem here is that there’s a dependency graph that needs to be
>>> considered.
>>>
>>> for example, if project A depends on project B, then we have to bump the
>>> version and push project B into maven before we upgrade dependencies on
>>> project A.
>>>
>>> This is a frustrating issue…
>>>
>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message