Just to clarify, I'm not proposing that we actually move those modules
under main. This was just a question to stimulate thinking about the
nature of nucleus.
On 7/15/2011 8:22 AM, Tom Mueller wrote:
> I'm not lobbying to go either way, but I do have a question.
>
> Why not make grizzly, hk2, jersey, updatecenter, etc. modules under
> main too?
> How is the new nucleus different from any of these other modules WRT
> release engineering?
>
> I certainly understand the pragmatic effort savings of keep this all
> in one repository, one java.net project, etc.
>
> Something to consider... right now, we have been discouraged
> (forbidden?) from putting the devtests from appserv-tests into the v3
> tree because it would increase the checkout time. If nucleus was in
> its own repository, then we presumably could put the tests for nucleus
> in that repository too. And maybe devtests for the appserver could be
> moved into the appserver repository.
>
> On 7/15/2011 6:33 AM, Jerome Dochez wrote:
>> On Jul 15, 2011, at 2:18 AM, Sahoo wrote:
>>
>>> Hi Jerome,
>>>
>>> When we find ourselves having to decouple life cycle of nucleus
>>> development from that of appserver, we will have to move to binary
>>> integration model. When we move to such a model, we will adjust our
>>> checkout goal to check out just the modules that are built from
>>> source. The components that are integrated using binary dependencies
>>> will be included from maven repo. We can even provide checkout goals
>>> that will checkout components that are binary integrated so that
>>> developers have all the necessary code checked out to debug.
>>>
>>> Actually, why just limit ourselves to consuming nucleus as a whole?
>>> As our modules and interfaces stabilize, I expect us to make our
>>> development/release process even more modular there by allowing us
>>> to release modules. The role of a distribution will then be limited
>>> to an assembly of a certain set of versioned components that are all
>>> tested/certified to work together. We can still use the top level
>>> pom.xml to provide us abilities to checkout all the sources
>>> corresponding to a particular release of a distribution.
>> yeah, well, I think this would quickly become a release hell to deal
>> with some many multiple versions to coordinate a final release. I am
>> not sure we have the bandwidth to achieve such flexibility.
>>
>>> We should not change our workspace structure to mirror
>>> distributions. Distributions can evolve over time. New distributions
>>> may be added, existing ones's composition may change. Distributions
>>> may not have superset/subset relationships.
>>>
>> I agree except that *at this point*, we really only have one reusable
>> distribution (nucleus) and few superset/subset ones for GF. I am not
>> expecting us to have multiple horizontal distributions any time soon.
>>
>>> Another point I would highlight is that for very many reasons maven
>>> coordinates of various GlassFish modules are not what we want them
>>> to be. I am glad to see us committed to improve that. I hope we will
>>> have some uniform way to locate a module from maven coordinate.
>>> e.g., one can very accurately predict the svn url of module in Felix
>>> project from the maven artifact id. If we constantly move our
>>> modules from location to another to meet the needs of distributions,
>>> either we constantly update their maven artifact ids or we can't
>>> infer a module's location from its artifact id.
>> It would be nice, but I don't consider that a must do.
>>> The cost of the proposed change does not probably include the effort
>>> individual developers have to pay to adjust their build scripts,
>>> hudson jobs, IDE project settings, etc. I see that causing great
>>> deal of pain. Actually, I am not as much worried about the change as
>>> I am more worried about the reason/motivation behind the change.
>>>
>>> Last, but not the least, I would like to know how what I suggested
>>> is not simpler than what is being proposed. I don't mind renaming v3
>>> to main, that makes sense and is overdue anyway. Other than that
>>> with the current proposal, we still need a pom.xml in main/. What I
>>> suggested can be managed by adding some build configurations in the
>>> top level pom.xml and there by avoid major disruption to established
>>> build processes. We don't have to solve all issues at once. We can
>>> make incremental progresses in a backward compatible way and yet
>>> meet our requirements I feel.
>> I think I would be fine with your proposed solution assuming we have
>> identified resources for implementing it, which might very well be you !
>>
>>> I hope I answered your questions. I sincerely urge to give this a
>>> thought before moving the sources around.
>> I think I am fine with either solution. let's wait for CA to wake up
>> to get a more complete feedback.
>>
>>> Thanks,
>>> Sahoo
>>> On Friday 15 July 2011 01:20 PM, Jerome Dochez wrote:
>>>> no we tried to go for the simplest route at this point.
>>>>
>>>> what you propose is certainly interesting although moving our
>>>> modules around does not preclude from adopting it at some point
>>>> (but making the move un-necessary). One of the thing that was
>>>> proposed earlier was to have nucleus being built using not only a
>>>> different workspace but also a dedicated version (not sync'ed with
>>>> glassfish's version).
>>>>
>>>> I thought it was an overkill at this point and I really wanted to
>>>> keep a single version for all artifacts for as long as possible but
>>>> could you clarify how your proposal would work if we find ourselves
>>>> having to do separate releases of nucleus from its appserver
>>>> counterpart ?
>>>>
>>>> jerome
>>>>
>>>> On Jul 15, 2011, at 12:05 AM, Sahoo wrote:
>>>>
>>>>> Upon further thinking about this, I would like to know if we
>>>>> considered not moving the modules around. Instead, how about just
>>>>> providing a top level target in pom.xml to just check out the
>>>>> modules corresponding to a particular distribution? This would
>>>>> allow us to keep all the modules under one root and give us the
>>>>> flexibility to build disjoint distributions. The proposed source
>>>>> code layout seems to assume that all the distributions have a
>>>>> subset/superset relationships.
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>> On Friday 15 July 2011 06:17 AM, Shreedhar Ganapathy wrote:
>>>>>> Hello all
>>>>>> While work on 3.1.1 is heading to the finish line, we are looking
>>>>>> into opportunities for doing some long pending code
>>>>>> reorganization that will benefit us for future releases.
>>>>>>
>>>>>> To this end, we will be making several changes to
>>>>>> trunk workspace layout and build procedure over the next couple
>>>>>> of days
>>>>>> .
>>>>>>
>>>>>> Please read through and let us know if you have any questions or
>>>>>> concerns or if work on something will be severely affected that
>>>>>> we need to reconsider currently planned workspace migration
>>>>>> schedule.
>>>>>>
>>>>>> What we plan to do :
>>>>>>
>>>>>> 1. The current trunk workspace will be moved
>>>>>> from
>>>>>>
>>>>>> https://svn.java.net/svn/glassfish~svn/trunk/v3
>>>>>>
>>>>>> to
>>>>>>
>>>>>> https://svn.java.net/svn/glassfish~svn/trunk/main/appserver
>>>>>>
>>>>>> using svn move command in order to preserve change history.
>>>>>>
>>>>>> 2. Workspace modules which are part of "atomic" module will be
>>>>>> moved from their current location under trunk/v3 to new location
>>>>>> under
>>>>>> https://svn.java.net/svn/glassfish~svn/trunk/main/nucleus
>>>>>> repository. Relative location of a module compared to top level
>>>>>> nucleus directory will remain the same.
>>>>>> This nucleus workspace will be used for bringing together modules
>>>>>> that should belong here to will make up nucleus as a core
>>>>>> component for server runtimes.
>>>>>>
>>>>>> How are you going to be affected and what you need to do:
>>>>>>
>>>>>> 1. If you have any pending checkins, especially in "atomic"
>>>>>> modules please make sure that you check them in by
>>>>>> Friday, 07/15/2011 2 PM PST
>>>>>> deadline. At that time we'll start moving workspace content to
>>>>>> the new URLs. It is very likely that you will need to do fresh
>>>>>> checkout after the move is completed as, in the past, we had
>>>>>> issues with module renaming/moving if you try to update or
>>>>>> migrate you existing workspace.
>>>>>>
>>>>>> 2. If you have any pending merges from 3.1.1 branch please check
>>>>>> them in by the same deadline i.e
>>>>>> Friday, 07/15/2011 2 pm PST
>>>>>> . You will still be able to merge after the workspace
>>>>>> reorganization since svn move preserves past layout history, but
>>>>>> it is easier to get it done while the trunk workspace more
>>>>>> closely resembles 3.1.1 branch.
>>>>>>
>>>>>> 3. Expect workspace build to be broken or unstable for at least
>>>>>> several hours and up to a day while the module migration is going
>>>>>> on. If you have work that cannot wait please keep a copy of old
>>>>>> workspace and track your changes so that they can be manually
>>>>>> applied to new workspace if necessary.
>>>>>> Do not check anything in after 2 PM PST Friday until you are
>>>>>> notified that new workspace is ready and available
>>>>>> .
>>>>>>
>>>>>> 4. After the migration is completed, you will need to check out
>>>>>> https://svn.java.net/svn/glassfish~svn/trunk/main
>>>>>> as your new workspace and you will be able to build both
>>>>>> nucleus and the rest of GlassFish from this top level directory.
>>>>>>
>>>>>> 5. As we progress with nucleus development and content cleanup,
>>>>>> more modules will need to be moved to
>>>>>> https://svn.java.net/svn/glassfish~svn/trunk/main/nucleus
>>>>>> . Detailed instructions for module migration will be provided
>>>>>> once we complete "atomic" content migration.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Shreedhar Ganapathy
>>>>>>