If two parties want to communicate with securely using OTP , how is the key ( that is lengthy as plain text) shared with other party for decryption ?
One way of sharing a OTP is to draw a random sequence (a huge list of randomly chosen characters or btis) in advance and to disclose it beforehand to the other party (physical meeting). The obvious disadvantage is the need to keep secret a big amount of information.
Another way is to share a short secret (key) in advance (e.g. during a physical meeting). This is much more practical in the sense that the information to be kept secret is much shorter. In order to share a random sequence as long a the plaintext to be transmitted, a cryptographic primitive is then used such as a stream cipher (or, e.g. a block cipher or hash function running in counter mode). An IV (a public short string) is used to derive a random sequence anew for each plaintext. The drawback compared to sharing a long random sequence before hand is that the random sequences thus genereated are "only" pseudo-random (i.e. in the best case scenario, they appear random to a computationally bounded adversary provided some hard computational assumption holds, such as the hardness of computing quadratic residues for instance; sometimes, the security is even more ad-hoc, like when using hash functions in counter mode).
Finally, an additional way is provided by quantum key distribution (Bennett and Brassard, 1984). The key is distributed through a quantum channel and it is assumed that tampering will be detected due to the physical properties of the channel. The advantage is that the whole system can be made to rely on inconditionally secure primitives only. The disadvantage is that the rate of random sequence generation is pretty low nowadays and do not compete at all with the previous solution. Also, it is highly susceptible to denial of service attacks.
That's a well-known disadvantage of using OTP. Like in the ancient times, you could e.g. employ a trusted courier for that transfer.
One way to share a OTP key is to separately send several different independently-generated OTP keys, each one in its own tamper-evident package (often more than one layer).
When Bob receives the package, if the seal shows the package hasn't been opened in transit, then therefore no one has opened the package and copied or modified or entirely replaced the OTP key inside, and therefore that key is safe to use between Bob and whoever sent the package.
When Bob receives the package, if the seal shows the package has been opened (or if shippers have banged it up so much it's hard to tell), then he simply discards it. That makes the key inside that package useless to whoever might have copied or replaced it.
The various quantum key distribution systems can each be seen as a high-tech way of sending one bit at a time, and discarding bits that might have been tampered with.
The tamper-detection system isn't perfect on its own. How can Bob be sure the package came from Alice and not Mallory? If Mallory has intercepted one of the OTP key packages from Alice, how can Alice discriminate between "good" over-the-air ciphertext messages from Bob vs "bad" over-the-air ciphertext messages that claim to be from Bob, but they're actually from Mallory? How do we prevent a denial-of-service attack? There exist work-arounds to these problems by combining tamper-detection with trusted couriers, or armed couriers, or some sort of back-and-forth key-agreement protocol, or some combination.
Given that the key does not need to be constructed in any particular way any secret sharing method such as the Diffie-Hellman exchange be repeated to build up to the required key length. And simply concatenating the acquired secrets (after potentially passing them through a cryptographically secure PRNG to remove any exchange artifacts). However this method is susceptible to the same attacks as the chosen secret sharing method.