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
>