Sahoo wrote:
> Harsha,
>
> Can you give some examples of what is the scenario that demands
> engineers to upload binaries to java.net maven repo? And why can't
> that be done by RE?
Hi Sahoo,
There is no such scenario where one (engineer) can do but the other can
not.. :-)
As far as RE's role is concerned, RE will do the publishing/promoting of
Qualified bits. By qualified, I mean, bits that are tested with the
regular QA cycle.
Perhaps the scenario that I can refer here is, say module 'A' does not
depend on any other module. But, other modules X,Y depend on A.
Developers of X & Y will create dependency rules of their modules on A.
Now, there is another module Z that depends on Y. Now, developers of
module Z, look for repositories of A, Y. In order to compile and test
during dev. cycles there is a need to have A in the first place
somewhere. Isn't it. Well there can be a workaround to include these
missing bits of A, somewhere in the classpath during development of Z.
But, thats not what we wanted; What's wanted is seamless maven access of
A and other dependencies of Z, for module Z in this case.
Thanks,
Harsha
>
> Thanks,
> Sahoo
>
> Harsha Godugu wrote:
>> Sahoo wrote:
>>> Dinesh Patil wrote:
>>>> Shreedhar Ganapathy wrote:
>>>>
>>>>> In addition control wrt sources corresponding to these binaries
>>>>> will be better with a release engineering process involved.
>>>>>
>>>>> Sahoo wrote:
>>>>>
>>>>>> Dinesh,
>>>>>>
>>>>>> Thanks for documenting this, but I hope we are *not* allowing
>>>>>> every developer to build binaries in their environment and push
>>>>>> it into global maven repo, are we? I understand Java removes a
>>>>>> lot of release engineering issues that are typically associated
>>>>>> C/C++ world, but that does not mean we allow developers to create
>>>>>> binaries and push it into maven repo. Binaries that are used to
>>>>>> build production systems like GlassFish *must* be built in
>>>>>> controlled environment using processes that are reproducible. Why
>>>>>> can't binaries be pushed by release engineering team? Then they
>>>>>> can take care of issues like tagging the workspace, using the
>>>>>> right compiler version, right flags (e.g. debug/optimize) to
>>>>>> compile, etc.
>>>>>
>>>> I didn't see this email in my inbox yet, may be some mail-client
>>>> issue.
>>>>
>>>> We have a RE process, and tagging/releases will happen from the
>>>> controlled env. Terena is working on setting up the lab env for V3.
>>>>
>>>> This is just a option for developers who are asking for automated
>>>> process/rules to independently publish their artifacts by the owners!
>>> Who ensures that those binaries are *not* used by GlassFish?
>> Just my thoughts..
>>
>> There are 2 different scenarios being discussed in this email
>> thread. one) for the developers and the other) for the so called
>> release vehicle (production quality GF).
>>
>> When GF is released it's released by RE. Not by developers :-)
>> There is no way during GF bundle installation of binary bits (not
>> source) will goto maven repository and bring jars
>> to the Users (Cu's) desktop. If it happens that's error in the
>> installer.
>>
>> All this publishing is ONLY to prepare the ground work for v3
>> modularization. (Splitting the appserv-rt.jar into various jars and
>> define dependency on each other jar).
>>
>>> Secondly, the Wikipage contains information that can only be used by
>>> Sun engineers (the m/c is sfbay m/c).Why does a Sun engineer have to
>>> publish their own binary to maven?
>> This is interesting question. Today, in v3, if a MODULE owner needs
>> to define and test a dependency rule, for his/her module, we need
>> something like maven repository in place. (due to modularization
>> requirement for v3). This repository could be internal (file based ,
>> within swan) or it could be external. Looks like we chose external on
>> the web. That's also, due to open-source reason. Please note that,
>> only those modules that have a subproject under Glassfish are on the
>> maven repository for the binary bits. Only those modules are being
>> published. Rest of the jars (modules ) which are dependent on the
>> primary jars are/should NOT (be) published. All this is, to start
>> at some place in Glassfish v3 development.
>>
>> Please disregard the part of the URL that was mentioned here to
>> upload a Jar / whatever bits to a repository. That should not be the
>> case. Only a module that has a primary dependency on the rest of the
>> modules in glassfish need to go there. Only modules owners can decide
>> which jar needs to be on the repository. (or doesn't have to be ) .
>> And the other condition for the module is, to be a sub-project of
>> Glassfish. Only a publisher with an access can publish.
>>
>> Once a particular module is finished development, the regular process
>> is followed, which is, RE will pick those particular versions of Jars
>> for each module, (which is basically, version number changes..) and
>> then release product for QA.
>>
>>
>> thanks,
>> Harsha
>>
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>