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
>>>>>