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